Key learning from Home Entertainment/Automation that can be applied to SOA/SaaS

Unlike the previous generation where technology innovation was driven by enterprise needs, over the past few years technology innovation such as smart phones, multimedia, game consoles, multimedia and social networking is being driven by the consumers. In short the consumers have gone digital, whether it is HDTV, Blue-ray, Home automation, smart phones, media servers or IMS (IP Multimedia Services). The vendors manufacturing these devices and services understood that unless there are standards adopted by industry - the consumers would not adopt these technologies (especially as they are not cheap). It is for this reason, most of the large vendors (hardware, software, manufacturers, protocol stack providers, etc.) got together to form the Digital Living Network Alliance (DLNA).


Their objective was to resolve the following consumer challenges:

• Products designed for the home should be easy to install, provide noticeable user value and be affordable
• Product must inter operate with each other without requiring the consumer to undergo complex setup and configuration for connection between devices
• Digital home products must inter operate with each other and with existing CE devices such as TVs and stereos.

Doesn't this sound very similar to the current IT Operations challenges?

The above diagram illustrates DLNA's view of the customers needs (source: DLNA). In order to be vendor neutral and provide the consumer the ability to control any service (yes! they call it services) the DLNA members standardized the technology stack (as shown below - source DLNA).

The key learning here is that the vendors adopted Peer-to-Peer (P2P) for device discovery, control and Media management. For now they have all adopted UPnP, especially as most existing devices at home (desktops, laptops, storage devices, game consoles, IP based TVs, Stereo systems, network hubs, etc.) support UPnP. Some of the vendors such as Microsoft support both UPnP and WS-Discovery and it the long term (once the backward compatibility issues are addressed) the industry may migrate to WS-Discovery.

For those getting ready to purchase TVs, Phones or other Digital Devices, I would recommend you verify that they are DLNA Certified.

The next obvious question is What does this have to do with SOA/SaaS? Well! why not use this same approach for deploying services? It would make life much easier for IT Operations and potentially eliminate the need for additional ESB hops in the network. Yes! I am back on this topic :). The Services-Oriented approach, it is basically a P2P architecture, i.e. a consumer invokes a producer. As most of the large software vendors have made a commitment to adopt Services Component Architecture (SCA) and developing the SCA Run time engines, it would great if they could adopt either UPnP, WS-Discovery or some other P2P technology. The following diagram illustrated the joining of new node/service(s) to the P2P network.

Benefits:
Following are the benefits of adopting this approach:

• Based on the SCA standards -unique (logical) service name for services both for defining and invocation. Do not need to know the EPR (physical location) at the time of deployment.
  
• Multi-cast availability of service whenever an instance come up - dynamic configuration does not require IT Operations or tools (even if they are automated) to change configurations.
• Service maps (for a predetermined domain/network) maintained at each node. Complete map could be maintained in the Super peer (read up on p2p architecture for more details).
• Eliminate the need for Service Registry in production. As each instance of the node and services is maintained dynamically by the Super Peer - there isn't a need to maintain and administer a Service registry.
• Eliminates the need for having a separate monitoring agent on each node, especially as each instances could updates it's own service performance details in the P2P map.
• Universal administration tool could be used to configure one or all the instances at any node and propagate the changes across the network.
• As the consuming services would know the EPR of the producing service, this eliminate the need of an ESB.
  

The Newton: Component Model (Key technologies, OSGi, Jini, SCA) is the only run time engine I know of, that supports both P2P (Jini) and SCA. The Apache Tuscany project does claim to support JXTA (P2P) binding and have not researched it as yet.

Just my thoughts and as always do feel free to drop me line with your comments and/or feedback.

- Yogish