Lecture 3: Middleware

Gustavo Alonso and Cesare Pautasso Computer Science Department Swiss Federal Institute of Technology (ETHZ) http://www.iks.inf.ethz.ch/

Contents Lecture 2 - Middleware

Understanding middleware Middleware as a programming abstraction Middleware as infrastructure for integration An overview of middleware platforms RPC based Object orientation Internet Messages The great divide

Chapter 2+3

IKS, ETH Zrich.

Middleware: Programming Abstractions Integration Infrastructure

Programming abstractions
Programming languages and almost any form of software system evolve always towards higher levels of abstraction hiding hardware and platform details more powerful primitives and interfaces leaving difficult task to intermediaries (compilers, optimizers, automatic load balancing, automatic data partitioning and allocation, etc.) reducing the number of programming errors reducing the development and maintenance cost of the applications developed by facilitating their portability Middleware is primarily a set of programming abstractions developed to facilitate the development of complex distributed systems to understand a middleware platform one needs to understand its programming model from the programming model the limitations, general performance, and applicability of a given type of middleware can be determined in a first approximation the underlying programming model also determines how the platform will evolve and fare when new technologies appear
IKS, ETH Zrich. 4

The genealogy of middleware

Application servers TP-Monitors Object brokers Message brokers Specialized forms of RPC, typically with additional functionality or properties but almost always running on RPC platforms Remote Procedure Call: hides communication details behind a procedure call and helps bridge heterogeneous platforms sockets: operating system level interface to the underlying communication protocols TCP, UDP: User Datagram Protocol (UDP) transports data packets without guarantees Transmission Control Protocol (TCP) verifies correct delivery of data streams Internet Protocol (IP): moves a packet of data from one node to another

Transactional RPC

Object oriented RPC (RMI)

Asynchronous messaging

Remote Procedure Call

sockets

TCP, UDP

Internet Protocol (IP)

IKS, ETH Zrich.

And Web Services? And Java?

Programming abstractions are a key part of middleware but theres more: a programming abstraction requires a good supporting infrastructure (i.e., a good implementation and support system underneath) Programming abstractions, in fact, appear in many cases as a consequence of changes in the underlying hardware or the nature of the systems being integrated Java is a programming language that abstracts the underlying hardware: programmers see only the Java Virtual Machine regardless of what hardware platform they use code portability (not the same as code mobility) the first step towards standardizing middleware abstractions (since now the can be based on a virtual platform everybody agrees upon) Web services apply existing abstractions to a specialized kind of network: the Internet. The Simple Object Access Protocol (SOAP) of Web services can be seen as a form of RPC wrapped in XML and mapped to HTTP for easy transport through the Internet
IKS, ETH Zrich. 6

Middleware as infrastructure
client process client code DCE development environment IDL server process server code

language specific call interface

client stub

IDL sources

language specific call interface

server stub

IDL compiler

RPC API RPC run time service library interface headers

RPC API RPC run time service library

RPC protocols

security service

cell service

distributed file service

thread service

DCE runtime environment

IKS, ETH Zrich.

Infrastructure for integration

As the programming abstractions reach higher and higher levels, the underlying infrastructure implementing the abstractions must grow accordingly Additional functionality is almost always implemented through additional software layers The additional software layers increase the size and complexity of the infrastructure necessary to use the new abstractions The infrastructure is also intended to support additional functionality that makes development, maintenance, and monitoring easier and less costly RPC => transactional RPC => logging, recovery, advanced transaction models, language primitives for transactional demarcation, transactional file system, etc. The infrastructure is also there to take care of all the nonfunctional properties typically ignored by data models, programming models, and programming languages: performance, availability, recovery, instrumentation, maintenance, resource management, etc.
IKS, ETH Zrich. 8

