PART VIII - B2B Systems

Transcription

1 PART VIII - B2B Systems 1. Motivation 2. B2B Scenario 3. Architecture of a B2B Server 4. B2B Models and Systems 1. Web Services 2. RosettaNet 3. Weblogic Collaborate 4. Other B2B Systems 5. Summary 6. References 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 1 1

2 1. Evolution of Electronic Commerce Business Applications Electronic Data Interchange (EDI) Electronic Commerce Internet- and WWW-Applications Convergence of Computing and Communication (http + html) time 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 2 Electronic commerce, i.e. the activity of performing commerce supported by computer and communication systems, has two different roots. 1. The traditional approach of exchanging data between business applications (EDI). EDI has a long history in business processing, however, its application was confined to high-end applications, both high in cost and in revenue, where the communication networks were usually expensive VANs (value-added networks) dedicated to the specific purposes of EDI. Examples of this approach are finanical clearing systems of banks. 2. The "Internet" approach: the Internet merged computation and communication and made it ubiquitously available. This opened many new applications of commerce, in particular also involving private consumers and small businesses. In fact, large businesses recognized the potential of the Internet as a "serious" platform for implementing business interactions comparably late. 2

3 Classification of Electronic Commerce (1) business B2A B2B consumer A2C B2C administration business Physical goods Electronic goods 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 3 Electronic commerce is usually classified according to who are the participants interacting with each other, i.e. businesses, consumers, and administrations (or governments). This leads to the different acronyms of B2B etc. In addition electronic commerce can be distinguished according to the type of goods, in particular, whether the communication over electronic channels is used to support the exchange of physical goods, or whether the goods themselves are electronic and can be delivered electronically. The first category covers traditional forms of commerce, such as manufacturing, services etc., whether the second covers new businesses of the "information economy", such as information brokers or trading of digital goods. Of course methods for supporting the trading of physical goods, such as payment, have their applications also for electronic goods, though sometimes the approaches might differ (for example: micropayments for electronic goods). Remark: also C2C and A2A are categories of commerce, which do not appear in this more traditional classification (which is taken from documents of the EU) 3

4 Classification of Electronic Commerce (2) business consumer Physical goods B2A B2B electronic trading A2C B2C administration business Electronic goods 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 4 The computer-assisted trading of physical goods is also called "electronic trading". NEXT SLIDE If we focus on the commercial interactions regarding the trading of physical goods (including services), we come to the probably most important subclass of electronic commerce, namely B2B ecommerce or electronic business. B2B ecommerce automates interactions among businesses, that traditionally have taken place using other means of communication (in particular paper-based communication). Important subclasses of electronic business are:./. 4

5 Classification of Electronic Commerce (3) business consumer Electronic goods Physical goods B2A B2B A2C B2C B2B Ecommerce supply chain management electronic procurement integration of finance, insurance, accounting, logistics administration business 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 5 -Supply chain management: enterprises produce partial products, that other enterprises require as part of their products (e.g. extemely simplified for car production: mining of iron production of steel production of parts from the steel assembly of car parts, which are all done by different enterprises). Supply chain management requires often very tight integration ofthe business processes among enterprises in order to ensure that the supply chain works properly (e.g. the stocks are readily available for production). -Service integration: producing a product and selling it to a customer requires a number of additional services, such as finance, insurance, accounting, or logistics, which are usually not provided by the producing enterprise, but need to be tightly integrated with the production and sales processes. -Electronic procurement: enterprises require for their operation also goods, that do not constitute a part of the product, such as pencils, computers etc., and which are easily exchangeable. For this, they are trying to find vendors that provide them at the best conditions, similarly as a private consumer. This form of B2B ecommerce bears thus some similarity with B2C commerce, e.g. use of catalogues, auctions etc. It differs however in the scale of trading value. In the following we will study mainly systems for B2B commerce, supporting the integration of processes among different enterprises, such as supply chain management and service integration, which differ from other systems, which are more related to the trading of goods, such as needed for electronic procurement and B2C ecommerce. 5

