1-4244-1496-2/07/$25.00 ©2007 IEEE

STANDARDIZATION OF BUSINESS-TO-BUSINESS ELECTRONIC EXCHANGES

Mostafa Hashem Sherif AT&T, MIDDLETOWN, NEW JERSEY, USA

This paper is a review of the history of business-to-business exchanges (e-business) from the perspective of standardization. The starting point is EDI (Electronic Data Interchange), which has continued to thrive even as web applications have increased their popularity. We then discuss the various approaches to assure EDI security on open networks, because they are gradually displacing private networks for transport. We also discuss the various ways for migrating existing EDI applications to new interfaces based on XML (Extensible Markup Language) and web service. Finally, we give an assessment of the evolution of e-business standardization.

Introduction -business is a set of measures to dematerialise the flow of exchanges among business entities to increase the efficiency and decrease operational costs. It started originally with procurement and logistics and then expanded toward other areas under the influence of just-in-time production and globalization. In addition,

enterprise restructuring to focus on core competencies and to outsource non-essential functions have extended the communication needs of business entities. Finally, Internet has stimulated new forms of e-business, especially for fragmented markets such as for restaurant business. In particular, on-line catalogues have facilitated the search for suppliers and the localization of goods or services.

The growth of e-business has highlighted the need for a uniform architecture for the supply chain, even as it integrates existing enterprise information systems. This paper summarizes the status of business-to-business electronic commerce from a standardization view point. It is not intended as a comprehensive survey but as an introduction to the main ideas to help readers find their ways.

Classification of E-Business Platforms Business-to-business exchanges depend on the nature of the supply chain. This chain is called vertical if the procured goods intervene directly into the production and horizontal if they cover several industries, in which case the goods are labelled as indirect. In the first case, the purchases are called strategic while in the second case they are for maintenance, repair and operations (MRO). Another criterion of distinction is the duration of the contracts among commercial partners, long duration for daily production or temporary for emergencies. Thus, by taking into account the two criteria of urgency of need and the strategic aspects of goods and exchanges services, there are four types of platforms for business-to-business electronic commerce: the exchanges for excess inventory, EDI systems, MRO hubs and the generalist catalogues.

The traditional form of e-business exchanges is EDI (Electronic Data Interchange). EDI is a structured way to represent administrative, commercial or transport documents as alphanumeric language strings with the help of standardized conventions (Gikins and Hitchcock, 1988). It focused on the purchase of strategic goods directly related to the chain of production or of service creation in a specific sector (automotive, chemistry, steel). Non-strategic purchases (equipment and office furniture, travels, etc.), which often represent the large bulk of the volume purchases, remained managed in a traditional way. With the growth of the Internet, many attempts have been made to fill this gap through e-procurement with online exchanges, MRO hubs, or yield managers. In these new platforms, access to the applications is through a web client and all participants (suppliers and consumers) agree to open their information systems. Exchanges are neutral platforms that do not favour either the buyer or the vendor; in contrast, in MRO hubs their suppliers are selected according to criteria that the buyer specifies, while yield managers bring together buyers and sellers through a catalogue or auctions. The latter mechanism constitutes a

E

194

SIIT 2007 Proceedings

prized method to link offer and demand and to determine the price and such an intermediation has had a fleeting popularity within the deregulated sectors (telecommunications, energy, etc.) (Sherif, 2004; 2007).

The evolution of the traditional EDI into these new forms is illustrated in Figure 1.

Figure 1. Evolution of platforms for e-business.

Even though streamlining internal process can reduce costs by at least 20% (Sivori, 1996), four main

factors slowed the spread of e-business. The first is the complexity of the set-up. In the mid-1990’s, despite the expected benefits of automated procedures, the rate of penetration of the traditional EDI in industrialized countries varied between 1% in the United States to 5% in some European countries (del Pilar, 1992 ; Landais, 1992). Within the countries of the European Union, traditional EDI is mostly used for intranational business, with applications directed toward intrasector transactions, in which the risk of litigation is at a minimum. They can be found in the banking sector, in transportation, retail distribution, aeronautical manufacturing and earlier, the automobile industry. The second factor concerns the uncertainties regarding the performance of the transport network with respect to reliability, availability and security. Security covers that of the network using well-established techniques (firewalls, monitoring, passwords, etc.) as well as the security of the messages. These are the services of identification, confidentiality, integrity, authentication and nonrepudiation. In addition, surveillance of the network and monitoring of the exchanges allow tracing of the trajectory of transactions (with the help of acknowledgments) and collection of data that can be useful in evaluating the performance of the system. This set of expertise is usually not readily available in small and medium enterprises. The third factor is the absence of standards and/or their proliferation. The fourth is the legal status of contracts and the evidentiary values of dematerialized documents.