Understanding middleware
To understand middleware, one needs to understand its dual role as programming abstraction and as infrastructure for integration PROGRAMMING ABSTRACTION Intended to hide low level details of hardware, networks, and distribution Trend is towards increasingly more powerful primitives that, without changing the basic concept of RPC, have additional properties or allow more flexibility in the use of the concept Evolution and appearance to the programmer is dictated by the trends in programming languages (RPC and C, CORBA and C++, RMI and Java, Web services and XML)
IKS, ETH Zrich.

INTEGRATION INFRASTRUCTURE Intended to provide a comprehensive platform for developing and running complex distributed systems Trend is towards service oriented architectures at a global scale and standardization of interfaces Another important trend is towards single vendor software stacks to minimize complexity and streamline interaction Evolution is towards integration of platforms and flexibility in the configuration (plus autonomic behavior)
9

Middleware basics: RPC DCE Transactional RPC TP-Monitors

Basic middleware: RPC

One cannot expect the programmer to implement a complete infrastructure for every distributed application. Instead, one can use an RPC system (our first example of low level middleware) What does an RPC system do? Hides distribution behind procedure calls Provides an interface definition language (IDL) to describe the services Generates all the additional code necessary to make a procedure call remote and to deal with all the communication aspects Provides a binder in case it has a distributed name and directory service system
IKS, ETH Zrich.

CLIENT call to remote procedure CLIENT stub procedure Bind Marshalling Send

Client process

Communication module

SERVER stub procedure Unmarshalling Return

Communication module Dispatcher (select stub) Server process

11

SERVER remote procedure

From RPC we go to ...

Stored procedures Two tier architectures are, in fact, client/server systems. They need some sort of interface to allow clients to invoke the functionality of the server. RPC is the ideal interface for client/server interactions on a LAN To add flexibility to their servers, software vendors added to them the possibility of programming procedures that will run inside the server and that could be invoked through RPC This turned out to be very useful for databases where such procedures could be used to hide the schema and the SQL programming from the clients. The result was stored procedures, a common mechanism found in all database systems Distributed environments When designing distributed applications, there are a lot of crucial aspects common to all of them. RPC does not address any of these issues To support the design and deployment of distributed systems, programming and run time environments started to be created. These environments provide, on top of RPC, much of the functionality needed to build and run a distributed application The notion of distributed environment is what gave rise to middleware. During the course, we will see many examples of such environments.

IKS, ETH Zrich.

12

DCE
The Distributed Computing Environment is a standard implementation of RPC and a distributed run-time environment provided by the Open Software Foundation (OSF). It provides: RPC Cell Directory: A sophisticated Name and Directory Service Time: for clock synchronization across all nodes Security: secure and authenticated communication Distributed File: enables sharing of files across a DCE environment Threads: support for threads and multiprocessor architectures
IKS, ETH Zrich.

Distributed Applications

Distributed File Service

Time Service

RPC
Cell Directory Service DCE Thread Service Security Service

Transport Service/ OS
13

DCE architecture
client process client code DCE development environment IDL server process server code

language specific call interface

client stub

IDL sources

language specific call interface

server stub

IDL compiler

RPC API RPC run time service library interface headers

RPC API RPC run time service library

RPC protocols

security service

cell service

distributed file service

thread service

DCE runtime environment

IKS, ETH Zrich.

14

DCEs model and goals

Not intended as a final product but as a basic platform to build more sophisticated middleware tools Its services are provided as the most basic services needed in any distributed system. Any other functionality needs to be implemented on top of it DCE is not just an specification of a standard (e.g., CORBA) but an implementation that acts as the standard. Since the API is the same across all platforms, interoperability is always guaranteed DCE is packaged in a modular way so that services that are not used do not need to be licensed
IKS, ETH Zrich.

Encina (a TP-Monitor) is an example of an extension of DCE:

Distributed Applications

Encina Monitor Structured File Service Peer to Peer Comm Encina Toolkit Reliable Queuing Service

Encina

OSF DCE

15

What can go wrong here?

