Dynamic Web Services Integration

An Overview of Web Services for Dynamic e-Business Integration

Web services are Internet based reusable components that provide a standard service interface defined by Web Services Definition Language (WSDL) and a common communication protocol called Simple Object Access Protocol (SOAP) (Jasnowski, 2002). Web services are deployed on a SOAP enabled Web application server and published in Universal Description, Discovery, and Integration (UDDI) registries. If the Web services providers are looking for lightweight "UDDI" registries, Web Service Inspection (WS-Inspection) Language (WSIL) documents are more appropriate. WSDL and WSIL are XML-based representations of the description and discovery information of a Web service, respectively. SOAP is also built on XML documents and common transport protocols such as HTTP, FTP, or Messaging Queue (MQ).

Web services are a key weapon for enabling business process collaboration and application integration. Web services have been used successfully in at least the following types of business application integration, namely, business-to-business integration, business to application as well as application-to-application integration. Specifically, lots of Web services based flow description languages have been proposed to orchestrate the business process collaboration among buyers, suppliers, and trading partners. Some of the available flow languages include Web Services Flow Language (WSFL) (Leymann, 2001), Business Execution Language for Web Services (BPEL4WS), Web Services Choreography Interface (WSCI), etc.

Web services have played an important role of enabling business application integration and collaboration across multiple organizations. As shown in Figure 1, the integration can be categorized into two types, namely, internal integration and external integration.

Figure 1: Web Services Enabled Advanced e-Business Integration.

The internal integration includes all the integration aspects within one enterprise. For example, enterprise application integration (EAI) is a typical example of internal integration. As for the external integration, it covers all the possible integration patterns across multiple enterprises. We often call this B2B integration. The typical external integration patterns are listed as follows:

• Message exchange based integration

• Application to Application integration (A2A)

• Business Process to Application integration (BP2A)

• Business Process to Business Process integration (BP2BP)

The message exchange based integration pattern shown in Figure 1 is a natural extension of Electronic Data Interchange (EDI) solution over Internet. MQ based messaging solutions are addressing this kind of integration issue. A2A is a simple integration scenario that refers to a point-to-point application integration. On both sides, they need to build adaptors to translate the native data formats into a mutual understandable format as well as to use an acceptable communication protocol for another site. Another type of external integration pattern is BP2A, which refers to a managed business process in an enterprise that will have interactions with one or more applications which are treated as externalized activities in the managed business process. The enterprise, which hosts applications, is loosely connected with the enterprise, which has managed business process. On the other hand, if there are business process engines deployed on both sides, they need to collaborate with each other based on the exchanged data and control messages. We call this kind of integration business process to business process integration (BP2BP).

As shown in , the integration solutions can be deployed in a point-to-point type, Hub style or peer-to-peer manner. For instances, if one enterprise is collaborating with multiple enterprises, there is a Hub integration pattern to support on-boarding process and services provisioning to allow all trading partners can have a central place to publish and subscribe services in a managed e-Hub infrastructure (Zhang, 2002a). Managed e-Hub consists of (1) a centralized membership portal with UDDI synchronization for rapid registration, subscription; and (2) provisioning of Web services, central connection and a control security model for all businesses and users to access services. On the other hand, integrating different business process solutions deployed in a distributed environment results in a peer-to-peer integration model.

All the above enterprise integration patterns can be realized in Web services enabled infrastructures. For example, Web services provide a standard way to describe the integration APIs and communication protocols for each enterprise application. Then, based on SOAP protocol, any integration partners can communicate with each other in a secure way guaranteed by the system level security mechanism and service level WS-Security specification (OASIS, 2003). However, when we build adaptive business infrastructures, there is a need for more advanced Web services technologies to realize the business process enabled enterprise integration and collaboration.

In this section, we present some research results on how Web services can be used and enhanced to build dynamic e-business infrastructure. We will cover (1) Overview of Web services creation and invocation; (2) Federated Web services discovery; and (3) Web services composition for business process integration.

Overview of Web Services Creation and Invocation