6 Main Challenges for Electronic Commerce According to a study of the European Union the main challenges and risks are Intellectual property rights (IPR) Security and Confidentiality Contractual and financial issues Globalization Dissemination Interconnectivity and interoperability Interconnectivity and interoperability requires Organisational solutions (standardization) Technical solutions 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 6 The challenges that have been identified for electronic commerce relate mostly to non-technical issues, such as IPR, contractual and financial questions, globalization (multi-linguality for example!), dissemination (of the technology), that require regulations and legislations. From a technical viewpoint the main issues, that have been identified are security and interoperability. So this clearly shows, that the interoperability problem (in terms of interoperability of the information systems used in B2Bcommerce) is a central question. Interoperability problems always can be solved in two ways: -by organisational means, i.e. by defining a standard -By technical means, i.e. by connecting heterogeneous, distributed and autonomous systems technologically As we will see, both ways are important. Clearly, regarding the technical means of integration, all the technologies we have introduced in this lecture are relevant. We will see however, that there exist additional requirements, which ask for more specific solutions for B2B interoperability. 6

7 Interoperability Issues in B2B Commerce Communication: Exchange of business data over the network Transport of messages: synchronous and asynchronous communication Message contents: B2B protocol standards Message recipients: trading partners, security Semantic B2B integration Organized and automated exchange of formalized business data between trading partners access across networks preserving business data semantics Coordination: No central process management (B2B is also P2P) Communication is performed bilaterally No participant has a global view of the process Coordination of process with communication When, what and with whom to communicate Integration of backend applications into process (Semantic) B2B integration server Software component that manages the state and execution ofsemantic B2B integration by connecting to back end applications as well as to trading partners over networks Has to address the complete problem space ofsemantic B2B integration 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 7 When studying the problem of interoperability in B2B commerce we can take two viewpoints: 1. The communication viewpoint, looking at the problem of how business partners can exchange their data through messages. This requires essentially an agreement among the business partners on the way they communicate including all aspects (transport, contents, participants), but specializing from general communication protocols to specific business protocols (often to specific protocols for an industry). Using such semantically specialized communication protocols is the basis for a semantic integration of businesses. The agreements necessary for enabling semantic integration are normally captured in (industry-specific) standards. 2. The processing viewpoint, looking at the problem how to coordinate the various activities in B2B commerce (communication, local workflow processes, existing back-end systems). This requires special software, that is capable to communicate through semantic B2B commerce protocols with trading partners and to integrate back-end applications. Since these servers typically support specific business protocols, they are called semantic B2B integration servers. 7

8 Relationship of B2B to other Types of Applications B2C (business-to-consumer) Spontaneous interaction No underlying contracts Simple business relationships Otherwise similar problems EAI (enterprise-application-integration) Applications within a company Central process management Otherwise similar problems ASP (application-service-provider) Access to applications over Internet Billing per use or time period Central process management Otherwise similar problems 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 8 There exist other types of applications that share many similarities with semantic B2B integration, but lack some of the problem dimensions: -in B2C the interactions are generally much simpler -In EAI only a single orgainzation is involved, which controls the complete process -In ASP there is a strong assymmetry between the user of the applications (the client) and the server (the ASP) 8

9 History of B2B Systems Roots Standards SWIFT EDIFACT X12 Etc. Networks Value added networks, e.g. FIN for SWIFT Old, but working fine For at least 25 years Adaptation through XML From SWIFT to swiftml Early integration efforts Application extension with B2B protocols Each application communicates individually (n^2 problem) Does not scale 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 9 B2B commerce has a long history as explained earlier. Some of the standards from earlier times are -SWIFT: well-known, used for interbank clearing, supported by an own network (FIN) -EDIFACT: a European standard covering almost every aspect of B2B interactions -X12: the US pendant to EDIFACT Today also many of these standard are migrated to XML message formats. In fact, their importance lies not so much in the enconding of business messages, which is often rather intricate and was for a long time driven by efficiency considerations, but in the extremely rich semantic knowledge on the specific application domains. Based on these EDI standards there existed (and exist) solutions that support the integration of application from different enterprises through B2B protocols, which were application specific (e.g. SAP has an own business message protocol). This leads however to the usual n^2 integration problem. Another solution were EDI message converters, which could convert from various in- house formats to standard EDI formats. These don't have the n^2 problem, but given the complexity of EDI standards and the very low demand for the converters, these products generally are extremely expensive and only very large enterprises, e.g. major banks, could afford their installation. 9

10 Recapitulation Which are the characteristics of B2B ecommerce? Which are the main examples of B2B applications? What is the difference between the notions of semantic B2B integration and semantic B2B integration server? 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 10 NEXT SLIDE In order to understand the purpose and architecture of modern B2B integration servers, we first study now a typical B2B scenario with 5 participants, for handling a purchase. We assume that there exist standard message protocols for the business interactions. For example, for purchase order we have messages PO (purchase order) and POA (purchase order acknowledge). The purchase could be e.g. for a car and the merchant would be the car dealer and the supplier the car manufacturer../. 10

