Web Services Conversations for B2B Electronic Commerce

Transcription

1 Lingnan University, Hong Kong From the SelectedWorks of Prof. YEUNG Wing-lok December 3, 2009 Services Conversations for B2B Electronic Commerce W. L. Yeung, Lingnan University, Hong Kong Available at:

2 Paper #P091 Page 1 of 9 South East Asia Regional Conference December December Revitalizing the Global Economy: Challenges and Strategies for Sustainable Growth Paper no. P091 Services Conversations for B2B Electronic Commerce W.L. Yeung Lingnan University, Hong Kong

3 Paper #P091 Page 2 of 9 Services Conversations for B2B Electronic Commerce W. L. Yeung Lingnan University, Hong Kong Abstract B2B electronic commerce has flourished on the Internet. On top of the Internet s HTTP protocol, trading parties need business-level protocols for automating their trading processes. This paper examines the conversational approach to specifying business-level protocols based on the web s technology. We illustrate this approach by specifying the contract net protocol in the Services Conversations Language (WSCL). Keywords: s, conversations, WSCL, contract net protocol 1 Introduction The US Census Bureau estimated that over 94% of all electronic commerce could be classified as business-to-business (B2B) in In 2007, Alibaba.com, the world s largest B2B online marketplace, went public and became the biggest technology stock market offering since Google s in Amid the current global economic downturn, information technology for B2B electronic commerce can be seen as an important means to cost-savings. For instance, British Airways has streamlined its procurement function with the help of B2B technology to achieve cost savings since 2001 (B2B News, 2007). s have emerged as a prominent technology that supports enterprise application integration (EAI) and business process management (BPM) within an organization (Lim & Wen, 2003; Zhao & Cheng, 2005; Albrecht, Dean, & Hansen, 2005). Applications from across different geographic and functional units of the same enterprise running on diverse platforms and infrastructures can be implemented or packaged as web s that are orchestrated to run according to visually defined workflow models and monitored by sophisticated business activity monitoring (BAM) tools. The web s architecture also enables the integration of BPM with B2B collaboration (Kim & Segev, 2005; Chen, Zhang, & Zhou, 2007). Enterprise applications implemented or packaged as web s are loosely coupled and can be dynamically bound together during the execution of a business process. This is most relevant to B2B collaborative processes in which business partnerships are often dynamically set up with interoperable web s running on diverse platforms, communicating and collaborating through the Internet. To use web s effectively, the interacting parties need to know and agree on the following (Hewlett-Packard Company, 2002): 1

4 Paper #P091 Page 3 of 9 Business payload Both parties need to know which information to exchange. Protocol Both parties need to know how to exchange business payload. Service location To interact with a specific, both parties need to know which protocols the supports, which payload it exchanges, and its location, e.g. its HTTP URL. In defining a protocol for two parties to exchange information, the external visible behavior of a web, i.e. its abstract interface, can be specified by the conversations that it supports, without revealing its application logic or internal (private) processes. This is the approach taken by the Services Conversation Language (WSCL) (Hewlett-Packard Company, 2002) which is a W3C standard for specifying web s. In this paper, we discuss and illustrate the use of WSCL in B2B e-commerce through an example. Our aim is to provide insights into the technology and discuss the context of its application. The next section provides some technology background on web s. Section 3 introduces the use of WSCL in specifying the contract net protocol (Smith, 1980). Section 4 gives a conclusion and discusses some alternative approaches. 2 s technology The web s architecture supports the modeling and execution of a business process workflow with languages and execution engines, respectively, designed for orchestrating web s. The Service Business Process Execution Language (WS-BPEL) (OASIS, 2007) has emerged as an industry standard supported by many vendors including IBM, Microsoft and BEA in their software products. Typically, such a product provides business analysts with graphical tools for defining workflow models and automatically translates them into WS-BPEL for execution by an orchestration (execution) engine implemented on a certain platform. The orchestration engine executes a workflow model by invoking the web s through SOAP messaging. The interface details for invoking a web (port types, operations, message types, etc.) are described and published in an WSDL document. For B2B collaborative processes, potential partners may discover one another s web s by directly exchanging WSDL documents or indirectly through UDDI registries. Orchestration of web s for a collaborative process can either be centralized or distributed. An overall workflow model can be defined for the entire collaborative process and a a single dominant partner or an independent party can be responsible for orchestrating all the participating web s accordingly. Control of the process is thus centralized under the responsible party. In the cases of distributed orchestration, partners retain control of their respective parts in the overall process and orchestrate (and manage) their own web s. Instead of having an overall workflow model, business partners first come together and agree on a protocol for their collaboration. Each partner then defines its own workflow model for its part(s) in the overall process 2