RPC is a point to point protocol in the sense that it supports the interaction between two entities: the client and the server When there are more entities interacting with each other (a client with two servers, a client with a server and the server with a database), RPC treats the calls as independent of each other. However, the calls are not Server 2 (products) independent New_product Recovering from partial system Lookup_product failures is very complex. For Delete_product instance, the order was placed but Update_product the inventory was not updated, or payment was made but the order was not recorded Avoiding these problems using Products plain RPC systems is very database cumbersome
DBMS
IKS, ETH Zrich.

INVENTORY CONTROL CLIENT Lookup_product Check_inventory IF supplies_low THEN Place_order Update_inventory ... Server 3 (inventory) Place_order Cancel_order Update_inventory Check_inventory

DBMS

Inventory and order database

16

Transactional RPC
The solution to this limitation is to make RPC calls transactional, that is, instead of providing plain RPC, the system should provide TRPC What is TRPC? same concept as RPC plus additional language constructs and run time support (additional services) to bundle several RPC calls into an atomic unit usually, it also includes an interface to databases for making end-to-end transactions using the XA standard (implementing 2 Phase Commit) and anything else the vendor may find useful (transactional callbacks, high level locking, etc.)
IKS, ETH Zrich.

Simplifying things quite a bit, one can say that, historically, TP-Monitors are RPC based systems with transactional support. We have already seen an example of this: Encina

Distributed Applications

Encina Monitor Structured File Service Peer to Peer Comm Encina Toolkit Reliable Queuing Service

Encina

OSF DCE
17

TP-Monitors
INVENTORY CONTROL IF supplies_low THEN BOT Place_order Update_inventory EOT Server 2 (products) New_product Lookup_product Delete_product Update_product Server 3 (inventory) Place_order Cancel_order Update_inventory Check_inventory

Products database

Inventory and order database

IKS, ETH Zrich.

The design cycle with a TP-Monitor is very similar to that of RPC: define the services to implement and describe them in IDL specify which services are transactional use an IDL compiler to generate the client and server stubs Execution requires a bit more control since now interaction is no longer point to point: transactional services maintain context information and call records in order to guarantee atomicity stubs also need to support more information like transaction id and call context Complex call hierarchies are typically implemented with a TP-Monitor and not with plain RPC

DBMS

DBMS

18

TP-Monitor Example
Interfaces to user defined services Programs implementing the services
Yearly balance ? Monthly average revenue ?

Front end

TP-Monitor environment

Control (load balancing, cc and rec., replication, distribution, scheduling, priorities, monitoring ) recoverable queue app server 3

app server 1

app server 1

app server 2

user program

user program

user program

user program

wrappers Branch 1 Branch 2 Finance Dept.

IKS, ETH Zrich.

19

TP-Heavy vs. TP-Light = 2 tier vs. 3 tier

A TP-heavy monitor provides: a full development environment (programming tools, services, libraries, etc.), additional services (persistent queues, communication tools, transactional services, priority scheduling, buffering), support for authentication (of users and access rights to different services), its own solutions for communication, replication, load balancing, storage management ... (similar to an operating system). Its main purpose is to provide an execution environment for resource managers (applications), with guaranteed reasonable performance This is the traditional monitor: CICS, Encina, Tuxedo.
IKS, ETH Zrich.

A TP-Light is a database extension: it is implemented as threads, instead of processes, it is based on stored procedures ("methods" stored in the database that perform an specific set of operations) and triggers, it does not provide a development environment. Light Monitors are appearing as databases become more sophisticated and provide more services, such as integrating part of the functionality of a TP-Monitor within the database. Instead of writing a complex query, the query is implemented as a stored procedure. A client, instead of running the query, invokes the stored procedure. Stored procedure languages: Sybase's Transact-SQL, Oracle's PL/SQL.

20

Databases and the 2 tier approach

client

database management system

Database developing environment user defined application logic

database
resource manager
IKS, ETH Zrich.

external application