11 2. A Typical B2B Scenario Scenario involves different roles Consumer, merchant, supplies, shipper, bank Communication through standard message protocols Merchant-supplier: PO - POA Merchant-shipper: SHP - INVC Consumer Supplier 1: buy 2: purchase order (PO) 9: status (STA) 4: ship 5: invoice (INVC) 3: purchase order acknowledge (POA) Merchant 7: ship (SHP) 8: invoice (INVC) Shipper 12: payment 6: payment 10: payment Bank 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 11: invoice 11 Handling a purchase involves the following activities, which are performed through message exchanges 1. A buy message from the consumer to the merchant (this could be also be performed through a user interface, like a Web browser). 2. A purchase order (PO) message of the merchant to the supplier 3. The POA acknowledging the good delivery (or refusing it). We assume for the following that the delivery will be made. 4. The supplier sending a shipping order to the shipper in order to ship the good to the merchant. 5. The shipper sending its invoice to the supplier. 6. The supplier paying the invoice of the shipper at the bank. 7. The merchant sending a shipping order to the shipper for shipping the good to the consumer. 8. The shipper sending its invoice to the merchant. 9. In the meanwhile the customer may request on the status of processing his buy request. 10. The merchant paying the shipper. 11. The supplier sending an invoice for the good to the merchant (probably including the shipping cost) 12. The merchant paying the good at the bank The remaining interaction between the customer and the merchant (paying the good) is not handled electronically and thus does not show up in this scenario. 11

12 System View of Merchant i Application SHP Application Application INVC INVCOK PO B2B Server SHP INVC PO POA Trading Partner 3 (Shipper) Trading Partner 2 (Supplier) POA Trading Partner 1 (Merchant) 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 12 If we zoom into the system, that the merchant is running in order to handle these interactions, we see that it has two types of components involved: the B2B server, that handles the business protocols with the other participants and the (inhouse) business application, like inventory management or accounting. Thus the B2B server has to handle protocols on two sides: the communication with trading partners and the communication with business applications, that are typically existing (legacy) systems and that handle the business logic. The necessary protocols usually will be different! In addition the interactions between the in- and outgoing messages and the different applications need to be coordinated and are thus part of a business process. 12

13 Processing Steps of Purchase Order in Detail A Adapter Workflow B2B Protocol i PO POA R S PO PO PO R Authorization S POA POA S R PO POA S R R S PO ACK POA ACK 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 13 If we again zoom into the detailed steps that are performed just in the interaction of the merchant with the supplier when exchanging the PO and POA messages, we see the following: From the viewpoint of the B2B integration server the back-end application (an order processing application) behaves as follows: 1. The B2B system receives from the back-end system the purchase order (PO''') 2. The B2B system has in the next step to send to the backend system a purchase order acknoweldgement (PO''') This workflow is captured in the Adapter workflow. The Adapter is a wrapper for business applications, that translates message syntax and handles communication. Similarly the B2B integration server perceives the B2B protocol as a process consisting of 4 steps: 1. Sending the PO' to the trading partner 2. Receiving an acknowledge of message receipt (in order to ensure that the message was correctly transmitted) 3. Receiving a POA' message, acknowledgiong that the purchase can be conducted 4. Sending a message receipt to the trading partner Note how acknowledgements at two levels of semantics occur in the B2B protocol: one for ensuring the correct communication and one for implementing the business logic of purchase. 13

14 Process Management Example Complex request for quotation (RFQ) process Several B2B protocols Several application systems Quote Application Workflow RosettaNet RFQ Q RFQ Q Q_OK ERP EDI Q_OK PO POA PO POA 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 14 From an abstract viewpoint the B2B servers views the purchase process again differently, as shown in the workflow in the middle: It coordinates the interaction of the back-end applications with the B2B protocol. For doing so it maps the process view it has on the global application into an abstract workflow. This workflow receives from an application adaptor messages of the format PO''/PO'', which are translated from the backend-application specific format PO'''/POA'''. Similarly it maps the activities from the B2B protocol workflow into its abstract workflow. By doing this it ignores however communication specific acknowledgement messages, which are not important for the implementation of the abstract workflow. In the abstract workflow the B2B server integrates new activities, which are neither implemented by the back-end system, nor are part of the B2B protocol. It introduces an authorization activity, which checks whether the messages generated by the purchase order application are properly authorized, before it places them to the supplier. This shows how in the integration of legacy back-end applications and the B2B interaction the B2B integration server enhances existing workflows by additional business logic. This is, for example, important in order to capture the internal business processes properly in case part of them were handled manually before. For example before the introduction of the B2B integration server a specific employee culd have manually authorized all mailed purchase orders. Thus the processing of B2B integration servers can be distinguished into Communication with business partners (B2B protocol) Management of overall business workflow Communication with legacy back-end systems THIS SLIDE: This example shows that the workflow process management has to be able to coordinate processes involving multple back-end systems and B2B protocols at the same time. 14