Standardisation needs for e-business can be viewed from a technical viewpoint and from a managerial viewpoint. From a strictly technical viewpoint, the technology to exchange workflow information covers the following elements:

• The format and content of messages exchanges • The protocols that manage the exchange of electronic files • The nature of the telecommunication networks • The information technology platform of the exchanges. The management aspects cover: • Service offers (cataloging, order taking, payment, billing, logistics, etc) • Policies for flow control (purchase policies, traceability of orders, merchandise reception, security) • Management of electronic documents (archival, retrieval, backup) • Management of legal responsibilities. In some professions (notaries, bailiffs, etc.), it is essential to

ensure integrity and to preserve the archives for the duration defined by law. Data directly or indirectly related to financial results must likewise be retrieved in case of financial or legal audit.

Standardization covers all these aspects as well as their security. We shall now present the various standards for business-to-business communications. We start with standards for the exchange of structure alphanumeric records, which is the traditional way of e-business. Next, we discuss possible standards for taking advantage of the capabilities of the Web in business communications.

Standardization of Electronic Exchanges

195

Structured Alphanumeric Data There are two standardized ways for exchanging structured alphanumeric data, namely, X12 and EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport). X12 is the structuring method most frequently used in North America (United States and Canada), whereas EDIFACT is the norm in Europe and the rest of the world. The differences between them reside in the definitions of the various data elements, the syntax rules, as well as the procedures employed to secure the exchanges.

Secure X12 transmissions use the security structures defined in X12.58 issued in December 1997. X12 can directly utilize the X.509 certificates delivered by a certification authority. Security of EDIFACT follows ISO 7498-2 (1989) and outcome of the European research program TEDIS (Trade Electronic Data Interchange System) which lasted from 1988 to 1994. The services offered are message integrity, authentication of the origin, and nonrepudiation (at the origin and at the destination). Confidentiality is not offered explicitly, but may be constructed with the other services. EDIFACT security services can be offered in two ways: by sending security segments "in band" using ISO 9735-5 (2002) or "out-of-band" with ISO 9735-6 (2002). The security mechanism of X12 gives the same protection to all parts of a transaction. This is a difference with EDIFACT services that offer a finer resolution and permit the possibility of according to the different fields of a transaction different types of protection.

The management of EDIFACT certificates (inscription, renewal, replacement, revocation, delivery) as well as the generation, distribution, and management of keys is defined in ISO DIS 9735-9 (2002). It should be noted that the EDIFACT certificates are different from X.509 certificates both in their format and in their method of management. However, a DEDICA (Directory based EDI Certificate Access and Management) gateway allows access to secure EDI with X.509 certificates.

Security of EDI Messaging Systems X.400 series of recommendations could, at least in theory, offer all the necessary security services: identification, authentication, integrity, confidentiality, and nonrepudiation of the origin. In addition, an X.400 implementation is required to offer some basic security services, the most important of which are:

• Access management • Time-stamping of messages • Message sequencing to correlate later notifications with each originating message • Message content type indication and content type of attached objects • Nondelivery report The architecture of these security services is available in Recommendation X.402. Adaptations of X.400

messaging to EDI were defined in 1991 through Recommendation F.435/X.435. An enterprise that already uses the Internet for messaging and internal distribution of documents is

obviously interested in reusing it for its EDI applications. Thus, the various MIME (Multipurpose Internet Mail Extensions) implementations will have to conform to the complete specifications defined in RFCs 2045 through 2049 (1996). The encapsulating protocol of RFC 2046 is compatible with the basic messaging protocol SMTP that is on top of the TCP/IP layers. This encapsulation allows the inclusion of different object types as well as the transmission of non-ASII text ASCII.

By adding security services, Internet messaging systems have caught up with most of the X.400 functions, with a few exceptions regarding authentication of the route and the guarantees on the delivery times. The outlines of the various IETF proposals are as follows (RFC 3335, 2002):

