part viii - b2b systemslsir b2bintegration.pdf · part viii - b2b systems 1. motivation 2. b2b...

1

©2002, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis 1

PART VIII - B2B Systems

1. Motivation2. B2B Scenario3. Architecture of a B2B Server4. B2B Models and Systems

1 . Web Services2 . RosettaNet

3 . Weblogic Collaborate4 . Other B2B Systems

5. Summary6. References

2


1. Evolution of Electronic Commerce

Business ApplicationsElectronic Data Interchange (EDI)

Internet- and WWW-ApplicationsConvergence of Computing

and Communication (http + html)

Electronic Commerce

time

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 expensiveVANs (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.

3


Classification of Electronic Commerce (1)

Physical goods

Electronic goods

B2BB2B B2CB2C

B2AB2A A2CA2C

business consumeradm

inistrationbusiness

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 catego ry 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)

4



Physical goods

Electronic goods

B2B B2C

B2AB2A A2CA2C

business consumer

administration

business

electronic trading

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:

./.

5



Physical goods

Electronic goods

B2B B2CB2C

B2AB2A A2CA2C

business consumeradm

inistrationbusinessB2B Ecommerce

supply chain managementelectronic procurementintegration of finance, insurance, accounting, logistics

-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 of the 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.

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

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.

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 back end applications into process

Ø (Semantic) B2B integration server– Software component that manages the state and execution of semantic B2B

integration by connecting to back end applications as well as to trading partnersover networks

– Has to address the complete problem space of semantic B2B integration

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 requiresessentially 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.

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

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)

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

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 B2Binteractions

-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^2problem, 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.

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 ?

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.

./.

11


• Scenario involves different roles– Consumer, merchant, supplies, shipper, bank

• Communication through standard message protocols– Merchant-supplier: PO - POA– Merchant-shipper: SHP - INVC

2. A Typical B2B Scenario

Consumer Merchant

Supplier Shipper

Bank

1: buy

2: purchase order (PO)

3: purchase order acknowledge (POA)

4: ship

5: invoice (INVC)

6: payment

7: ship (SHP)

8: invoice (INVC)

10: payment

9: status (STA)

11: invoice

12: payment

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.

12


System View of Merchant

Application B2BServer

Application

Application

SHP

INVC

PO’

POA’

SHP

INVC

INVCOK

PO

POATrading Partner 1(Merchant)

Trading Partner 3(Shipper)

Trading Partner 2(Supplier)

i

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.

13


Processing Steps of Purchase Order in Detail

R

S

R

R

S

S

R

S

S

R

A iAdapter Workflow B2B Protocol

PO’’’

POA’’’

POA’’ POA POA’

POA’

PO’’ PO POPO’

PO’

ACK

ACK

Authorization

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.

14


Process Management Example

Quote Application RosettaNetWorkflow

ERP EDI

RFQ

Q

Q_OK

Q_OK

PO

POA

RFQ

Q

PO

POA

• Complex request for quotation (RFQ) process– Several B2B protocols– Several application systems

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.

15


Functional Components of B2B Server and Their Interaction

ERP

Adapter

WorkflowManager

Audit/Tracking

Coordinator

TradingPartner Mgt.

Transfor-mation

B2B ProtocolEngine

Transport

Security

B2B Server

Merchant Supplier

PO1

2

2

3

3

4

4

5

66

PO’ PO’7

6

POA’POA’12

5

3

2

4

4

6

7

POA 7

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)

16


3. Generic Architecture of a B2B Server

Modeling Simulation Configuration Management

Adapter CoordinatorB2B Protocol

Engine

WorkflowManager

TradingPartner Mgt. Transport

Audit/Tracking

Transfor-mation Security

PersistentQueues

FileSystem Database

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.

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

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)

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.

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

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

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

The implementation of the B2B protocols requires a sequence of standard steps that are listed here.

21


Management of B2B Integration Lifecycle

Creation Advertising Agreeing Execution

Maintenance

Termination

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 bilateral 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).

22


Recapitulation

• Which are the three different process views on a B2B integrationapplications ?

• 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 ?