15 Functional Components of B2B Server and Their Interaction ERP Merchant Supplier 1 PO Adapter Workflow Manager Audit/ Tracking POA Coordinator Trading Partner Mgt. Transformation B2B Server B2B Protocol Engine 3 5 Transport 2 Security 6 7 PO POA 1 PO POA 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 15 If we further zoom into the B2B server, we can identify the specific components needed for performing the necessary processing. We follow the path of the PO message from the ERP (Enterprise Resource Planning) system to the supplier. The inverse processing of the POA message is kept in bold. 1. Issueing a purchase order from the ERP system. This request is s ent to an application adaptor, that can convert the ERP specific format into an internal message format, that is understood by the B2B integration server. 2. The message, that is received, is forwarded to the coordinator, that coordinates the internal acitivites of the B2B integration server. In addition a log is kept of this step in the auditing component. The auditing component keeps track of any communication inside or outside the company, in order to produce proofs in case of later disputes. 3. The coordinator asks the workflow manager, which are the necessary actions to take and forwards then the message to the B2B protocol engine, that can interpret the B2B protocols. The workflow manager is a separate component, since it is also used to implement intra-company workflows, that are independent of the B2B integration server. 4. The protocol engine uses a trading partner management component in order to obtain the necessary information to contact the trading partner. From this it obtains the required target format (e.g. EDIFACT, Swift, RosettaNet including trading partner specific versions of them) and converts the message correspondingly using a transformation component. 5. Then the message is forwarded to the transport component. 6. The transport component checks the security conditions and obtains the neccessary security related information (certificates, authorizations, authentications, keys) from hte security component. If the security conditions are given it logs the transfer with the auditing component 7. Finally the message is transmitted over the network using one of many possible of transport protocols such as SOAP, HTTP/s or SMTP (depending on the trading partner information) 15

16 3. Generic Architecture of a B2B Server Modeling Simulation Configuration Management Adapter Coordinator B2B Protocol Engine Workflow Manager Trading Partner Mgt. Transport Audit/ Tracking Transformation Security Persistent Queues File System Database 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 16 From the previous slide the core components have been identified (the bold ones we will discussed in more detail in the following) Technically a B2B integration server builds on existing middleware technologies, such as database systems and transaction monitors to perform reliable transactions, message queues to perform reliable communication, and workflow systems to implement the process logic. On top of the architecture we find typically administrative and development tools. 16

17 Integration of Back-end Applications Back-end applications implement business semantics by processing the contents of the business messages Oracle, SAP, Baan, Domain specific applications Interface with B2B server through application adaptors that can provide a standard interface independent of application Example: provision of a queued interface Application Adaptor 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 17 17

18 Management of Trading Partners A trading partner is a legal entity that is source and destination of business messages Legal entity Contracts must be set up and followed Distinction between internal and external trading partners Internal: divisions and employees External: business partners A trading partner agreement is a legal document defining the rules of engagement between trading partners Names the trading partners References B2B protocol and business documents exchanged Defines security requirements States validity of documents "semiformal" representations for automated processing are becoming used Trading partners are characterized by attributes Name, unique identifier, physical address, network address B2B protocols supported Organizational information (divisions, ) Business information (credit rating, preferred supplier, ) Standardized representation is part of B2B standards (e.g. ebxml, UDDI) 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 18 Trading Partner Management concerns in particular the maintenance of trading partner agreements, that specify all the necessary aspects of being able to electronically interact with trading partners. They are extending conventional legal documents with technical information. 18