• The sending organization sends the encrypted data and the signature of the message (message digest encrypted with the sender's private key) in an envelope constructed according to PGP/MIME, S/MIME (Secure Multipurpose Internet Mail Extensions), or S-HTTP (Secure HyperText Transfer Protocol) and requests and acknowledgment.

• The recipient organization recovers the symmetrical encryption key and its parameters (for example, the initialization vector) with its private key, decrypts the message, checks the signature with the public key of the sender, thereby verifying simultaneously verifying the integrity of the data and the authenticity of the sender.

The recipient sends back a signed acknowledgment by encrypting its digest with the recipient's private key; the acknowledgment, in turn, contains the digest and the identifier of the received message.

Figure 2 summarizes the different protocol stacks for EDI messaging without security while Figure 3 depicts a synthetic view of the protocol stack for a secure EDI.

196

SIIT 2007 Proceedings

MIME (RFC 2045)

SMTP (RFC 821)

TCP

IP

X.400

X.420/X.435 (P2)

X.411 (P1)

X.25

X.214-X.216

EDIFACT/X.12

XMLMIME/EDI

(RFC 1767)

Figure 2. Protocol stacks for EDI messaging (without security).

Structured Documents or Forms Structuring the dialogues as documents or forms allows consideration of all the data exchanged in the context of a commercial transaction, independent of their format (text, graphics, image, sound, audio, video), and not only those that can be represented by alphanumeric characters. Thus one can speak of Electronic Form Interchange instead of Electronic Data Interchange to distinguish this approach from the traditional EDI.

Stimulated by the success of the Internet, this approach is based on XML (eXtensible Markup Language). Even though the use of XML increases the file size by at least 20% compared to the equivalent alphanumeric EDI message, many initiatives started to use that approach in commercial and industrial sections. Among these initiatives, we will discuss Commerce XM, the financial XMLs and RosettaNet.

Commerce XML (cXML) Commerce XML (cXML) is an XML derivative that Ariba introduced in 1999 for electronic market places specialized in on-line purchasing of indirect goods. The idea is to standardize access to on-line catalogues irrespective of the purchasing software through a common cXML and a uniform method to track the commands (purchase orders, shipment notices, etc.).

Financial XMsL There are many XML derivatives for coding the data used in final services (Sherif, 2004; 2007). Their proliferation has efforts for their standardization. Several organizations such as SWIFT, IFX (Interactive Financial Exchange) and the Open Application Group (OAGi) formed the International Standards Team (IST) to rationalize the international norms. ISO also published in 2002, the ISO 20022 standard to define the use of XML in financial applications with the aid of the Universal Financial Industry Scheme (UNIFI) to be commonly used in the financial industry.

Standardization of Electronic Exchanges

197

MIME (RFC 2045)

SMTP (RFC 821)

TCP

IP

X.400

X.420/X.435 (P2)

X.411 (P1)

X.25

X.214-X.216

EDIFACT/X.12

XML

MIME/EDI(RFC 1767)

PGP/MIMERFC2015

S/MIMERFC2311

ISO DIS 9735

SH

TTP

Figure 3. Synthetic view of the protocol stack for secure EDI.

RosettaNet The RosettaNet consortium was born in 1998. Its primary focus is the supply chain for the electronics industry, a sector where the legacy EDI is almost negligible, which allowed a green field start. The parties include manufacturers of electronic components (e.g., Intel), equipment manufacturers (e.g., Cisco Systems, HP, Siemens, Toshiba), system integrators, wholesale dealers (e.g., Ingram Micro), and retailers (e.g., CompUSA). By linking the information systems of all the participants of the supply chain, it becomes much easier to track the status of the supply at any moment and consequently to coordinate the production and distribution capacities of the supply chain to avoid build-ups or shortages. To align the processes used along the chain on the same reference, the description of the business processes uses Partner Interface Processes (PIPs). These are, in effect, DTDs where the objects and the transaction data models are described in XML. Using these data models, a tight integration of the supply chain is possible including integrating the enterprise resource planning (ERP) system of each party with respect to order management, forecasts, marketing plans and inventory control (Yang and Tian, 2007). Notice that because RosettaNet was started before the standardization of Web services, the specifications had to be changed to bring it in line with the work in other standard bodies to ensure the compatibility across all specifications. Note:

In 2002, the Uniform Code Council (UCC) absorbed RosettaNet. The UCC covers about 23 industries associated with public warehousing and grocery industries.

Standardization of e-Business on the Web While the volume of enterprise purchases over the Internet has expanded, EDI and private value-added networks continued to thrive and increased their revenues. In contrast, Internet-based market places floundered and their numbers have dwindled dramatically. Nevertheless, the syntax of all new industrial applications is now based on XML; therefore, exchanges structured with XML will coexist with the traditional EDI and efforts will have to be spent to ensure their integration and/or a smooth migration to new systems. Such integration can take one of three main forms: 1. Use of specialized intermediaries to provide translation services between EDI and XML; 2. Expressing existing EDI exchanges directly in an XML syntax; 3. Introducing a new architecture for business-to-business exchanges in the various industrial sectors in one of two

ways: 1) extending Enterprise Application Integration (EAI) architectures to integrate the applications in different organizations irrespective of their platforms with the help of Web services or, 2) by revisiting the architecture of the business-to-business exchanges used in the traditional EDI to exploit the capabilities of XML and Web communications. This lead to Electronic Business XML (ebXML).