Databases are traditionally used to manage data. However, simply managing data is not an end in itself. One manages data because it has some concrete application logic in mind. This is often forgotten when considering databases. But if the application logic is what matters, why not move the application logic into the database? These is what many vendors are advocating. By doing this, they propose a 2 tier model with the database providing the tools necessary to implement complex application logic. These tools include triggers, replication, stored procedures, queuing systems, standard access interfaces (ODBC, JDBC).
21

Object orientation CORBA Object Monitors

CORBA
The Common Object Request Broker Architecture (CORBA) is part of the Object Management Architecture (OMA) standard, a reference architecture for component based systems The key parts of CORBA are: Object Request Broker (ORB): in charge of the interaction between components CORBA services: standard definitions of system services A standardized IDL language for the publication of interfaces Protocols for allowing ORBs to talk to each other CORBA was an attempt to modernize RPC by making it object oriented and providing a standard
IKS, ETH Zrich.

Client (CORBA object) client stub (proxy) CORBA library interface to remote calls

Server (CORBA object) server stub (skeleton) CORBA Basic Object Adaptor

Marshalling serialization

Object Request Broker (ORB)

CORBA services
23

CORBA follows the RPC model

CORBA follows the same model as RPC : they are trying to solve the same problem CORBA is often implemented on top of RPC Unlike RPC, however, CORBA proposes a complete architecture and identifies parts of the system to much more detail than RPC ever did (RPC is an inter-process communication mechanism, CORBA is a reference architecture that includes an inter-process communication mechanism) CORBA standardized component based architectures but many of the concepts behind were already in place long before
IKS, ETH Zrich.

Development is similar to RPC: define the services provided by the server using IDL (define the server object) compile the definition using an IDL compiler. This produces the client stub (proxy, server proxy, proxy object) and the server stub (skeleton). The method signatures (services that can be invoked) are stored in an interface repository Program the client and link it with its stub Program the server and link it with its stub Unlike in RPC, the stubs make client and server independent of the operating system and programming language
24

Objects everywhere: IIOP and GIOP

In order for ORBs to be a truly universal Client component architecture, there has to be Server (CORBA a way to allow ORBs to communicate (CORBA object) object) with each other (one cannot have all components in the world under a single ORB) ORB 1 ORB 2 For this purpose, CORBA provides a General Inter-ORB Protocol (GIOP) that specifies how to forward calls from one GIOP GIOP ORB to another and get the requests back The Internet Inter-ORB Protocol (IIOP) specifies how GIOP messages are IIOP IIOP translated into TCP/IP There are additional protocols to allow ORBs to communicate with other systems The idea was sound but came too late and Internet (TCP/IP) was soon superseded by Web services

IKS, ETH Zrich.

25

Object Transaction Service

An OTS provides transactional guarantees to the execution of invocations between different components of a distributed application built on top of an ORB. It is part of the CORBA standard It is identical to a basic TP-Monitor There are two ways to trace calls: Explicit (manual): the invocation itself contains the transaction identifier. Then, when the application registers the resource manager, it uses this transaction identifier to say to which transaction it is subscribing Implicit (automatic): the call is made through the OTS, which will forward the transaction identifier along with the invocation. This requires to link with the OTS library and to make all methods involved transactional
Gustavo Alonso, ETH Zurich.

... and two ways to register resources (necessary in order to tell the OTS who will participate in the 2PC protocol and what type of interface is supported) Manual registration implies the the user provides an implementation of the resource. This implementation acts as an intermediary between the OTS and the actual resource manager (useful for legacy applications that need to be wrapped) Automatic registration is used when the resource manager understands transactions (i.e., it is a database), in which case it will support the XA interface for 2PC directly. A resource are registered only once, and implicit propagation is used to check which transactions go there

26

Running a distributed transaction (1)

1) Assume App A wants to update databases A and B 3) App A registers the database for that transaction App A App B App A App B

DB

DB

DB

DB

ORB

Register ORB db Object Transaction Service Txn has part executed in database A

Object Transaction Service 2) App A obtains a txn identifier for the operation

txn