19 Transformation of Business Messages Business messages that are exchanged are the basic events that drive the execution of an integrated B2B process Common message structure Header: Trading partner information, Message identifier Payload: Business data to process (e.g. purchase order) Heterogeneity result from Different data types, vocabulary, data values (e.g. product identifiers, trading partner identification) in backend systems Use of common intermediate representation to avoid n^2 problem Requires mappings to and from the formats of B2B protocols and backend systems Similar techniques for data transformations as for data integration Simpler than the general data integration problem since the application domain is restricted 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 19 Different message types may occur due to the use of different B2B protocols. The problem of transforming business messages is very similar to the problem of integrating database schemas, however with some important differences: -normally the translations are one-to-one (at a schema level). So we do not have to deal with the typically problems of integrating multiple, partially overlapping schemas. -The application domains are very restricted and in businesses normally well understood, such that fewer ambiguities occur. -Integration at the data level is generally not an issue, since message instances are mapped one-to-one 19

20 Implementation of the B2B protocols B2B protocols are a defined sequence of message exchanges over the network The implementation of the B2B protocol requires sources and targets for the business messages (trading partners) Implementation requires Protocol-compliant behavior (send POA if PO has been received) Acknowledge receipt of messages (sequencing) Creation protocol-compliant messages Packaging of message (header and trailer information) Encryption and signatures Relay over transport protocol 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 20 The implementation of the B2B protocols requires a sequence of standard steps that are listed here. 20

21 Management of B2B Integration Lifecycle Creation Advertising Agreeing Execution Maintenance Termination 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 21 This slide illustrates the development lifecycle for integrating B2B systems. In the first step the B2B integration application needs to be created. The creation of the B2B application includes process modelling, definition of message transformations, trading partner definitions, and configuration of B2B protocols and application adaptor configurations. For doing this normally B2B integration tools are available. Once an application is made interoperable over B2B platforms, the next step is advertising. This is done through a public directory. The announcement of a service consists of a description of the organisation offering the service, the properties of the service and the technical specification of the service, i.e. its interfaces. Problems in publicly announcing services may occur with regard to the trustworthiness of the organizations offering a service or the spamming of public directions offering services. The solution to that are bi-lateral trading partner agreements that allow to identify trustworthy business partners in the service selection or long- lasting business relationships. Once a service is selected, the involved business partners move to an agreement phase: in this phase a negotiation is performed (in order to settle open servcie parameters) and as a result a formal contract is established. Opposed to the advertisement phase this phase requires a security infrastructure for authorization, authentication and non-repudiability of established contracts. After the agreement is established the service can be executed and after successul execution (or failure) the life cylce terminates eventually. During the lifetime the B2B integration application is continuously maintained. Data structures and mappings need to be adapted to changes in the involved systems (which requires versioning support for all datastructures and mappings) and before services are executed, they are tested, e.g. through simulation or the sending of test messages. The results of the maintenance operations continuously influence both the advertising of the services and the decisions taken in negotation (e.g. considering changing service qualities of business partners). 21

22 Recapitulation Which are the three different process views on a B2B integration applications? What are the differences in the role of the B2B protocol engine, the coordinator and the WFMS component in a B2B integration server? Which information is managed by the trading partner management in a B2B integration server? Why can we consider business message transformation as a problem that is similar to database schema integration, and why can we consider it as a simpler problem? What are the two basic structural elements of a business message? 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 22 22

23 4. B2B Models and Systems 1. Web Services 2. RosettaNet 3. Weblogic Collaborate 4. Other B2B Systems 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 23 23

24 4.1 Web Services Distributed computing model based on asynchronous messaging (XML) Support dynamic application integration over the Web Service-oriented architecture Service provider publish bind Service broker find Service requestor 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 24 The Web service model for B2B interoperability is a relatively simple model for application interoperability. Is has recently become very popular in particular through its role for the.net platform by Microsoft. Web services are self-contained, self-describing, modular applications that can be published, located and invoked across the Web. Web services are platform and implementation neutral. They can be anything from simple requests to complex business processes. We may consider Web services as an infrastructure for advertising and using request/reply protocol based services through a message-based interface. The three components of a Web service architecture are: 1. The service providers that publish available services and offer bindings for services 2. The service brokers that allow service providers to publish their services (register and categorize). They provide also mechanimsm to locate services and their providers 3. The service requestor that uses the service broker to find a service and then invokes (or binds) the service offered by a service provider. 24