198

SIIT 2007 Proceedings

The principal differences among these new architectures can be found in the following items: 1) the structure of the directories or registries of the service and the data repositories of the elementary data elements, 2) the nature of the contents of the specialized libraries in terms of standards, logical components or business process and 3) the access protocols to the registries. There are many similarities between the approaches used for Web services for ebXML; the major distinction is that Web services is a bottom-up approach which makes it very useful within an enterprise while ebXML is top-down, which is more useful for the commercial transactions among different businesses (Patil and Newcomber, 2003; Yang and Tian, 2007).

Let us review now the main efforts.

EDI/XML Translation In this hybrid architecture XML a server communicates with a typical EDI converter (see Figure 4) modified to encapsulate the traditional EDI messages so that they can be displayed on a client station with a simple browser. Because the end-user sees an electronic form to be filled through a browser, this approach is sometimes called “Web EDI.” This arrangement is useful for those that have previously invested in EDI and would like to be on the Web without affecting the legacy client applications. The disadvantage of this solution is that it rests on the use of proprietary formats because the interface between the client and the server is not standardized.

Figure 4. EDI/XML Integration.

XML Extensions of EDI This is a pragmatic approach relying on the conversion of existing EDI messages into XML documents. Two approaches warrant attention: xCBL and UBL.

The XML Common Business Library (xCBL) initiative was started in 1997 by software companies such as Veo Systems and Commerce One to establish a library of documents for electronic commerce. The main objective is to express EDI messages (X12 and EDIFACT) in the XML syntax. Some of the documents covered include, cost estimates, invoicing, payment, order tracking, shipment of goods, delivery, etc. The work continued after Commerce One had acquired Veo Systems and resulted in Version 3.0, approved in November 2001 and which served as the basis for UBL.

The UBL (Universal Business Language) was developed by the OASIS (Organization for the Advancement of Structured Information Standards) consortium to facilitate the production of XML schemas for business operations starting with a library of EDI templates. This language was initially promoted by CommerceNet on the basis of Version 3.0 of xCBL. The first version codifies the transposition of the X12 and EDIFACT messages associated with the cycle purchase order/invoice into their equivalent in XML schemas (Bosak, 2005). UBL is currently the only format recognized in Denmark for the invoicing of public works.

Standardization of Electronic Exchanges

199

Web Services The first approach for e-Business is through an evolution of distributing programming with a global directory accessible on the Web. This directory contains registries that refer to repositories where the partners’ profiles are stored as well as the exchange scenarios and the data dictionaries. This new architecture is represented in Figure 5. Web services the software applications in this distributed programming environment that are capable of opening the internal applications of an enterprise to the outside by establishing real time communications with other applications on the Web, irrespective of the physical or logical platforms, including operating systems or programming languages (Benslimane, 2005; Chauvet, 2002; Erl, 2004; Langlois et al., 2005). As a bottom-up approach, web services have inherited many of the concepts, models and specifications that have been very successful with object-oriented architectures: CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) or EJB (Enterprise Java Beans).

Thus, to engage in this new form of business-to-business commerce, each party prepares its software and defines its profile with respect to other partners. The following phase consists in the discovery of the potential correspondents and the negotiation of agreements with them on the semantics and the syntax of the messages, the technical interfaces and the means of achieving security. Finally, the run-time, i.e., the execution of a specific transaction, takes place according to a pre-defined “choreography.”

