Federated Application Integration with Web Services Case of

Federated Application Integration with Web Services: Case of Multi-Participant Cargo Transportation Haoxiang Xia Japan Adv. Inst. Sci. &Tech. Shuangling Luo Dalian Univ. Tech. Taketoshi Toshida Japan Adv. Inst. Sci. &Tech.

Outline A real-world application case: multiparty shipments tracking with Web Services n Current Efforts of Web Service integration (composition, orchestration, choreography…) n Federated Application Integration Model with Web Services n

Application Case: Multiparty Shipments Tracking Scenario: inquiring Transport Agent Coordinated by a transport agent, User (cargo owner) multiple cargo coordinating transportation companies collaboratively Transport Process freight a bunch of cargos, from one participating city to another, or from one country to another. Transport/Inventory Service Providers

WS-based Solution Browser-based Query Interface Cargo owner Status report WS A Shipments Tracking System of Company A Cargo Status DB Status report WS B Shipments Tracking System of Company B DB updater Transport Agent Status Listener … Status report WS n Shipments Tracking System of Company n

Reporter-Listener Mechanism Reporter-Listener mechanism for Interactions between WS of Transport Service Providers and the Transport Agent Cargo Status Tracking System of a participator Status Report Generator: XML -based Doc. Status Reporter JAXM-based Listener: Handling response or fault Status Report WS JAXM-based Listener: receiving status change info DB Updater Error? Error Msg Generator Status Listener

Observations from the Example Facing a single company 1) From business point Transport inquiring of view, this Agent User (cargo owner) example implies the coordinating Web Service support for a Transport Process virtual A Virtual Enterprise enterprise participating Invisible to user Transport/Inventory Service Providers

Observations from the Example (cont. ) 2) From technology point of view, the key problem to support virtual enterprises is the interorganizational IT application integration, or “Business-to-Business Integration” (B 2 Bi). In the case of Web Services, the major challenge is inter-organizational Web Services integration.

Observations from the Example (cont. 2) Requirements: • interoperable – Services should be easy to interconnect with each other to complete the overall goal; • Adaptable to changes of business processes – currently supports long-running processes, short-running inter-organizational processes need to be supported too. process prone to change in temporary collaborations, e. g. , Ø new company participate an existing virtual enterprise; a company leaves the integrated process; or, the integrated process ends

Current Efforts for WS Integration Two families of work: 1) Composite Ws description in the Semantic Web Services community, e. g. DAML-S/OWL-S; 2) Web Service Orchestration and Choreography Collaborative BPEL 4 WS Abstract Processes Protocols Executable Processes BPEL 4 WS Executable Processes WSCI BPML Source: C. Peltz, 2003 (HP White Paper)

Current Efforts: OWL-S Composite Processes The Process Ontology of OWL-S describes the construction of composite processes Source: www. daml. org

Current Efforts: BPEL 4 WS is a typical example of the Web Services Composition technologies in the WS Orchestration and Choreography community. • Proposed by IBM, Microsoft, and BEA; • Combine and extend XLANG (Microsoft) and WSFL (IBM) • Essentially describe syntax of WS interactions • Follow a centralized orchestration model of WS composition and integration --- the integrated process is edited in a central control point and executed by a BPEL Engine, which invokes the participating Web Services.

Current Efforts: BPEL Centralized Orchestration Model of BPEL (Source: BPEL 4 WS Introduction article at IBM alphaworks, 2003) BPEL Execution Engine

Limitations in Current Efforts All the work essentially aims at describing WS interactions at the coding level (e. g. describing how a message passes from one service to another, as well as the execution sequence of a series of services for completing a specific task or process); BPEL and BPML imply a central control model for WS orchestration; WSCI declares to support more collaborative mode of WS interactions, but it itself does not provide the underpinning mechanism of how to support collaborative interactions.

Federated Application Integration with Web Services: Infrastructure interfacing App 1 WS 1 The Web of Services The Internet publishing App 2 WS 2 App 3 WS 3 ? Serve for users (user groups) as simple or composite services

Basic Ideas of FAI Inter-organizational integrated processes are formed from bottom up by the participating organizations: • Each organization takes the full responsibility of simple and composite Web Services (processes) bounded to it; • Recursive composition of composite processes from simple operations, using BPEL 4 WS, WSCI or OWL-S; • Decentralized orchestration of Web Services /processes for inter-organizational processes. “Federated” integration means: 1) each organization manages and runs its own Services /inner-processes; 2) Simultaneously, it participates interactions with others

Recursive Service Composition In business process modeling, the fundamental elements are “actions” ( in WSCI term) or “atomic processes” (in OWL-S term), which can be embodied as an executable “operation” of a Service. Composite processes are comprised of a series of actions from some control construct ( basically “Sequence”, “Split”, and “Cycle”…) --- thus, the structured programming model is applicable for constructing a composite process: simple actions group into a module or composite process, composite processes form larger composite processes…

Recursive Service Composition Observing from outside, composite and simple processes are not distinguishable

Decentralized Inter-Organizational WS Orchestration 1 Participating organizations publish simple and composite services (processes) so as to potentially be used by the collaborators; 2 Composite services can be comprised of internal services, and they can also be comprised of internal and external services (services that are from another organization); 3 Central control point is replaced by multiple orchestration points that are respectively owned and maintained by the participating organizations.

Decentralized WS Orchestration: Demonstrative Example Composite WS B 5 Company A WS A 1 B 1 WS A 2 The Internet B 2 B 3 B 4 Company B Orchestrated Process A 3 A 1 B 5 A 3 Orchestrated Process C 2 A 3 Runtime Engine at Company A WS C 1 Runtime Engine at Company C

Further Considerations for FAI For business process integration, the key concept is that each participating company takes the responsibility of its own parts of the overall process; and the overall process is then formed from bottom up. Each company maintains the interactions with the companies that directly interact with it, ignoring those not being directly connected. Flexibility and Agility of the entire process would be increased, comparing with the centralized orchestration model; more suitable for temporary organized virtual enterprises or communities.

Further Considerations for FAI Company A Find a new collaborator B 1 WS A 2 The Internet B 2 B 3 B 4 Company D Company B Orchestrated Process A 3 A 1 B 5 A 3 Influenced Orchestrated Process C 2 A 3 WS C 1 Influence extends to Company C

Further Considerations for FAI The leaving of Company B in fact influences its direct collaborator (Company A). Company C needs do nothing. When Company A recovers the Process A 3, the entire process is recovered too. This concept resembles the localization principle of programming – try the most for avoiding local changes spread to the global structure.

Concluding Remarks Current work is at a very primitive stage, just on conceptualization. • Test with more realistic application fields (medical information systems) • Implementation of the entire framework. Øfor WS interactions, existing technologies of SOAP WSDL WSCI BPEL 4 WS are applicable. Ø need to integrate with data transfer standards, connects to eb. XML, Rosetta. Net, …? Ø consider Inter-organizational mutual “understandings” of WS, at syntactic, semantic, and pragmatic levels?

Thank you! Questions and Comments, please.