25 Web Service Stack Architecture for implementing web services Publication and Discovery: UDDI Service Description: WSDL Messaging: SOAP Transport: HTTP, SMTP, FTTP, 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 25 Web services build on different basic communication mechanisms, that can be viewed as a protocol stack, where each higher level protocol builds on the lower level protocol: The web service transport layer is responsible for the basic communication between web services and builds on existing Internet (application) protocol standards The messaging layer uses the XML-based Simple Object access Protocol for exchanging messages in a request/reply fashion in a distributed environment The description layer allows describing interfaces of web services including operations and their parameters. The descriptions are based on the XML-based WSDL standard (Web Service Description Language) The publication and discovery layer provides the mechanisms for the service brokers. This layer is based on the Universal Descritpion, Discovery and Integration (UDDI) standard, a standard that defines XML-based service AND business descriptions, and a SOAP-based standard API to interact with the service broker. 25

26 SOAP Simple Object Access Protocol Lightweight messaging framework based on XML Supports simple messaging and RPC SOAP consists of SOAP envelope construct: defines the overall structure of messages SOAP encoding rules: define the serialization of application data types SOAP RPC: defines representation of remote procedure calls and responses SOAP messages consist of Envelope: top element of XML message (required) Header: general information on message such as security (optional) Body: data exchanged (required) 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 26 SOAP supports both simple messaging and RPC. It can be used over any transport protocol layer (such as HTTP, SMTP). For implementing Web services RPC-based SOAP messages are used 26

27 Example: SOAP Message POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" Transport binding Envelope <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" Header SOAP-ENV:mustUnderstand="1"> 5 </t:transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> Body </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 27 The transport binding of this sample SOAP message consists of the http header for submitting this message through HTTP as request. The envelope is the mandatory top- level element of any SOAP message. The header relates to information on authentication, transaction management, payment etc. needed for processing the message. This example shows of how the header is used in order transmit certain transactional properties that are required for the service invocation. The body contains the request, which consists of the invocation of a method GetLastTradePrice using a parameter with name symbol. 27

28 WSDL Web Service Description Language Abstract specification of the messages and operations of a service that is accessed using SOAP Operations offered Messages for each operation Data types for parameters and return values Endpoints where the service is accessible A WSDL document consists of Types: data types to be used Messages: definition of data that is transmitted Operation: definition of an operation that is supported PortType: set of operations supported by an endpoint Binding: concrete protocol and data format for a port type Port: combination of binding and a network address Service: collection of related ports 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 28 WSDL describes web services in terms of the services offered and the endpoints that offer the services. Using the WSDL specification of a web service a client is able to construct the necessary SOAP messages in order to access the service, as well as to correctly interpret the responses. The message, operation and port type specifications are abstract, i.e. they are not bound to a specific endpoint. The combination of a binding and a network address constitute a port and a set of ports defines a (concrete) service. 28

29 Example: WSDL Message (1) 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 29 This example shows the type definition of a WSDL specification. The types are defined using the XML Schema language. Notice, that in this example the use of the <all> constructor is not essential, since there is only a single element occuring in the complex type. 29

30 Example: WSDL Message (2) 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 30 This (fragment of a) WSDL specification refers to the type definitions before. In addition it contains the specification of abstract input and output messages for the stock trader application method. The abstract port type specification combines the two messages into a port that supports as an (abstract) service exactly these two messages. 30

31 Example: WSDL Message (3) 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 31 This WSDL specification completes the example. It refers to the specification on the previous slide. In the binding it binds the port type GetLastTradePrice (which is the abstract service) to a concrete protocol, namely the SOAP protocol and thus defines the message format. In the service part the binding StockQuoteBinding (which is the abstract service definition together with a concrete transport protocol) is bound to a specific access point, given as URL, resulting in a port. This single port then constitutes the concrete service. 31

32 UDDI Universal Description Discovery and Integration Standard for describing, publishing and finding web services Still evolving Use XML-based description files for services Like WSDL, but different -> complex mapping Main components White pages: basic contact information about an organization Yellow pages: classification of organization based on industrial categorization Green pages: technical description of services offered by registered organisations Access ot UDDI Registry Standard UDDI API Web browser Data Structures Business entity: general information + business services Business services: business level description + binding templates Binding templates : access point + tmodel (service types) tmodel: abstract definition of a web service 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 32 The UDDI standard contains a number of different components for describing organizations, classifying them according to their general activities and offering the registered services. The service descriptions used are based on an abstract service specification language, that is however different from the WDSL model. The mapping between the two service models of WSDL and UDDI is intricate. 32