Generally speaking, a Web services solution consists of two related processes, namely creating Web service interface in WSDL and implementing the operations defined in WSDL. As for the Web services interface, we can create it manually or use Web services development toolkits to generate it automatically from the implementation code. This interface file can be deployed on any operating system or any Web application server. On the other hand, we can implement the detailed business logic and operations in any programming languages such as C/C++ and Java. Microsoft .NET framework is an example platform using Web services as a foundation (Bertrand, 2001). A Web services creation diagram is illustrated on the left hand side in Figure 2.

Figure 2: Web Services Creation and Invocation.

As for Web services invocation, we can use a SOAP RPC call to invoke a Web service deployed on a Web application server with a SOAP engine. This kind of SOAP RPC call can be included in a Web services client proxy, which can be generated automatically by a development toolkit. Another more general alternative is using Web Services Invocation Framework (WSIF, 2002) from Apache (2002). WSIF hides the complexities of the regular SOAP invocation process no matter what kind of SOAP implementation and application platform. An example input for WSIF is the URL of the WSDL and other input parameters for invoking methods defined in WSDL. A Web service invocation diagram is illustrated on the right hand side in Figure 2. The middle part of Figure 2 is an example of deployment and publishing processes that are related to the Web services creation and invocation.

More information about the basic idea of Web services and the relationships with other technologies such as agent technology can be found from (Huhns, 2002; Curbera, 2002; Roy, 2001). Specifically, Huhns (2002) described the relationship between popularly used agents and Web services. The service oriented architecture including Publish, Find and Invoke as well as basic building blocks of Web services such as WSDL, UDDI and SOAP has been described in Roy (2001) and in Curbera (2002).

The key requirements for Web services to mature are interoperability and security as well as business process enabling. Industry leaders are creating Web Services Interoperability Organization (WS-I, 2002) to standardize WS-I Security Profile and other profiles. As for the Web services based business process flow, BPEL4WS has been submitted to OASIS (Organization for the Advancement of Structured Information Standards) which is an e-business user group consortium to promote standardization. In addition, Semantic Web services and QoS related topics have attracted some researchers and engineers in the field. McIlraith (2001) described a few examples of DAML-S for creating semantic Web services and then introduced semantics for Web services using DAML-S (McIlraith, 2003). From the solution point of view, Medjahed (2003) presented a Web services infrastructure for e-governments. Some QoS issues that the services providers are facing in Web services have been discussed in Menasce (2002).

Federated Web Services Discovery

After creating Web services, we can publish them into a Web service registry. Currently, there are two types of registries, namely, UDDI registry and WSIL documents. UDDI registry provides a centralized place to publish Web services. It could be a public UDDI registry that allows any Web services providers to publish Web services. Meanwhile, it could also be a private UDDI registry that stores Web service information in a controlled environment. As for the WSIL documents, it is a plain-text based XML document that may include service name, location of a WSDL or UDDI entries. Facing different kinds of Web services registries, the native discovery mechanisms are UDDI4J and WSIL4J which are from Apache open source project (Apache). There are totally different programming interfaces. Therefore, creating a uniform Web services discovery framework which can provide an unchanged programming interface and effective search result aggregation is an emerging research topic. Based on these requirements, a sample advanced Web services discovery mechanism should look like the federated Web service search engine shown in Figure 3.

Figure 3: Federated Web Services Discovery.

In Figure 3, the applications could be a regular program, a Web page, or a SOAP application. They pass the higher-level Web services discovery request to the federated Web services discovery engine, which includes components like compound query handler, native search command dispatching and search result aggregation with different-level data mining capability. While aggregating the search result, the federated Web services discovery engine may need to check the capability of a Web service.

In this framework, we can use a capability matching engine to help select or sort the Web services retrieved from different Web services registries. The capability of a Web service refers to the functionalities provided by this specific Web service. Usually, you can retrieve the capability of a Web service through invocation. For example, a shipping company provides shipping Web service to its customers. From the Web service interfaces, the only thing provided is the method signature information. If you really want to know the price information on different types of services (e.g., overnight delivery, second day delivery and third day delivery), you have to invoke the corresponding methods of this shipping Web service. Therefore, a capability match making mechanism should be used for the next-level Web services discovery. A few Web services capability matchmaking mechanisms have been proposed in Gao (2002) and Web services Matchmaking Engine which is included in Emerging Technologies Toolkit (ETTK, 2002). However, the direct way to get the capability of a Web service is to dynamically invoke it. An efficient dynamic Web services invocation mechanism is essential to correct capability matching results.