BizTalk® by Microsoft was one of the first commercial offers. It includes a directory for the elementary objects and the business processes, a message protocol SOAP (Simple Object Access Protocol) and a set of programming tools to develop the necessary interfaces.

Clearly, this new architecture introduces three discontinuities with the traditional EDI: commercial services are offered in an open network and are described using a standard language, the dialogues associated with the dynamic discovery of these services and the potential partners are also described with the help of standardized messages and the interchange agreements with these partners can be produced in an automatic fashion.

Web services have the theoretical capability of supporting flexible collaborative relations within the enterprise as well as among different enterprises. However, the operation of these services requires precise rules to structure the messages, to sequence the exchanges, to ensure the compatibility of the interfaces and to allow the identification of the available applications on the network. This standardization takes place within OASIS as well as within the W3C.

The main standardized protocols that regulate the web services are: • WSDL (Web Services Description Language) • UDDI (Universal Description, Discovery and Integration) • SOAP (Simple Object Access Protocol) • The security protocols for the various layers The protocols for management, presentation, orchestration, routing and delivery of message, etc. are, for

the most past, being defined and, as a consequence, are either unstable or incomplete. Figure 6 sketches their organizations in layers that are more or less defined.

WSDL (Web Services Description Language) As the name indicates, WSDL (Web Services Description Language) is a language for the description of the mechanisms used to invoke services available on the Web. It specifies the dialogue parameters and the communication protocols. In particular, four types of information are required for any given method: the methods involved for communication with the underlying programs (such as the plug-ins that the client station will need to have to establish the contact), the parameters for defining the interface, the elements in the call and the format of the response. WSDL offers in this way a uniform method for calling services.

UDDI (Universal Description, Discovery and Integration) UDDI (Universal Description, Discovery and Integration) describes a universal registry of private or private services that catalogues in a uniform way the remote components or services available online. This registry is in fact a logical structure that groups WSDL files distributed over many sites or administrative domains that must be able to talk to each other to synchronize their states. This property of UDDI aims at overcoming the difficulties due to the heterogeneity of directories by supplying a unique format and standard elements to answer requests regarding the availability of products or services, information on the purchases (prices, delivery delays, etc.) as well as the existence of substitute products. Once the services have been declared in the UDDI format, the repository will stock the description, the access point as well as the interconnection contract. This contact contains the API of the service that the enterprise of the application will use to negotiate the communication parameters.

200

SIIT 2007 Proceedings

The information within the registry can be then organized according to different criteria, such as the business specialty, the vendor name or the geographic location. Other data can be related to the availability of products or services, the parameters of the sale (prices, delivery intervals, etc.) as well as the availability of substitute products. It is the responsibility of the vendors themselves to update their entries in the registry.

Figure 5. New architecture for the business-to-business electronic commerce.

SOAP (Simple Object Access Protocol) SOAP (Simple Object Access Protocol) describes the envelope for messages and requests using XML for structured communication among the different components of a Web service. This is a generalization of the Remote Procedure Call (RPC) to start the execution of a procedure on a remote server in a distributed and decentralized environment. In electronic commerce applications, SOAP messages are typically transported using HTTP (HyperText Transfer Protocol).

SOAP structures the exchanges for invocation of services in the form of requests and responses. The messages are XML documents formed of three elements: an envelope, coding rules and conventions to make remote procedure calls and interpret their responses. The envelope shows the type of message and includes declarations on the name space or additional attributes. It consists of a header and a body. The presence of the body is mandatory, while the header is optional — its supplies elements with which to interpret the exchanges without prior agreements between the two parties of a communication. In contrast, the body, which must be present, contains the elements that are needed to interpret the exchanges without prior agreement between the two parties in communication. Typically, this is related to establishing a remote procedure call for the sending of structured date among applications.

Standardization of Electronic Exchanges

201

Figure 6. Protocol stack for Web services (already standardized or being standardized).

Message Processing The routing protocol from Microsoft, WS-Routing, defines two unidirectional trajectories for the forward and return paths between two correspondents through several intermediate nodes.

Web Services Eventing (WS-Eventing) is another protocol, jointly developed by Microsoft, BEA and other companies for the publication of events and the subscription to the event notification service.