5 Paper #P091 Page 4 of 9 Service criteria UDDI Registry Service WSDL descriptions Service Requester Matched WSDL descriptions Service Provider WS BPEL Orchestration SOAP Service request message SOAP Service response message WS BPEL Orchestration WSCL Conversations Figure 1: s architecture and orchestrate its web s accordingly. A partner may also prefer not to expose the fully executable workflow model to its partners but instead only an abstract version of it. Such abstract descriptions, known as abstract processes in WS-BPEL, are not executable but contain sufficient details about the separately defined workflow (sub-)models for verifying their interoperability as well as conformance to the agreed interaction protocol. The Services Conversations Language (WSCL) (Hewlett-Packard Company, 2002) supports the definition of the abstract interfaces of web s. Its relationships with WS-BPEL and other standards is illustrated in Figure 1. 3 Specifying the contract net protocol in WSCL The Control Net Protocol (CNP) was originally proposed for a multilateral contract negotiation process through which software agents assume the roles of managers and contractors in allocating processing tasks among a network of nodes. The protocol involves three main speech acts, namely, task announcement, bid, and award. Further post-awarding speech acts include inform, interim report, complete, and terminate. For the sake of clarity, we shall consider protocol designs involving only the three main speech acts together with complete in this paper. The basic design of CNP can be described as follows. A manager agent sends details of a task in the form of a task announcement message to potential contractor agents. Those who are unavailable or unsuitable (or both) for the 3

6 Paper #P091 Page 5 of 9 Manager Contractor announcement bid award completion Figure 2: A scenario of interactions between a manager and a contractor 4

7 Paper #P091 Page 6 of 9 Announcing [Rejection] Bidding [Award] Completing Figure 3: UML statechart diagram for the contract net protocol task need not reply whereas the rest will each send a bid message to the manager agent. The latter will evaluate the received bids and select one for the task. It will then send an award message to the selected contractor agent. Finally, when the task is completed, the contractor agent sends a completion message together with the result to the manager agent. Figure 2 shows a scenario of interactions between a manager and a contractor. Figure 3 shows a UML activity diagram that formalizes the conversations among the agents from the point of view of the manager based on the basic CNP design. The process begins with the announcing of a task by the manager by sending out a task announcement message to all contractors. This is followed by the receipt of bids from contractors. For each bid, the manager sends out either a Rejection message or an Award message. Once an award is granted, the manager will wait for a completion message upon completion of the task, after which the process ends. Figure 4 shows the corresponding WSCL specification for the manager agent. The first part of the specification contains definitions of interactions between the manager and other agents. Each interaction can be of one of the following types: Empty, Send, Receive, SendReceive, and Receive. The Empty type involves no exchange of information but simply marks the start or end of the process. The Send and Receive types are one-way interactions that involve a document flowing in one direction only. The SendReceive and ReceiveSend types are two-way interactions that involve documents flowing in both directions. The second part of the specification defines how interactions are ordered in the process. The process always begins with the Start interaction and ends with the End interaction. It proceeds from one interaction to the next according to the transitions defined among the interactions. A transition may involve conditions and form loops for repeated interactions. 5

