WSO2Con 2011: Open Service Federation Framework - Dipanjan Sengupta
- WSO2Con 2011
- - WSO2
The Case for Federation
Enterprises need to implement a federation model to meet the challenges of coordinating efforts, both internally and externally, Mr. Sengupta said. Federation he noted, enables diverse domains of service-oriented architecture (SOA) services and infrastructure to co-operate seamlessly.
From an inter-enterprise standpoint, organizations need to integrate different business units, invocate services across different domains, and ensure service version management, Mr. Sengupta observed. Additionally, acquisitions and mergers drive the need for enterprises to consolidate and reduce the redundancy of business and technical services owned by different business units across security domains, network segments, or even geographies.
At the same time, organizations also face inter-enterprise demands, particularly when they are part of a supply chain in which multiple trading partners are federated as a conglomerate or consortium and seek to promote their services for reuse by other partners, Mr. Sengupta explained.
By leveraging their well-established role as B2B intermediaries for e-commerce, many integration service providers are well positioned to expand their capabilities to include cloud computing and, thus, evolve into cloud service brokers, Mr. Sengupta said. These cloud service brokers also can act as a marketplace for services where service providers may showcase their services and service consumers may subscribe them based on their requirements, he added.
Introducing the Open Service Federation Framework
The framework allows a federation architect to define the relationship model between the different domains of an enterprise and set up the rules for sharing services and service artifacts between the federated domains, Mr. Sengupta explained. It also supports all the common enterprise domain models appropriate for implementing a successful federation, he said.
The framework, which can be deployed on-premise or in the cloud, creates the entry for a service in the target registry and triggers the appropriate workflow for the adoption of the service in a target domain, Mr. Sengupta said. It also creates the proxy for the service in the mediation component of the target domain and then deploys the proxy when the service is accepted.
Finally, the framework is composed of the two components. An Open Service Federation Manager is the core component that implements the rules and business logic for service federation. Domain Agents are domain technology-specific components, which implement a set of common interfaces and abstract classes, and help communicate registry events and artifacts to the Open Service Federation Manager. They also create the service proxies and deploy them in the mediation component of the domain in which they are collocated.
The Framework in Action
Mr. Sengupta noted that Open Service Federation Manager is a proven approach, and he provided a demonstration of how it works.
He first explained that within the framework, Cognizant has taken advantage of OSGi-compliant components, and that a small lightweight component is located with each domain, which has access and authorization to talk to both the ESB and the service registry of that particular domain. The Domain Agents listen to events going on in the domain, convert them into a format that is understood by the Open Service Federation Manager, and relay them to it. Next, the Open Service Federation Manager looks up the rules defined there and determines the domain or target domain(s) to which the event needs to be communicated by the Domain Agents.
In the demonstration, there are two domains. One is implemented in the IBM stack including IBM WebSphere Service Registry and Repository and WebSphere ESB. The other is in the WSO2 stack with WSO2 Governance Registry and WSO2 ESB. The two domains are up and running, and Domain Agents are aware and listening to the events going on between the registries. There are no services in the service list, and both registries are in their virgin states.
As part of the demonstration, Mr. Sengupta showed how a currency conversion service initiated in the WSO2 stack would be updated automatically in the IBM stack as well. He demonstrated how a how a Domain Agent would wake up when the event occurred—and how a Domain Agent would not just create a proxy in the service registry but would also change the service endpoint so that it pointed to the proxy service within the ESB. Additionally, he showed how the same types of artifacts had been created and how there were similar descriptions in the service.
Although, the demonstration was just one use-case showcasing interoperability between the WSO2 and IBM domains, Mr. Sengupta concluded, “I am pretty confident we can do this with most technology stacks.”
To learn more about how Cognizant is using WSO2 middleware to support its Open Service Federation Framework, view Mr. Sengupta’s full presentation here.