33 4.2 RosettaNet RosettaNet is an independent non-profit consortium of technology companies Defines open and common electronic business processes for information technology over electronic distribution channels implementation framework Interface processes (PIPs) Define business protocol and business document format Business Dictionary designates the properties for defining business transactions Technical Dictionaries provide properties for defining products and services Core processes Administration, Partner, Product and Service Review, Product Introduction, Order Management, Inventory Management, Marketing Information Management, Service and Support, Manufacturing Implementation framework (RNIF 2.0) Defines sequencing, packaging, transport binding, security 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 33 RosettaNet is standard for B2B commerce in the information technology area, that covers all aspects of B2B data exchange from the semantic specification of messages down to the implementation architecture for message exchange. In that sense it provides an alternative solution for message-based interactions to the Web service model we have seen before, together with the semantic definitions for a specific application domain. The semantic part of RosettaNet are the PIPs (Partner Interface Processes). PIPs include the specification of partner business roles (Buyer, Seller etc.), business activities involved between the roles and type, content, and sequence of business documents exchanged by the role-interactions while performing these activities. They also specify the time, security, authentication, and performance constraints of these interactions. Structure and content of the business documents exchanged is specified through XML Document Type Definitions (DTDs) and associated Message Guidelines. The specification of dictionaries can be used in order to constrain data values used to describe products and their properties. The implementation framework is comparable to what is provided by SOAP, however it is more sophisticated, in particular with respect to security support. We illustrate in the following the PIPs for the Purchase Order process. 33

34 Example: Request Purchase Order (1) PIP business protocol 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 34 This is the specification of the purchase order process as UML activity diagram. This view of the PIP is called Business Operational View (BOV). The diagram contains "activities" (the rounded boxes) and "object flows" (the rectangles), which are use to control the activity state transitions by means of a data flow. Concretely, in state RequestPurchaseOrder the action of sending a message PurchaseOrderRequest will pass control to the ConfirmPurchaseOrder activity, which passes it back through the flow of the PurchaseOrderConfirmation message to the activity RequestPurchaseOrder, which then decides upon the incoming message whether to move to the success of failure state. The <<Secure Flow>> stereotype in the boxes containing the business actions implies that the business action MUST be transported from sender to recipient in a secure way. 34

35 Example: Request Purchase Order (2) Business Transaction Dialog Specification 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 35 The Functional Service View (FSV) is the part of a PIP that specification is derived from the BOV and specifies the network component design and the interactions between the network components as they execute the PIP. The figure identifies Buyer and Seller as two RosettaNet services (network components). It also depicts the interactions between them, namely, the request and response actions and the corresponding Receipt- Acknowledgment signals. The FSV also defines the message exchange controls for each of the actions and signals involved in the dialog. For actions, this includes specification of the time within which an Acknowledgment of Receipt signal should be sent, the time within which a response to the action should be sent (if applicable), whether authorization is required to perform the action and whether a secure transport should be used to transmit the action to the recipient. 35

36 Structure of RosettaNet Messages 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 36 The individual business documents involved in a PIP (i.e., action and signal messages) are exchanged in a container that packs together other related entities such as headers, attachments and digital signatures. This container with its constituent parts is the basic unit of exchange between two RosettaNet end-points, and is called a RosettaNet Business Message. A RosettaNet Business Message always contains a Preamble header, a Delivery Header, a Service Header, and a Service Content. Service Content comprises an action message or a signal message. If Service Content is an action message, attachments may be included. 36

37 Example: Request Purchase Order (3) <!ELEMENT Pip3A4PurchaseOrderRequest ( fromrole, GlobalDocumentFunctionCode, PurchaseOrder, thisdocumentgenerationdatetime, thisdocumentidentifier, torole ) > <!ELEMENT fromrole ( PartnerRoleDescription ) > <!ELEMENT PartnerRoleDescription ( ContactInformation?, GlobalPartnerRoleClassificationCode, PartnerDescription ) > <!ELEMENT ContactInformation ( contactname?, Address?, facsimilenumber?, telephonenumber?, PhysicalAddress? ) > , Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 37 This is a (short) excerpt from the DTD for a (business) action message, illustrating of how the "semantics" of a purchaseorder is captured in detail in a DTD. 37