Figure 4 illustrates a sample advanced Web services discovery portal using Business Explorer for Web Services (BE4WS) (Zhang, 2003a) and WSIL Explorer, which are part of ETTK (a.k.a., Web Services Toolkit) (ETTK, 2002). You can specify the Web services sources and search criteria as well as aggregation operators. A developer can also use this portal to generate compound query (e.g., UDDI Search Markup Language search script) automatically based on a wizard. For example, a search key word "Web OR Stock" included in service names is used to construct a compound query that is used by the federated Web services discovery engine to search within one UDDI registry and one WSIL document.

BE4WS based Federated Web Services Discovery Portal

Result Pages -- Result Category

Find Service Results

Your query returned a total of 3 matched services. Press the New Search button to search again.

Registed Services: Results 1-3 of 3
Service Name	Description	Key	Operator
UDDI Web Services	UDDI SOAP/XML message based programatic Web services interfaces	33c3d124-e967-4ab1-8f51-d93d95fac91a	Microsoft Corporation
UDDI Web Sites	UDDI Registry Web Sites	86e46aad-82a5-454f-8957-381c2f724d6f	Microsoft Corporation

Where 1 results of 3 is/are from WSIL
Item#1	Service Name	WSDL URL
1	StockQuote Service	stockquote.wsdl

New Search

Figure 4: Advanced Web Services Discovery Portal.

The example search result in Figure 4 demonstrates the retrieved Web services. Two of them are returned from one UDDI registry operated by Microsoft and the other one is retrieved from a WSIL document.

Web Services Composition for Business Process Integration

A business process includes lots of components corresponding to work flow, screen flow, business rules, longtime transaction engine, etc. Companies are transforming their existing business into a manageable business process system. In the mean time, a company's proven business processes can be made available to its customers through Web services interfaces or in-house integration activities.

Aissi (2002) surveyed a few popular business process flow languages such as WSFL, XLANG, BPML (Business Process Modeling Language) and ebXML. Then, Aissi (2002) proposed a process coordination framework to leverage some existing flow specifications. There is a comparison study research report on the emerging Web services flow languages such as BPEL4WS, XLANG, WSFL and XPDL in Staab (2003). Benatallah (2003) proposed a method to compose Web services in a Self-Serv environment.

One of the key challenges of composing advanced business processes is to select services that meet business needs. With Web services, any numbers of business services are published in UDDI registries and WSIL documents, thus increasing the complexity of the provider selection process. In this paradigm, a manual way of composing business process and service provider selection through a graphic user interface is not feasible in a complex business scenario. Instead, an automated means of business process composition is required.

We have presented an advanced Web services composition framework to address the challenges above. Based on the federated Web services discovery technology, we proposed an advanced Web services composition framework, Web Services Outsourcing Manager (WSOM), which enables a dynamic composition of Web service flow based on customer requirements. A tooling flow is illustrated in Figure 5. The input of WSOM is customer's requirements. The Output of WSOM is the composed Web services flow that matches customer's requirements.

Figure 5: Web Services Composition Toolkit.

As shown in Figure 5, the customer requirements are analyzed and optimized to generate an annotation document for business process outsourcing. This service-oriented architecture allows effective searching for appropriate Web services and integrating them into one composite Web service to perform a specific task. WSOM automates the generation of scripts for searching for Web services; and it automates the process of selecting Web services by using a "pluggable" optimization framework. As a result, the business process constructed by WSOM could be adapted to different Web service flow languages, such as WSFL, BPEL4WS, and so forth. You can download the prototype of WSOM from alphaWorks (WSOM, 2002). The extensible two-level advanced composition framework of WSOM allows developers to bring any pluggable components such as Web services discovery, capability matching, service selection algorithm and output adaptors.