4) App A runs the txn but does not commit at the end App A App B

DB

App A

App B

DB

DB

DB

Begin txn

ORB

ORB

Object Transaction Service

Object Transaction Service

Gustavo Alonso, ETH Zurich.

27

Running a distributed transaction (2)

5) App A now calls App B Call for Txn DB App A App B DB 7) App B runs the txn but does not commit at the end App A App B txn

DB

DB

ORB

ORB

Object Transaction Service 6) App B registers the database for that transaction

Object Transaction Service 2) App A request commit and the OTS runs 2PC

DB

App A

App B

DB

DB

App A

App B

DB

ORB Register db Txn has part executed in database B Object Transaction Service

Commit ORB txn Object Transaction Service

2PC

2PC

Gustavo Alonso, ETH Zurich.

28

The best of two worlds: Object Monitors

Middleware technology should be interpreted as different stages of evolution of an ideal system. Current systems do not compete with each other per se, they complement each other. The competition arises as the underlying infrastructures converge towards a single platform: OBJECT REQUEST BROKERS (ORBs): Reuse and distribution of components via an standard, object oriented interface and number of services that add semantics to the interaction between components. TRANSACTION PROCESSING MONITORS: An environment to develop components capable of interacting transactionally and the tools necessary to maintain transactional consistency What about Object Transaction Monitors?

Object Monitor = ORB + TP-Monitor

IKS, ETH Zrich.

29

The Internet web services

The Web as software layer (N-tier)

Browser

Web Server
Front end
app server 1

wrappers Branch 1 Branch 2

N-tier architectures result from connecting several three tier systems to each other and/or by adding an additional layer to allow clients to access the system through a Web server The Web layer was initially external to the system (a true additional layer); today, it is slowly being incorporated into a presentation layer that resides on the server side (part of the middleware infrastructure in a three tier system, or part of the server directly in a two tier system) The addition of the Web layer led to the notion of application servers, which was used to refer to middleware platforms supporting access through the Web
31

app server 1

IKS, ETH Zrich.

WWW basics
The earliest implementations were very simple and built directly upon the existing systems (client/server based on RPC, TP-Monitors, or any other form of middleware which allowed interaction through a programmable client) the CGI script (or program) acted as client in the traditional sense (for instance using RPC) The user clicked in a given URL and the server invoked the script corresponding to that URL the script executed, produced the results and passed them back to the server (usually as the address of a web page) the server retrieved the page and send it to the browser BROWSER URL response page WEB SERVER map URL to CGI script execute CGI script get results back (stdout of CGI script) prepare response page send page to browser Implemented as a normal client CGI script INTERNET

MIDDLEWARE

user program

user program

user program

user program

Existing Middleware Infrastructure

IKS, ETH Zrich. 32

Just one more layer ...

BROWSER Internet SALES POINT CLIENT IF no_customer_# THEN New_customer ELSE Lookup_customer Check_inventory IF enough_supplies THEN Place_order ELSE ... Server 1 New_customer Lookup_customer Delete_customer Update_customer Server 2 New_product Lookup_product Delete_product Update_product Server 3 Place_order Cancel_order Update_inventory Check_inventory RPC based system

DBMS DBMS DBMS

Customer database

WEB SERVER

INVENTORY CONTROL CGI script call CLIENT Lookup_product Check_inventory IF supplies_low THEN CGI script call Place_order Update_inventory ...
IKS, ETH Zrich.

Products database

Inventory and order database

33

on top of existing systems

TP Client
Yearly balance ?

TP Client
Monthly average revenue ?

WEB SERVER

Internet

CGI script calls

browser

Front end

TP-Monitor environment

Control (load balancing, cc and rec., replication, distribution, scheduling, priorities, monitoring ) recoverable queue app server 3

app server 1

app server 1

app server 2

user program

user program

user program

user program

wrappers Branch 1 Branch 2 Finance Dept.

IKS, ETH Zrich.

34

Business to Business (B2B)