23


4. B2B Models and Systems

1. Web Services2. RosettaNet3. Weblogic Collaborate4. Other B2B Systems

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

Service broker Service requestor

publish

find

bind

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.

25


Web Service Stack

• Architecture for implementing web services

Transport: HTTP, SMTP, FTTP, …

Messaging: SOAP

Service Description: WSDL

Publication and Discovery: UDDI

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.

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)

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

27


Example: SOAP Message

POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/><SOAP-ENV:Header>

<t:Transactionxmlns:t="some-URI"SOAP-ENV:mustUnderstand="1">

5</t:Transaction>

</SOAP-ENV:Header><SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="Some-URI"><symbol>DEF</symbol>

</m:GetLastTradePrice></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Transport binding

Envelope

Header

Body

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.

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

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.

29


Example: WSDL Message (1)

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.

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.

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.

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

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.

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

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.

34


Example: Request Purchase Order (1)

• PIP business protocol

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.

35



• Business Transaction Dialog Specification

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 (networkcomponents). 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.

36


Structure of RosettaNet Messages

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 RosettaNetend-points, and is called a RosettaNet Business Message. A RosettaNetBusiness Message always contains a Preamble header, a Delivery Header, a Service Header, and a Service Content. Service Content comprises an actionmessage or a signal message. If Service Content is an action message, attachments may be included.

37



<!ELEMENT Pip3A4PurchaseOrderRequest ( fromRole ,GlobalDocumentFunctionCode ,PurchaseOrder ,thisDocumentGenerationDateTime ,thisDocumentIdentifier ,toRole ) >

<!ELEMENT fromRole ( PartnerRoleDescription ) >

<!ELEMENT PartnerRoleDescription ( ContactInformation? ,GlobalPartnerRoleClassificationCode ,PartnerDescription ) >

<!ELEMENT ContactInformation ( contactName? ,EmailAddress? ,facsimileNumber? ,telephoneNumber? ,PhysicalAddress? ) >

...

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.

38



• 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 chainManufacturer: 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 resel ls them to customers unchanged.Original Equipment Manufacturer: Product manufacturer of original equipment in the supply chain.

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.

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

WebLogic Collaborate provides an infrastructure platform for integratingbusiness 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.

40


Process Management in Weblogic Collaborate

• Implementing RosettaNet RFQ using Weblogic PI and Collaborate

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.

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

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.

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 archite cture 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 ?

43


B2B Integration Checklist

• Task: integrate business processes of different bussinesses using semantic B2B protocols

• Abstract Model P– Common process model and message formats

• Embedding P– B2B protocol engine, message transformation, adaptors to back-end systems

• Architectures and Systems P– B2B integration servers

• Methodology (P)– Contract establishment

44


Summary

• B2B server are the latest generation of business information systems enabling interoperability of businesses

• Adress the issue of distribution– Message-based communication between businesses

• Adress the issue of heterogeneity both at the data and process level– Message transformation– Application integration

– Distinction of B2B protocol, business workflow process and application protocol

• Adress the issues of autonomy– Trading partner management and contracts

– Security components

• Important current development– More flexible contracts and business protocols and automation of contract

establishment

45


References

• Books (background information)– P. Timmers, "Electronic commerce - strategies and models for business-to-

business trading", Wiley 2000.

• Websites– static.userland.com/xmlRpcCom/soap/SOAPv11.htm– Biztalk.org

– e-docs.bea.com/wlcollab/v1_0_1/index.htm

46


And Finally: The Big Picture

Processmodels XML

Distributedtransactions

Data integration Foundations

Databaseintegration

Web databaseaccess

TM & MQs

OTMs

EJB

Workflowmanagement

B2B servers

Informationsystems

Message transformation

Data transformation

Message representation

Canonical model

Deploymentdescriptors

Web data model

Transaction model

Process model

Predecessor ofWeb app. servers

Process vs. Dataintegration

Applications

Processmanagement

System platform

functions

objects

components

part viii - b2b systemslsir b2bintegration.pdf · part viii - b2b systems 1. motivation 2. b2b...

Documents