With the cooperation between IBM and Microsoft on web services, the following security protocols were also defined: 1. Web Services Trust Language (WS-Trust) 2. Web Services Secure Conversation (WS-Secure Conversation) 3. Web Services Security Policy Language (WS–SecurityPolicy) 4. Web Services Policy Framework (WS-Policy) 5. Web Services Policy Assertions Language (WS-PolicyAssertions) 6. Web Services Policy Attachment (WS-PolicyAttachment).

Table 1 summarizes the current standardization activities for the web services.

Technical Service Protocol Function Standardization Organization

Presentation WSRP (Web Services for Remote Portlets

Aggregation of contents among enterprise portals

OASIS

Process orchestration WS-BPEL (Web Service Business Process Execution Language

Description and modeling of business processes

OASIS

Choreography WS-Choreography WS Choreography Description Language (WS-CDL Web Services Choreography Interface (WSCI

The set of rules for message ordering

W3C

202

SIIT 2007 Proceedings

Transaction Web Services Transaction Framework (WSTF) WS-Coordination WS-Atomic Transaction WS-Business Activity

The mechanisms for transaction management

OASIS

Routing WS-Addressing WS-Message Delivery

Message delivery W3C

Reliability WS-Reliable Messaging Guarantees for the message delivery in the presence of failures

OASIS

Resource Management

Web Services Resource Framework (WSFM)

OASIS

Distributed Management of Services

Web Services Distributed Management (WSDM)

OASIS

Table 1. Current standardization activities for Web services.

Security The security of XML exchanges is the subject of several recommendations and technical reports from the W3C. Thus, XML Encryption allows selective encryption by identifying the sections to be encrypted with specialized tags while the processing of signatures is specified in XML Digital Signature.

The WS-Security specifications from OASIS describe the conceptual and technical basis to secure SOAP exchanges (integrity and authentication). The elements used for authentication are defined using the SAML protocol that OASIS had also defined and are sent using SOAP messages. WS-Security provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. Among these tokens are X.509 certificates and Kerberos tickets.

SAML (Security Assertion Markup Language) describes, using XML documents, user profiles and the requests for authentication before authorizing the access of an individual or an object to a given service (OASIS, 2002, 2005). It establishes equivalencies among administrative domains, each with its own policy for managing rights.

When a user identifies itself to an SAML server, the server attaches to the request a description of the user’s access rights in SAML within a Simple Object Access Protocol (SOAP) envelope to be forwarded to the server of any Web service that the user could invoke later. The SAML structures are transported using the POST method of HTTP or within SOAP messages coded in XML. Thus, with SAML, the user access profile can be propagated from one application to the other during the same session. Thus, after the initial authentication by a given domain ends successfully, the user would be able to access the resources that reside in other associated domains without the need of a new authentication; this is called Single Sign-On (SSO).

Management of encryption keys is available from W3C documents. XML Key Management Specification (XKMS) define the public key infrastructure for web services. It has two parts related to two different services: XML Key Information Service Specification (X-KISS) and XML Key Registration Service Specification (X-KRSS). X-KISS provides a client the possibility of avoiding the computational load of the security tasks such as encryption, signature, authentication, etc., by delegating them to specialized servers with large computational power. X-KRSS specifies the protocol to register data about public keys so they can be made available to all secured services on the Web.

Finally, XACML (Extensible Access Control Markup Language) defines the access rights to a web service and the ways to manage them.

Evaluation While the protocols mentioned above are independent of the operational platform use, they cannot guarantee the reliability of transport. As a consequence, they remain better adapted to the applications within enterprise networks.

It should be noted, however, that because the environment of web services is open and programmable, the policy of protection cannot be restricted to the security of the exchanges. In particular, vulnerability can arise for any failed element: XML parsers, software, unprotected data repositories, faulty operating systems, etc. Thus,

Standardization of Electronic Exchanges

203

memory overflows, the bugs in external libraries, the malicious rerouting of traffic or attacks to block access to any registry can destabilize the whole system by attacking the weakest link.

Electronic business XML (ebXML) The second approach to e-business is focused on traditional applications of EDI. This is why activities on the ebXML protocol were started jointly in September 1999 by the OASIS consortium and the CEFACT to standardize the business-to-business exchanges over the Web. The Electronic business XML (ebXML) is a variant of XML for business-to-business e-commerce. The participation of OASIS facilitates the harmonization of ebXML specifications and those of Web services.

The five parts of the standards ISO/TS 15000 defines new business-to-business electronic exchanges on the basis of ebXML. They specify the automated procedures to obtain the agreement of commercial partners on the basis of their profiles, typical exchanges (selection, buying, payment, delivery) for each industrial sector under consideration (automotive, chemistry, etc.) and objected-oriented transactions (Chauvet, 2002; Gibb and Damodaran, 2003; Patel and Newcomer, 2003).

ebXML offers two perspectives to business-to-business commerce, a business operational view (BOV) and a functional service view (FSV). With this division in mind, the work was parcelled between the UN/CEFACT and OASIS: the business processes and transactions are the responsibility of CEFACT while OASIS is primarily focused on the XML infrastructure standardization. This separation is also consistent with the reference model for Open or interactive EDI as defined in ISO/IEC 14662.

In this framework, the central repository of the traditional EDI is replaced by a distributed database on a network. The framework of reference gives scenarios for typical exchanges (selection-purchase-payment-delivery) for each sector considered (automotive, chemistry, etc.) based on which are defined the subjects of the transactions, the messages exchanged, their order in the exchange, and the role of each of the participants.

The business aspects describe the roles and obligations of organizations during the implementation, i.e., the business processes and the exchanges that take place during business-to-business transactions, the core components, which are the objects that form the founding blocks that the enterprises will use to construct their exchanges. The functional aspects relate to the profiles and protocols for collaboration, the registries and repositories and the reliable message service.

With the separation of the business from the functional aspects, the business specifications are now technologically neutral and the information mode is valid irrespective of the syntax used (ANSI X12, EDIFACT, XML documents).

The definition of the common objects in ebXML is based on UMM (UN/CEFACT Modelling Methodology), which was inspired by the object-oriented meta-model UML (Unified Modeling Language). The exchanged documents are formed from the core components with the help of business rules used in a given context. Each core component gives a specific business information entity (BIE) in a specific context, for example, in Europe; the object Tax Amount will represent the value-added tax.

The protocol profiles for collaboration describe the technical capabilities of the partners in terms of the services offered, the ways of connecting, the disciplines and expectations (for example, what is the maximum delay before an acknowledgement is sent, the maximum number of communication attempts, the configuration parameters of the communication, of the security, etc.). In principle, the technical agreements among the parties can be made automatically by comparing their collaboration-protocol profiles to identity common areas. Their agreement, known as collaboration protocol agreement (CPA), can be used in the automatic configuration of the realization.

A global repository or library of objects contains the core components. The directory catalogues all the elements stored in the global repository, i.e., business and industry-specific libraries, the profile of the partners and their collaboration protocols, the descriptions of the exchanges and the technical and/or security constraints. The registry is based on UDDI and the information is organized by industrial sector, by business process and by the technical or secure constraints. A hierarchy of dictionaries, with the CEFACT dictionary at the top level, are also used for the definition of the content of the exchanged documents. Despite the similarity, ebXML and Web services provide distinct approaches for discovery that have yet to be merged or to be made compatible (Al-Masri and Mahmoud, 2007).

To maintain the integrity of the registry, new entries go through a series of verification steps before they are accepted; out-of-date entries are taken from the registry. This cycle is under the control of the CEFACT.

SOAP is used as a message service for the different payloads. The services are those of authentication, integrity, confidentiality and non-repudiation.

Figure 7 illustrates the protocol stack used for ebXML.

204

SIIT 2007 Proceedings

Figure 7. Protocol stack for ebXML.

Table 2 compares the main properties of the traditional EDI with ebXML

Characteristic Traditional EDI ebXML Nature of the links Point-to-point Point to multipoint Interface configuration Static and manual Dynamic and automatic

Subject of standardization Messages Methods, architectures, processes, objects

Technical negotiation Manual Automatic Operation Batch Transactional Orchestration of the exchange kinetics Manual Automatic

Table 2. Comparison of traditional EDI and ebXML.

Today, ebXML does not offer yet the same coverage as traditional EDI and the tools for development are not always available. ebXML will require some time to mature, because it depends on the involvement of enterprises in supplying all the necessary blocks. Once the definition of the constituent components has sufficiently progressed, the following architectural decisions will have to be made:

• The placement of the registries, directories and repositories • The conformance of the stored components to the specifications and the validation of this conformance • The operational criteria and the guarantees on the service quality • The maintenance and the management of faults.

Summary and Perspective Automation and dematerialization of exchanges are means to improve productivity. This modifies the course of the information flows within the enterprise and helps establish collaborative relations among distinct enterprises. E-business causes a major reorientation in the ways information is managed. There are two possible ways to provide e-business on the Web depending on the starting point: whether it is the distributed computing environment of enterprise applications or the electronic commerce environment where independent entities communicate to conduct their usual transactions.

The magnitude of the investments that large enterprises have already committed to EDI, in one form or another, delays the development and large scale adoption of XML-based solutions, so long as the legacy systems satisfy the needs. No enterprise can afford to rethink its mode of operation every few months to follow the latest fashion. Without stability, it is highly unlikely that a commercial network would be able to survive. Standardization offers this stability because it requires substantial prior thinking, and discussion to obtain useful standards.

Web services are currently an active area of research and development, perhaps due to the familiarity of computer scientists to its concepts. Initial applications have been in the areas of travel and business planning. In a production environment, however, Web services are still in the introductory phase and more effort is needed to constitute a universal protocol stack that all the actors would agree on. The replacement of existing solutions will take time as the infrastructure is renewed and as new requirements arise that the legacy systems cannot meet. Some of these needs include consultation of multimedia catalogues, multimedia exchanges, and quasi-real time queries of inventories or of market status. The competition among software editors and the inflation of specifications are slowing down agreements and prevent the interoperability, which are necessary conditions for a universal business-to-business commerce. This is why standardization is essential to pull the necessary knowledge, minimize the commercial risks and to avoid ending up with a complicated architecture.

Standardization of Electronic Exchanges

205

References Al-Masri, E. and Q. H. Mahmoud, Interoperability among service registry standards, IEEE Internet Computing, 11,

3, 74–77, 2007. Benslimane, D., (Ed.), Les services webs, Revue des sciences et technologies de l’information, RSTI série ISI 10, 3,

2005. Bosak, J., UBL: A standards-based approach to ecommerce, in The Standards Edge: Future Generation, Bolin, S.,

Ed., Bolin Communications, www.thebolingroup.com, 2005, pp. 397–409. Chauvet, J.-M., Services web avec SOAP, WSDL, UDDI, ebXML, …, Eyrolles, Paris, 2002. Del Pilar Barea Martinez, M., EDI: des organismes fédérateurs pour le commerce international, Télécom Interview,

33, 12–14, 1992. Erl, T., Service-Oriented Architecture, A Field Guide to Integrating XML and Web Services, Pearson Education,

Upper Saddle River, NJ, 2004. Gibb, B. and S. Damodaran, ebXML, Concepts and Application, Wiley Publishing, Inc., Indianapolis, IN, 20003. Gikins, M. and D. Hitchcok, (Eds.), The EDI Handbook, Blenheim Online, London, 1988. Landais, Y., Les produits et services EDI offerts par un opérateur, Transpac, Télécom Interview, 33, 60–68, 1992. Langlois, M., D. Favero and M. Lesourd, XML dans les échanges électroniques, le Framework ebXML, Lavoisier,

Paris, 2005. Patel, S. and Newcomer, ebXML and Web services, IEEE Internet Computing, 7, 3, 74–82, 2003. Sherif, M. H., Protocols for Secure Electronic Commerce, 2nd ed., CRC Press, Boca-Raton, 2004. Sherif, M. H., Paiements électroniques sécurisés, Presses Polytechniques et universitaires romandes, Lausanne,

2007. Sivori, J. R., Evaluate receipts and settlements at Bell Atlantic, Commun. ACM, 39, 6, 24–28, 1996. Yang, L. and L. Tian, Research on the collaborative e-business system model, in International Conference on

Services Systems and Service Management, Changdu, China, 9-11 June 2007, pp. 1–6.

Web Sites http://www.commerce.net http://www.ebxml.org http://www.ebxml.forum.net http://www.iso.org/iso http://www.oasis-open.org/home/index.php http://www.openapplications.org http://www.rosettanet.org http://www.uddi.org http://www.udef.org http://www.unece.org/cefact http://www.xml.org

206

SIIT 2007 Proceedings