FIREWALL WEB SERVER
Front end

INTERNET

FIREWALL WEB SERVER

Front end

MIDDLEWARE

Service A

Service 1

wrappers Resource X Resource Y Resource 1 Resource 2

wrappers

IKS, ETH Zrich.

MIDDLEWARE
35 36

Service B

user program

user program

user program

user program

Service 2

user program

user program

Web services
CLIENT call stubs, runtime service location SOAP system
Serialized XML doc Wrap doc in HTTP POST request

user program

HTTP support (web client)

This could be RPC, CORBA, DCOM, using SOAP as protocol

SERVER service

stubs, runtime adapters

SOAP system
Serialized XML doc

Retrieve doc from HTTP response

HTTP support (web server)

IKS, ETH Zrich.

INTERNET

user program

Messages instead of calls queuing systems message brokers

Queuing systems
client

Input queue

Output queue

Reliable queuing system Monitoring Administration Persistent storage

Input queue Output queue

external application

IKS, ETH Zrich.

Queuing systems implement asynchronous interactions. Each element in the system communicates with the rest via persistent queues. These queues store messages transactionally, guaranteeing that messages are there even after failures occur. Queuing systems offer significant advantages over traditional solutions in terms of fault tolerance and overall system flexibility: applications do not need to be there at the time a request is made! Queues provide a way to communicate across heterogeneous networks and systems while still being able to make some assumptions about the behavior of the messages. They can be used embedded (workflow, TP-Monitors) or by themselves (MQS i T d /Q)

38

Message brokers
Message brokers add logic to the queues and at the level of the messaging infrastructure
in basic MOM it is the sender who specifies the identity of the receivers

sender receiver Message processing is no longer just moving with message messages between brokers, custom locations but designers message routing logic can be can associate rules and defined at the processing steps to be message broker message broker core level or at the executed when given queue level message broker messages are moved around (e.g., transformations) The downside of this approach is that the logic associated with the queues and the messaging middleware might be very difficult to understand since it is distributed and there is no coherent view of the whole

IKS, ETH Zrich.

39

Publish/Subscribe
Standard client/server architectures and queuing systems assume the client and the server know each other (through an interface or a queue) In many situations, it is more useful to implement systems where the interaction is based on announcing given events: a service publishes messages/events of given type clients subscribe to different types of messages/events when a service publishes an event, the system looks at a table of subscriptions and forwards the event to the interested clients; this is usually done by transferring the events message into a queue for that client publish, subscribe, get, .. are also RPC calls to a resource manager
IKS, ETH Zrich.

server publish

client subscribe get

Subscription server List subscriptions for a message type Subscribe to a message type

Publish check subscriptions put in queues subscribe check subscriptions put in queues get read from queue

subscriptions

Reliable queuing system RPC support (DCE, TP-Monitor, )

40

Subscription in message brokers

at systems startup time (can occur in any order, but all must occur before RFQs are executed) RFQ processing A: subscription to message quote B: subscription to message A 1 5 6

quoteRequest

C: subscription to message newQuote at run time: processing of a request for quote. 1: publication of a quoteRequest message 2: delivery of message quoteRequest 3: synchronous invocation of the getQuote function 4: publication of a quote message 5: delivery of message quote

message broker
B 2 4 C 7

SmartQuotation adapter
3

SmartForecasting adapter
8

6: publication of a newQuote message

SmartQuotation

SmartForecasting

7: delivery of message newQuote

8: invocation of the createForecastEntry procedure

IKS, ETH Zrich.

41

The great divide

The service world

The WWW suddenly opened up software systems that had remained hidden within the IT organization of a company The nature of the interaction did not change. Behind the WWW there is the same client/server model as in basic RPC. However, the WWW made everything much easier, cheaper and efficient integration at the level of user interface became possible services could be accessed from anywhere in the world the clients could now be not just an internal or selected user but anybody with a browser
IKS, ETH Zrich.

Browser

WEB SERVER
Front end
app server 1