8 Paper #P091 Page 7 of 9 <?xml version="1.0" encoding="utf-8"?> <Conversation name="contractnetprotocol" xmlns=" initialinteraction="start" finalinteraction="end" > <ConversationInteractions> <Interaction interactiontype="send" id="announcing"> <OutboundXMLDocument hrefschema=" id="announcement"/> </Interaction> <Interaction interactiontype="receivesend" id="bidding"> <InboundXMLDocument hrefschema=" id="bid"/> <OutboundXMLDocument hrefschema=" id="award"/> <OutboundXMLDocument hrefschema=" id="rejection"/> </Interaction> <Interaction interactiontype="receive" id="completing"> <InboundXMLDocument hrefschema=" id="completion"/> </Interaction> <Interaction interactiontype="empty" id="start" /> <Interaction interactiontype="empty" id="end" /> </ConversationInteractions> <ConversationTransitions> <Transition> <SourceInteraction href="start"/> <DestinationInteraction href="announcing"/> </Transition> <Transition> <SourceInteraction href="announcing"/> <DestinationInteraction href="bidding"/> </Transition> <Transition> <SourceInteraction href="bidding"/> <DestinationInteraction href="completing"/> <SourceInteractionCondition href="award"/> </Transition> <Transition> <SourceInteraction href="bidding"/> <DestinationInteraction href="bidding"/> <SourceInteractionCondition href="rejection"/> </Transition> <Transition> <SourceInteraction href="completing"/> <DestinationInteraction href="end"/> </Transition> </ConversationTransitions> </Conversation> Figure 4: A WSCL specification of the contract net protocol 6

9 Paper #P091 Page 8 of 9 4 Conclusion and discussion We have considered the use of WSCL in specifying the business protocol for a B2B collaborative process. A common standard for defining business protocols is essential for global B2B electronic commerce and the conversational approach of WSCL is only one of the several alternatives. s choreography is another major approach to defining business protocols for global B2B electronic commerce. A web s choreography can be specified to serve as a contract containing a global definition of the common ordering conditions and constraints under which message are exchanged among the participants in a collaborative process (Kavantzas et al., 2005). While orchestration always represents control from one party s perspective, choreography tracks message sequences among multiple parties from a global point of view (Peltz, 2003). The Services Choreography Description Language (WS-CDL) (Kavantzas et al., 2005) is the latest effort spearheaded by the W3C to provide a standard specification language for web s choreography. WS-CDL is intended to be used in conjunction with the Service Business Process Execution Language (WS-BPEL) (OASIS, 2007) as well as other languages (e.g. Java) for orchestrating web s. The ebxml Business Process Specification Schema (BPSS) (OASIS Standard, 2006) is another choreography language. Further work is needed to integrate the various approaches to specifying business protocols with an aim to improve the interoperability of web s for global e-commerce. The would require the efforts of researchers and standard bodies such as the W3C, as well as the software industry in providing products based on the relevant standards. References Albrecht, C. C., Dean, D. L., & Hansen, J. V. (2005). Marketplace and technology standards for b2b e-commerce: progress, challenges, and the state of the art. Information & Management, 42 (6), B2B News. (2007). B2B technology saves money for British Airways. ( Chen, M., Zhang, D., & Zhou, L. (2007). Empowering collaborative commerce with s enabled business process management systems. Decision Support Systems, 43 (2), Hewlett-Packard Company. (2002). Services Conversation Language (WSCL) 1.0. ( Kavantzas, N., et al. (2005). Services Choreography Description Language Version 1.0. ( Kim, J. B., & Segev, A. (2005). A Services-enabled marketplace architecture for negotiation process management. Decision Support Systems, 40, Lim, B., & Wen, H. J. (2003, Spring). s: An analysis of the technology, its benefits, and implementation difficulties. Information Systems Management, OASIS. (2007, April). Services Business Process Execution Language 7

10 Paper #P091 Page 9 of 9 Version 2.0. Available from OS/wsbpel-v2.0-OS.html OASIS Standard. (2006, December). EbXML Business Process Specification Schema 4 Technical Specification V Available from spec/ebxmlbp-v2.0.4-spec-os-en.pdf. Peltz, C. (2003, October). s orchestration and choreography. Computer, Smith, R. G. (1980). The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver. IEEE Transactions on Computer, 29, Zhao, J. L., & Cheng, H. K. (2005). s and process management: A union of convenience or a new area of research? Decision Support Systems, 40,