For building an enterprise solution normally we need to combine multiple existing enterprise services. These composite services helps in turns recursively composed with other services into higher level solutions and this is the one important feature of SOA. The main drivers for the creation of composite-services are,
- Usage simplicity: – Making a composite service like encapsulating participating services and enforcing the rules of their invocation can significantly simplify their usage.
- Improved reusability: – The availability of services provides new solutions that might otherwise not be considered. These new solutions can often be makes inexpensively and rapidly through development or enhancement of relatively few services.
- Solution partitioning, visibility, control and change management: – Composite services can serve as a partitioning mechanism for overall solution. Similar to the case of local and remote interfaces in EJBs, introducing composite services and exposing only some of their interfaces to external users permits controlling what is visible to the consumer. This provide the ability of underlying software architectures (composite services implementations) to quickly respond to changing requirements by changing the implementations of its subordinate services, as well as the interconnection between them with minimal or no impact to the consumers.
In this article we are discussing the service composition framework, Aspects of service composition, Composition approaches.
Service composition framework
The automatic service composition framework is in high level abstraction without considering a particular language platform or algorithm used in composition process. The aim of this type of framework is to give the basis to discuss the similarities and differences of the available service composition methods.
The above composition system has the two types of participants.
- Service provider: – The service providers propose Web service for use.
- Service requester: – The service requester includes information or services offered by service providers.
The system also includes the following components.
- Translator: – The translator translates between the external languages used n\by the participants and the internal languages used by the process generator.
- Process generator: – For each request the process generator tries to generate a plan that composes the available services in the service repository to fulfill the request.
- Evaluator: – If two or more plan is found the evaluator evaluates all plans and process the best one for execution.
- Execution engine: – The execution engine executes the plan and returns the result to the service provider.
- Service repository: – The execution engine returns the result to the service provider.
The phases of automatic composition include the following ones.
1) Presentation of single service:-Firstly the service provider will advertise their atomic service at a global market place. The essential attributes are,
- Signature: – It is represented by the service’s inputs, outputs, and exceptions.
- States: – It is specified by precondition and post condition.
- Non functional values: – These are attributes that are used for evaluating the services such as the cost, service quality and a security issues.
2) Translation of the languages:- Service composition systems distinguish the external and internal service specification language, The external language enhance accessibility of the users in the sense that the users can express what they offer or what they want in a relatively easy manner.
Eg: – Logical programming language
The standard web service languages are WSDL and DAML-S
3) Generation of composition process model: – The process generator tries to solve the requirement by composing the atomic services advertised by the service providers. The process generator usually takes the functionalities of service as input, and output process model that describes the composite service. The process model contains a set of selected atomic services and the control flow and data flow among these services.
4) Evaluation of composite service:-The composite services are evaluated by their overall utilities using the information provided from the non-functional attributes. The most commonly used method is utility functions. The requester should specify a weight to each non functionality attributes and the best composite service is the one who is ranked on top.
5) Execution of composite service: – Execution of a composite Web service cam be thought as a sequence of message passing according to the process model. The dataflow of the composite service is defined as the actions that the output data of a former executed service transfers to the input of a later executed atomic service.
Aspects of service composition:-
There are two major aspects used in service composition.
1) Composition design:-
Composition designs is concerned with designing a solution based on a set of existing services and specify how to coordinate the component services to fulfill the client request. Its role is to specify a list of services involved in a composition, and the way they interact and the composition topology. The two composite design approaches are,
- Hierarchical composition:-In this method the implementation of composite service is completely opaque to the service consumer (black box). A consumer arouses this type of composite service, waits till its execution completes and uses the results (either directly or in a form of side effects) of its execution.
- Conversational composition:-The black box composition approach or hierarchical composition is a very powerful way of dealing with complexities, there are situations when a consumer needs to control execution of the composite service based on the intermediate execution results of service execution. Such an implementation is supported by conversational composition. In this case the implementation of the composite service is also completely opaque to the service consumer, but selected intermediate execution results are exposed (grey box).
2) Composition implementation:- It is the simplest way to implement a service mediator is to use general purpose programming language.
There are five approaches includes the service composition.
1) Static with dynamic service composition:- During the design phase the static composition works when the architecture and the design of the software system are planned.
The dynamic web service composition contains the four steps.
1) Service providers publish their services at a web service registry.
2) The Service Composition Engine decomposes user requirements into an abstract service and sends a SOAP request to the registry to find proper services.
3) The web service registry returns a set of concrete services.
4) The service composition engine sends SOAP request to the concrete services and binds to them.
2) Model driven service composition:-Model driven service composition is based on dynamic service composition. It facilitates the management and development of dynamic service composition.
3) Declarative service composition. The declarative approach includes the two phases.
1) The first phase takes an initial situation and the desired goal as starting point, and constructs generic plans to reach the goal. The first phase is realized using PDDL (Planning Domain Definition Language) and estimated-regression planning as used in XSRL (XML Web-services Request Language), which must provide machine-readable semantics and specify the abstract service behavior
2) The latter one chooses one generic plan, discovers appropriate services, and builds a workflow out of them. The second phase may be realized by using existing process modeling languages, such as BPEL.
4) Automated with manual web services composition:- The automated and manual web service compositions are also possible. The manual web service composition is little bit complex than automated service composition.
5) Context based Web service Discovery and composition:- Context information is pre-processed and post-processed before being actually sent by the web service. In the framework, the context block could be processed by several components. Thus, processing instructions are needed to specify rules of precedence. The context framework proposed here provides several context types, such as location (GPS coordinates, country, local time and time zone), information about the consumer invoking service (name, e-mail address, preferences) and client context information, such as hardware or software. The authors demonstrate the functionality of the framework by developing an information service, which is invoked by several different clients, such as PCs or PDAs. In case of a PDA invoking the service, unnecessary representation information is cut out of the SOAP message, since the display size would not meet the graphical representation requirements.