app server 1

wrappers Branch 1 Branch 2

MIDDLEWARE
43 44

user program

user program

user program

Remote clients
client stored procedure client embedded SQL client browser XML FIREWALL WEB SERVER

user defined application logic

API
user defined application logic

API

database
resource manager

database
resource manager

database management system IKS, ETH Zrich.

user program

Business to Business (B2B)

FIREWALL WEB SERVER MIDDLEWARE
Front end

FIREWALL INTERNET WEB SERVER

Front end

wrappers Resource X Resource Y Resource 1 Resource 2

wrappers

IKS, ETH Zrich.

The next step ...

The next step in that progression leads immediately to the notion of Web services as an extension of existing RPC middleware. The notion of service in the conventional middleware is now translated into the notion of Web service based on the access channel to that service (the service in fact can be a pre-existing middleware service, e.g., stored procedures in databases made available as Web services) The only thing that changes from the middleware and enterprise application integration world is that a few details need to be changed so that they match the needs of exchanges through the Internet rather than a LAN: XML as the data representation format SOAP as a protocol wrapper to allow conventional communication protocols of middleware platforms to cross the Internet and firewalls (essentially turns invocations into document exchanges) WSDL as the XML version of IDLs (plus a few other things) UDDI as the WWW version of basic name and directory services

IKS, ETH Zrich.

MIDDLEWARE
45 46

Service B

Service A

Service 1

user program

user program

user program

user program

Service 2

user program

user program

user program

user program

The message world

IKS, ETH Zrich.

47

Documents rather than methods

When exchanges occur as documents, the emphasis is no longer on the mechanisms for sending and receiving documents (there are many to choose from) but on the contents of the documents and how to interpret them. The arrival of documents is not a function or a method call. It is not even a service request as such but one element of a business process. Hence, in addition to specifying the format for the documents and the semantics for the contents of the documents, it is necessary to agree on what documents are needed to get things done, i.e., the business process that defines the interaction between the participants. The basic document exchange standard is the Electronic Data Interchange (EDI), a set of common data format standards developed in the late 1970s. EDI is a collection of basic data elements (e.g., a price) that can be combined to form composite data elements, which are then combined into functionally related units called data segments (e.g., the complete description of an item), and finally grouped into transaction sets (minimal meaningful unit for document exchanges between companies, e.g., an invoice or a purchase order) Additional standards (EDIFACT, X12) describe how to use transaction sets as part of concrete business processes.
IKS, ETH Zrich. 48

Processes rather than service calls

The xCBL 3.5 ChangeOrder document is a buyer-initiated document that can be used to change an existing Order already received and responded to by a seller. The document can be used to make changes to header level information, change line items, cancel line items, add line items, etc. Note that if an OrderResponse has not been received for a given Order, a ChangeOrder is not necessary (an Order with a purpose of Replace should be used). Similarly, if an entire order is to be cancelled (regardless of whether a response has been received or not) an Order with a purpose of Cancellation should be used. xCBL 3.5 Order Management Recommended Use, Version 1.0 November 19, 2001
IKS, ETH Zrich. 49

The next step ...

The next step for message based electronic commerce is to take advantage of the Internet to improve electronic commerce: e.g., ebXML and the many attempts at producing an XML version of EDI. Note, these efforts also include linking to the standardization efforts around XML and Web services. However, the final goal is still the standardization of business exchanges rather than the standardization of the low level mechanisms used to implement those exchanges. With this interpretation, there is no client server flavor to the exchanges. Business interactions occur between trading partners Middleware architectures are not obvious in these proposals. One assumes they are there to implement the business processes but they do not determine the specification of the exchanges There is much concern with the semantics of business exchanges than with the syntax (unlike in the Web services architecture which is purely syntactic) Many concepts that are unknown in the Web service architecture play an important role in these architectures: role of the participant, business agreement, automatic enforcement of business agreements, conversations, business protocols, integration of business processes, etc.
IKS, ETH Zrich. 50