12
Copyright © 2009 Open Geospatial Consortium, Inc.Copyright © 2009 Open Geospatial Consortium, Inc.
Figure 8. Opaque Chaining Pattern
In step 1, the user invokes an aggregate service unaware of the implementation details e.g. if the aggregate service uses a service chain and what kind of services are involved.
The aggregate service starts now the predefined execution order at this point, so the first service is invoked in step 2. The processed results or a reference are returned back to
the aggregate engine in step 3. These results or a reference are passed in the second service in step 4. If the aggregate service supplies a reference, the service has to obtain
the actual data in step 5 from the previous service. Again, after processing, the results or a reference are returned back to the aggregate service as can be seen in step 6. In step 7,
the aggregate service invokes the third service with the results from the two previous services. In case a reference to actual data is delivered, the third service requests the
actual data from the corresponding service as presented in step 8 and 9. After processing, the final results are returned to the aggregate service in step 10 and from there back to the
user in step 11.
4.2.4 Business Process Execution Language BPEL
The de-facto standard for Web Service workflow composition van der Aalst et al., 2003a is the Business Process Execution Language for Web Services BPEL4WS,
commonly referred as BPEL, which is a standard proposed by IBM, Microsoft and BEA Andrews et al., 2003a, that evolved from former standards, such as graph based WSFL
or block based and algebraic XLANG. BPEL descriptions scripts are XML based documents, which describe the roles involved in the message exchange, supported port
types and orchestration information of a process. BPEL is also a service composition model Wohed et al., 2003, which supports composition and coordination protocols
Chen et al., 2006. It consists of an activity-based component model, an orchestration model that allows the definition of structured activities, XML schema data types, a
service selection model and a mechanism for exception and event handling. 2
3 4
5 6
7
8 9
10 1
11
Copyright © 2009 Open Geospatial Consortium, Inc.Copyright © 2009 Open Geospatial Consortium, Inc.
13 A BPEL process does not only interact with a set of partners through Web Service
interfaces but also represents a Web Service from an external point of view figure 9. This process is internally implemented by the interaction of participating Web Services,
whose interfaces are specified by WSDL documents. Reuse and simplicity of BPEL processes are guaranteed by operating only on the “abstract” PortType definitions instead
of the concrete Port definitions of a Web Service. Thereby, specific binding and deployment issues remain at the Web Service and not at the BPEL process itself
Leymann et al., 2003.
Figure 9. BPEL Process Overview
Since BPEL is strongly related to Web Services, BPEL4WS is build on top of numerous XML based specifications: WSDL 1.1, XML Schema 1.0 and XPath 1.0. WSDL
describes all external resources and participating Web Services. XML Schema specifies the datatypes in conjunction with the WSDL messages and XPath is needed for internal
data manipulation.