38 Example: Request Purchase Order (4) Excerpt from the Vocabulary 12: GlobalPartnerClassificationCode Entity Instances Carrier: Product carrier for transporting goods in supply chain. Distributor: Product distributor in supply chain. End User: Product end user in supply chain. End User Government: End user government. Financier: Financial service provider in supply chain Manufacturer: Product manufacturer in supply chain. Retailer: Product retailer in supply chain. Shopper: Product shopper in supply chain. Freight Forwarder: Product freight forwarder for transporting goods in supply chain. Broker: Representative of a third party. Customs Broker: Product customs broker in supply chain. Warehouser: Product warehouser in supply chain. Distribution Center: Product distributor in supply chain. Contract Manufacturer: The party responsible for the services rendered. Reseller: The party who buys goods from a manufacturer and resells them to customers unchanged. Original Equipment Manufacturer: Product manufacturer of original equipment in the supply chain. 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 38 This is an excerpt from the vocabulary. It shows of how the vocabulary provides for the CONTENT of attributes possible values, together with natural language explanations of their meaning. 38

39 4.3 WebLogic Collaborate B2B integration server based on BEA's Weblogic Application Server Implements collaboration spaces ("C-spaces") through C-enablers and C -hubs Supports RosettaNet 1.1 Provides a proprietary business protocol XOCP to be used as canonical model 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 39 WebLogic Collaborate provides an infrastructure platform for integrating business processes that can span multiple units within an organization, as well as multiple enterprises across the Internet. It supports multiple business protocols, including XOCP, RosettaNet, and cxml, thus providing the ability to exchange business documents in a secure manner with a varietyof trading partners. The platform consists of two main components: 1. The collaboration hub (c-hub) hosts the c-space and serves as the transportation utility for sending messages among trading partners. It performs routing and filtering of messages, conversation management, maintains a trading partner repository and performs logging. 2. The collaboration enabler (c-enabler) exists at each trading partner's site, and allows a trading partner to participate in predefined c-spaces and possibly with multiple c-hubs. It performs conversation management, process management (using WLPI), and logging. 39

40 Process Management in Weblogic Collaborate Implementing RosettaNet RFQ using Weblogic PI and Collaborate 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 40 WebLogic Process Integrator is used to compose business messages and manage their exchange in a conversation. Each trading partner who participates in the conversation in a given role must implement the workflow required for its role. The workflows encapsulate the processes required to handle the business messages in the manner expected for a given trading partner's role in a conversation. In this figure the following aspects are illustrated The business messages Two business messages, PriceAndAvailabilityQuote and PriceAndAvailabilityResponse, are exchanged between trading partner applications. The buyer and supplier roles The implication of being in a role in a given conversation is that it sends and receives only the business messages defined for it's role. For example, the buyer: Starts the conversation Sends the business message PriceAndAvailabilityQuote Receives the business message PriceAndAvailabilityResponse and processes it By contrast, the supplier: Receives and processes the business message PriceAndAvailabilityQuote Sends the business message PriceAndAvailabilityResponse Note of how the event constructure of WLPI is used in order the catch the event of incoming messages. The message transfers themselves are supported by the messaging services provided by the C-hub. 40

41 4.4 Other B2B Systems Origins of B2B servers Native implementations Extensions of Enterprise Application Integration solutions Extensions of application adaptors solutions Extensions of transformation tools for business messages (converters) Extensions of workflow management systems IBM WebSphere B2B Integrator Consists of WebSphere application server, MQSeries, MQSeries Workflow, MQSeries Integrator, App Adapters, Tivoli, Visual Age, Extricity B2B Platform (external product) VITRIA Builds on Enterprise Application Integrator (EAI) technology TIBCO Builds on message queuing technology Pulls together existing components (e.g. EAI) webmethods Focuses on bilateral document exchange among businesses 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 41 Weblogic collaborate is only one example among many different products providing similar functionalities. Some of them are listed here. It is important to observe that the specific strengths (and weaknesses) of the products are frequently related to their history. Depending on which earlier products they are built on, like EAIs, application adaptors, WFMSs, or message converter systems, the original functionalities are typically more emphasized in the B2B integration systems. 41

42 Recapitulation With which level in the Web service stack can the RNIF and the PIP of RosettaNet be compared? To which component of the generic B2B integration server architecture does the functionality covered by the UDDI standard correspond? Which aspects of business interoperability are modelled in PIPs that are not considered with the web service standards? What are the differences in the roles of C-hubs and C-enablers in the Weblogic Collaborate architecture? Which components of the generic B2B integration server architecture do each of them implement? 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 42 42

43 B2B Integration Checklist Task: integrate business processes of different bussinesses using semantic B2B protocols Abstract Model Common process model and message formats Embedding B2B protocol engine, message transformation, adaptors to back-end systems Architectures and Systems B2B integration servers Methodology ( ) Contract establishment 2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmesd'informations rèpartis 43 43