Technical Lead: Biplav Srivastava
Collaborators over the years: Vikas Agarwal, Girish Chafle, Koustuv Dasgupta, Gautam Das, Sugata Ghoshal, Mangala Gowri, Neeran Karnik, Arun Kumar, Ashish Kundu, Anupam Mediratta, Sumit Mittal and Sougata Mukherjea
External Collaborators: Prashant Doshi, John Harney
Availability: Synthy is freely available within IBM as-is. It can be provided externally but only under a commercial engagement.
We here discuss:
What exactly is Synthy?
Synthy is a technology for semi-automatically composing SOA-compliant components such that the new component meets the desired functional and non-functional requirements and the resultant component can be flexibly executed. While the technology is demonstrated using web services, the technique generally applies to services in Services Oriented Architecture (SOA), and possibly other component representations.
Applications are developed today in an ad hoc manner resulting in poor reuse of software assets and longer time-to-delivery. Viewing software components as web services, the current solutions to web services composition based on business web services (using WSDL, BPEL, SOAP etc.) or semantic web services (using ontologies, goal-directed reasoning etc.) are both piecemeal and insufficient for building practical applications. We have developed the first integrated and practical solution to composition of web services end to end from specification to deployment by synergistically combining the strengths of the current approaches.
There are two key novelties we have introduced: (a) We distinguish between web service instances that get actually deployed and web service types which represent a group of web services that have the same functionality. (b) We compose in stages representing what components are needed for the composite component and how the components should be connected together to realize the needed functionality.
The technology covers how the components capabilities should be represented, how the components should be composed and how the compositions should be managed/ adapted so that the user has minimal disruption during execution as the environment changes.
How does Synthy work?
A development organization maintains a registry of software components (web services, in our case) that are semantically annotated, using ontology to model the domain. When a new function/service needs to be created, the developer formally specifies the requirements of that service using terms from that ontology. Our tool (which uses AI planning-based techniques) then looks for relevant components in the registry, and stitches them together in a BPEL workflow that delivers the requested function. The control flow of the workflow is generated based on specifications that will change slowly (like the specification of the composite service) while the data flow of the workflow is generated based on factors that are quite dynamic (e.g. Quality of Service). We can also adapt to changes in the world by creating multiple alternative workflows and intelligently switching between them based on the severity of the change.
What makes Synthy special?
Synthy is unique in that (a) it is effective, (b) it is intuitively appealing and (c) it tries to position the role of different alternatives tried to date.
Synthy is effective as we have built a large set of compositions for a wide variety of domains including the domain of a commercial telecom customer. The composition built is correct by design (theoretically provable) and the tool will find one if a composition exists. In technical terms, the technology is sound and complete. The design of Synthy is also efficient and we have shown in simulated experiments that it can build composition in domains with large number of components.
Synthy is intuitively appealing because it separates "what components need to be composed" from "how they will be composed". We humans do this in practice and this approach is also theoretically sound.
Synthy also brings out the synergy among the current approaches. The business world has adopted a distributed systems approach for composition in which the web service instances are described using Web Services Description Language (WSDL), and published to a Universal Description, Discovery and Integration (UDDI) directory, composed into flows in a language like Business Process Execution Language for Web Services BPEL), and invoked with Simple Object Access Protocol (SOAP). The academia has propounded the AI approach of formally representing web service capabilities in ontologies, and reasoning about their functional composition using goal-oriented inferencing techniques from planning. These approaches by themselves are piecemeal, and insufficient. The former has focused on the execution aspects of composite web services, without much consideration for requirements capture and the development process. The latter approach has stressed the feasibility of service composition based on semantic descriptions of service capabilities, but its output cannot be directly handed off to a runtime platform for deployment. We use both - the academia approach is used to answer the "what" of the composition while the industry approach is used to answer the "how".
IP:Papers and Patents
Papers
Patents Applications