The aim of this short report is to show the usage and benefits of the ebXML architecture and the UN/CEFACT Modelling Methodology with a real-world example: the empties supply chain. Within GILDANET this example can be used to demonstrate an electronic document exchange application, explain (real) interoperability and the reusability of its components. The implementation of this application can be used to build an ebXML framework (architecture), demonstrate the functionality, and build reusable blocks that help other customers to create service oriented applications in the logistic sector.

1. GILDANET
gildanet.paradigma.net
Implementing the Empties Business
Case using ebXML
Paradigma Unternehmensberatung
Vienna, December 2004
Mariahilfer Strasse 47/1/3
1060 Vienna, Austria
www.paradigma.net
empties_businesscase_report.doc
Page 1 of 1

2. Introduction
The aim of this short report is to show the usage and benefits of the ebXML architecture and
the UN/CEFACT Modelling Methodology with a real-world example: the empties supply chain.
Within GILDANET this example can be used to demonstrate an electronic document
exchange application, explain (real) interoperability and the reusability of its components. The
implementation of this application can be used to build an ebXML framework (architecture),
demonstrate the functionality, and build reusable blocks that help other customers to create
service oriented applications in the logistic sector.
Business Case Overview
This simple case study deals with the transport and management of empty containers. Since
controlling and financial services are beyond the scope of this model, it can be best described
in relation to an empty container’s lifecycle. An empty container "is created" when a full
container is emptied of the goods it carried. Normally this occurs either in a container terminal
or at a client's location. The next step may involve a movement of the container, which can be
taken to another terminal (port terminal or inland terminal); the container could even stay at
the same location (no relocation) in case the unloading were performed is be stocked.
Subsequent movements to different terminals are possible; until finally an empty container is
filled with goods. This is the end point of an empty container's lifecycle.
Among others, the following agents are involved in the supply chain of empty containers:
•
Customer: An enterprise or person demanding a transport service from the
shipping line.
•
Shipping line: A shipping line manages a fleet of vessels. Vessels carry full
and empty containers from a departure port to a destination port. Normally
it owns a certain amount of containers.
•
Multimodal transport operator (MTO): The multimodal transport operator
takes care of the transport of containers between different locations,
organizes the transport of all modes and conducts the transportation by
truck himself.
•
Container terminal: A container terminal handles container flows within a
port or dry port area (loading, unloading, stocking, charging, discharging,
repairs, inspection, etc.).
The process chain starts with a container being emptied at a customer’s site. The latter
communicates this to the shipping line, which in turn provides this information (basically the
container’s location) via its web service to a set of multimodal operators. In order to be able to
exploit the potential for optimization in this chain, the MTOs are given the opportunity to
decide within certain constraints on their own which orders they would like to fulfil. This is
done by the MTOs’ legacy route planning systems, which calculate the dates of pick-up at the
client and dates of delivery to the container terminal. Pick-up and delivery dates are sent to
the client and container terminal, respectively. After the MTO has carried out the transport to
the container terminal, the empty container is released for future use. The container terminal
inspects the containers and if necessary conducts repair and maintenance operations. The
container’s status as well as tracking information is provided via web service to the shipping
lines.
The detailed flow of information can be seen in Figure 1: the initial message sent out by the
client (1) is a simple notification (cf. Appendix). Its addressee is the shipping line where the
message is received, pre-processed and provided to the Web Service at the Shipping Line
(6). In their operations planning process MTOs look for open orders as clients of the shipping
line’s service. This transaction (2) is best depicted by a query/response pattern (cf. Appendix
figure). On a MTO’s query, the shipping line’s system responds by supplying the necessary
information.
The acceptance of an order (3) triggers the MTO’s detailed planning process. Routing and
scheduling decisions concerning the means of transport result in pick-up and delivery dates.
empties_businesscase_report.doc
Page 2 of 2

3. The former are communicated directly to the client (4), the latter to the receiver of the
delivery, the container terminal (5). Since neither of them needs to react to this information,
this process is again modelled by a notification pattern (for an example see Appendix, figure ).
Finally the container terminal provides the status of any particular container as well as
relevant tracking information via web service (7). The shipping line may use this Web Service
provided by the Container Terminal at any time to request information concerning their
containers (8) and (9).
Shipping
Line
1
Container ready
for pickup
Multimodal Operator
Container Terminal
6
2
Customer
open Orders
accept order
3
Container Pickup Notification
Container arrival notification
4
5
Container Status Information
7
8
Caption:
Container Tracking Information
Web Service
Activity (manual or
automated)
9
Figure 1: Business Case Overview
Logical Architecture
Based on the business process analysis and technical environment we decided to implement
the communication between Shipping Line and MTO and Container Terminal and Shipping
Line as Web Services. In particular, the MTOs looking up open orders and the Shipping Lines
requesting information about containers at the terminal. The technical environment suggests
an ebXML-conformant service-oriented approach so the selected transactions are
implemented as Web Services and SOAP messages.
Multimodal
Operator
Container pickup notification
Customer
Container ready for pickup
Legacy
System
Web
Service
Client
Container delivery notification
Shipping
Line
Web
Service
SOAP Message
SOAP Message
Container
Terminal
Web
Service
Figure 2 Logical Architecture
empties_businesscase_report.doc
Page 3 of 3

4. Physical Architecture (focus on the Container Terminal)
For completeness only.
(The Role Multimodal Operator is not
covered in detail by this example)
Role:Multimodal
Operator
This SOAP message
invokes the process at
the Terminal Container
service.
The Container Status WebService
examplifies an interface application
to a legacy system.
The behavior is specified in the
sequence diagramm
3) The Business
Software of the
Shipping Line requests
for container status
information.
Business
Software
This part of the SW retrives the
information about the Container
from the Legacy Application
Role: Container Terminal
WebService (ContainerStatus)
BSI
Business Service Interface
BSI
Business Service Interface
SOAP Message
Message
Handling
Role: Shipping Line
Specified by Sequence
Diagramm
requestCSI(Cont.ID) {
code
code
Glue Code
code
return(Cont.Data)
}
Message
Handling
SOAP Messages
WebService (Client)
2) The Business Service Interface
handles this RPC by packing it into
an SOAP message
WebService
(ContainerTracking)
BSI
1) The ClientSW at the Shipping
line requests for
ContainerStatusInformation (CSI)
by calling a WebService with the
ContainerID as a parameter.
direct
access
Business Service Interface
This ContainerTracking examplifies
applications build upon WSA
(WebServiceOriented Architectures)
Figure 3 The Physical Architecture
empties_businesscase_report.doc
Data
base
The status information about
the Container is stored here.
It can only be accessed
through a legacy application.
BSI
code
Business Service Interface
RPC-Call
code
code
requestCSI(Cont.ID)
code
Business
Software or
Legacy
Application
Page 4 of 4
T&T
Database

5. Using ebXML
The business and the functional model are results of UMM. The business model contains
information like requirements for the collaboration, i.e. when and where certain business
information is needed in the business process. On the other hand, the functional model
contains a detailed technical specification of the collaboration that will be implemented using
ebXML and was derived from the prior analysed business processes. Also the technological
environment imposes constraints on the implementation, which in our case are: using ebXML,
the interoperability with legacy systems, and the use of Web Services. In this case ebXML
suggests a service-oriented architecture (SOA). This facilitates the integration of existing
business software (legacy systems) and external Web Services described below (see section
Physical Architecture).
The functional model (in UMM terms the ‘Functional Service View’) delivers two essential
results: the class diagram provides the common data basis for all services, but one service
may only use parts of it. Sequence diagrams, which exist for each transaction, provide the
specification for a particular service. Both together determine the choreography of business
processes and the information exchanged between all partners. If each of the partners
adheres to these outlines in his implementation, interoperability will be guaranteed.
The technical system specification contains all information needed to implement the business
choreography. While the functional service specification and the class diagram are derived
from the functional model the project definition is taken directly from the business model.
Finally, the Business Service Interface depends on the particular legacy system in use.
The development process usually has five phases: analysis-, specification-, implementationtesting- and rollout phase. The analysis phase is extended by UMM to analyse not only the
messaging layer to derive requirements also the business layer to ensure interoperability. So
with UMM the requirements of a detailed technical analysis phase and the requirements of
interoperability for that phase can be accomplished. The specification phase can be
supported by standardised material from UMM described above. The additional architectural
descriptions (logical or physical component diagrams, describing the building SW or HW
blocks and their interfaces) can be derived from SOA and adopted to the individual needs of
the business partners.
Business
Model
One Business Model (per Business
Case = EmptiesCain) defines the
scope where all subsequent
created objects relate to
The Class Diagram
provides an overview
about all used data
items in the whole
business case
UseCase
Diagram
Patterns
Technical System Specification
Functional
Model
Project Definition
Architectual Model
(Collaboration)
Decision which
and how
collaborations are
implemented
Technological Environment
Class
Diagram
Class Diagram
Sequence
Diagram
Specifications for all
Services:
(Requirenments from:)
ebXML
service oriented approach
One sequence
diagramm per
service
The specification
for the services
can be derived
direct from the
funcional modell
Sequence
(Choreography) of
Function Calls (RPC)
Legacy Systems
BSI
description about:
Business Service
Interface = Legacy
System Interface
- Interface and
- Data (Information Model)
The BSI implements the interface to
existing applications (Legacy Systems)
External WebServices
to be used:
- WSDL
WSDL provides all information
needed to call such a service
Figure 4 Software Development Workflow
empties_businesscase_report.doc
Page 5 of 5

6. Advantages of the this approach
The combination of UMM, a standardized analysis methodology, and ebXML, a collaborative
business framework, implemented by a service oriented approach makes the whole approach
modular, reusable, and interoperable.
Reusability of the components
•
Not only SW components: UMM Artefacts (BPSS) can be reused, the Class Diagram
should be used by every partner, all collaboration information can be used by both
partners.
Interoperability in the sense of ebXML is achieved by:
•
"Common Business Processes - Both entities involved in the exchange of data MUST
be engaged in executing the same transaction in the context of a business process":
Achieved by using UMM to analyzing and documenting business processes and
representing key attributes in an XML document (BPSS).
•
"Common Semantics - Common meaning, as distinct from words, expression, or
presentation": Achieved by the use of core components
•
"Common Character Encoding”: UNICODE, which is specified in the W3C XML
Version 1.0 technical specification, provides this.
•
Document business and application (technical) layer by using standardized
methodologies. First with UMM, second with WSDL and finally publishing those in the
Registry
o
•
Make this documentation readable (and accessible) by everyone / partners
(Registry)
(Re-)Using existing systems by connecting them to a SOA
Core Components
•
Core Components specify the semantics of data attributes. Use these core
components in the Class Diagram to arrive at commonly understood business
documents.
UNeDocs
•
Mapping of real world standard documents in the logistic field to XML structures by
adding (the needed) semantic notation.
Question section-explained by fictive examples
The aim of this section is to show the previously promised features with “real world”
examples:
What if: a new actor joins the collaboration?
The interface tasks and communication with its partners must be analysed and documented
using UMM (or a similar methodology). The pertinent interactions (the business) with its
partners can then be formulated (based on the business process description) within a
contract.
The decision which of the above-described interface will have to be implemented
electronically is done (see Software Development Workflow). Existing Web Services of the
partners can be reused; the interface (Web Service) of the new partner has to be
implemented (reusing components of the ebXML framework).
empties_businesscase_report.doc
Page 6 of 6

7. The compliance with the contractually specified choreography, validity checks of the
transmitted data and any required mappings to legacy applications will be part of this interface
component (BSI).
The specification for this component is an important result of UMM. The process must be
integrated in the processes of the partners (this is achieved by virtue of the choreography of
UMM); components must be able to communicate (this is assured by the Class Diagram).
… a new document should be integrated (used).
The new document exchange will be added to the Business Model (by changing the BPSS of
the involved partners) if needed (see below). The implementation of the new document
depends on the needed mapping functionality (see Appendix).
If the new document is a standard document in the logistic field (covered by UNeDocs) or the
document can be described by an XML structure (by definition almost every document can)
the two needed tasks can be done with minimum effort.
Multimodal Operator
Example:
We assume that for security reasons every
container that arrives at the CT must have
an document with an security ID. The CT
provides a Web Service where such
documents can be requested and the MTO
needs to equip every container with such a
security document.
In the following every step necessary for
such a change is described
Container Terminal
Container Arrival Notification
Container Security Information
Container Status Information
Container Tracking Information
Figure 5: new security document
1. CT and MTO formulate the new transaction with a pattern in the Business Model. (SL
is not involved in any change). This pattern describes the information which has to be
sent by the MTO to eventually receive the security ID. As no other interaction is
involved the existing business model may remain unchanged.
2. Subsequently the two trading partners can express their changed collaboration within
a new version of the previously shared BPSS. If they agree on the new business
process (BPSS) they will sign a new contract (CPA) based on the new BPSS.
3. The new transaction results in additional Web Service functionality which must be
described in the technical specification. In particular a new sequence diagram
describing the methods invoked and the data elements which are transmitted to
implement the security ID service at the CT.
4. The CT may implement the new service using the same methodology as they used to
based on the same kind of specification. Their development process will benefit from
the reusability of many components of the already implemented Web Service. The
effort and costs of this extension will be minimal because of the modular design and
the independency of each individual service.
5. The final output of the Web Service is a document described in XML downloaded by
the MTO, which can be easily converted into a paper document by an “XML to PDF”
conversion and by printing out the PDF.
empties_businesscase_report.doc
Page 7 of 7

8. … a business process changes ?
As described above the Partners must agree on new interaction process (collaboration). This
is done by a standardised method: First, a common BPSS is formulated, and stored using
registry functionality. Second, a new contract based on the new BSPP is signed. The new
process can be then integrated supported by the flexibility of the SOA: No other service have
to be changed, adopted or rewritten. The new functionality can be easily integrated using
existing components into the set of Web Services.
Multimodal Operator
Container Terminal
Example:
Cont. Arrival & Security Info.
Container Security ID
We assume that because of efficiency reasons
the MTO–CT communication is redesigned so
it can be integrated into and benefit from the
service oriented approach: The message of the
container arrival is no longer sent by email, fax,
or whatever it is sent by; the information is now
direct input of the MTO and can be aligned with
the information the MTO has to send to receive
the security ID.
Container Status Information
Container Tracking Information
Figure 6 Container Terminal establishes
a new Web Service
1. The pattern of the security ID transaction will be changed by adding the data formally
sent by the container arrival notification.
2. The new version of the BPSS will again be signed by the partners using their CPP
and a new CPA as a contract.
3. The Web Service of the CT will be extended by a method that is similar to the security
ID method. Additionally it will update the container arrival information and
subsequently the container status data in the tracking application.
4. Maybe not all MTO are able to change the business process. In the old version the
information received from the MTO have to be manually inserted into the tracking
database. The new process makes it possible, that the input of the MTO can be used
to update the tracking database automatically. Because of the fact that in a SOA the
services can coexist independently the old and the new version will coexist as long as
needed.
… one of the involved actors is not equipped with appropriate IT ?
If for one of the partners is not feasible to implement SW clients on their IT environment, the
previous described architecture cannot be implemented as described. One possible solution
may be a “Web Service to Web Application” – service, a Web Client. This Web Client is a
client to a given Web Service, but serves the business logic of the collaboration via HTML so
a simple web browser can be used as an interface to the Web Service.
Such Web Clients have been described in several GILDANET discussions about architecture
as a possible role of “the Portal”, and is identically used in the ebXML Registry client.
Example:
We assume that the Shipping Line’s IT environment of the agents at the ports does not allow
any thick clients, only web browsers are feasible to access the CT’s services.
1. It is important that the services or any other component of the SOA has to be
changed. The Web Client must only use the same Web Service Interface as any
other client would do.
empties_businesscase_report.doc
Page 8 of 8

9. 2. The CT (or anyone else who is capable) now operates such a Web Client so that the
Shipping Line is able to access the Web Services of the CT via web browser-based
technology.
3. The business logic, in particular the workflow management and the data input and
output interface, which is normally managed by the SLs business software is now
implemented in the Web Application logic of the Web Client.
The requirements to implement such a Web Clients are:
•
Use exactly the services that are provided by the Web Services. This interface can be
seen as an API for the Web Client, described in the WSDL of the Web Service.
•
The needs of the Shipping Line at the client side. In particular the workflow
management needs to be implemented aligned to the requirements of the user.
These requirements are partially described in the business model.
Where does the mapping between different business documents
happen?
To answer this question it is expedient to firstly describe the concept of “mapping” itself (see
Appendix). Secondly XML is not a file format like CSV, it is a data description language. It
contains per definition not only data but semantic information about the data also. This makes
mapping where either source or target is specified using XML much less complex than
between other file formats.
1. “Medium transformation”: UNeDocs provides appropriate Web Services, which can
be used to map a UNeDocs XML-structure to a printable PDF format. Or the same
method can be used as a local Web Service.
2. “Format Mapping”: such mapping is best implemented at the message-handling
component of the BSI and in the code that communicates with the legacy application
(Figure 3 The Physical Architecture), because it requires intimate knowledge about
the legacy application. By the same token this prevents any outsourcing venue. In
case different mapping needs arise, they can be addressed by reusing the BSI code
for a template.
3. “Information Mapping”: a SOA can perform this task by defining a Web Service
designed to perform the mapping itself. This scenario assumes, that a single point of
maintenance has been defined
Appendix
Output from UMM:
Business process models describe business processes that allow business partners to
collaborate. Business process models for e-business must be turned into software
components that collaborate on behalf of the business partners. The UMM Meta Model is a
description of business semantics that allows trading partners to capture the details for a
specific business scenario (a business process) using a consistent modelling method and a
standardized language. A Business Process describes in detail how trading partners take on
shared roles, relationships and responsibilities to facilitate interaction with other trading
partners. The interaction between roles takes place as a choreographed set of Business
Transactions. Each Business Transaction is expressed as an exchange of electronic
Business Documents. The sequence of the exchange is determined by the Business Process,
and by messaging and security considerations. Business Transactions are subdivided into
groups of patterns. The following six conventions for business transaction patterns have
proven useful in the application of existing business requirements:
•
Query/Response
empties_businesscase_report.doc
Page 9 of 9

10. A query for information that a responding partner already has available. This pattern
depicts the exchange of static information, such as product catalogues. There is no
need for receipt or acceptance acknowledgements.
o
o
•
Query against a fixed data set
Query to obtain a catalogue
Request/Response
Similar to Query/Response; however, an additional activity from the responding
partner is needed to gather the demanded information. This pattern is used to map
the exchange of dynamic information such as requests for quote or availability
checks. There is no need for receipt or acceptance acknowledgements.
o
•
Price Request
Request/Confirm
This pattern is for obtaining status information and involved business documents for
request and response. There are no economic commitments after this interaction and
no business acceptance or receipt conformation.
o
•
Request to obtain order status
Commercial Transaction
This pattern is used for interactions that result in economic commitments among
business partners. Thus, non-repudiation and authentication are essential.
o
•
Place order
Notification
This pattern specifies the exchange of a notifying business document and a receipt
acknowledgment business signal. This pattern models a formal information exchange
and therefore has non-repudiation requirements. It is a non-repudiation exchange of
business documents.
•
Information Distribution
Similar to notification, except that it is about informal information exchange, and
therefore has no non-repudiation requirements. It is a “repudiatory” exchange of
business documents.
Such a classification into six patterns also provides additional information about the
communication process itself. Business requirements and information about the role of the
two partners are therefore stored within the model.
In the above example the Container Terminal receives a message from the MTO stating when
an empty container is scheduled to arrive as seen in figure
Class Diagram of the Business Model
A class diagram shows the static structure of the information model, in particular, the things
that exist, their internal structure, and their relationships to other things. A class diagram is
direct related to the sequence diagram and the business transaction patterns via the business
information objects which are included in all of these diagrams. Through this link, the static
information is linked to the dynamic process described in the process model.
The class diagram for the example in this report is given below.
empties_businesscase_report.doc
Page 10 of 10

11. I f r an
om o
n ti
nom n
I f r ao
i
t
noao
I f mn
r t
i
* Fr I f
i sno
t
* ScnI f
eodno
* Tr nf
hi i o
d
* r sf
i to
FI n
* ecnI f
Sodno
* hr no
Ti i
df
OpenOrderQuery
Multimo
dalOperator
1
* Fi t f
sI o
r n
* S odno
cn f
e I
* Thr no
i df
i
OpenOrderResponse
(from WebServi...
OrderNotification
(from WebServi...
(from WebServi...
(from act...
Train
TrainID
LocationOfTrackedTrain : String
WagonCount : Integer
Order
OrderID
Date : Date
AmountOfContainerBooked : Integer
provide
1..n
TransportMedium
0..n
Truck
DriverAuthentication : String
LicencePlateNumber : Integer
TruckID
I f r ao
om n
n ti
* Fi t f
rI o
s n
* Seodf
cnI o
n
* Thr n
i df
o
i
ContainerStatusQuery
0..n
MeansOfTransport
MT_ID
Authentication
Containe StatusResponse
r
(from WebServi...
1..n
1
ShippingLine
organise
* Fr I f
i sno
t
* ScnI f
eodno
* Tr nf
hi i o
d
(from act...
1
TerminalContainer
is delivered to 1
ContainerArrivalNotification
(from act...
carry out
I f r ao
om n
n ti
* Fi t f
s n
rIo
* S odno
cn f
e I
* Thr no
i df
i
(from WebServi...
ContainerPickUpNotification
(from WebServi...
noao
I f mn
r t
i
* r sno
i tf
FI
* ecnI f
Sodno
* hr nf
Ti i o
d
0..1
0..n
Transport
0..n
0..n
Container
Containe Type : Stri n
r
g
Containe W ht : Integ e
r eig
r
Containe ID
r
A untOfCo n
mo
ntai er
1
1
0..n A
uthorizedToRep 0..n
air
Vessel
VesselID
nom n
I f r ao
i
t
1
1
1..n
0..n
0..n
Repair
ReparationID
ConditionOfDamagedContainer
DamageSpecification
RepairCost
ReparationStatus
Transp
ortOrigi n : S ng
tri
Transp
ortDe na
sti tion : Stri ng
Transp
ortArrival Time : Date
Lo
adTi me : Da
te
ContainerReadyForPickUpNotification
(from WebServi...
Figure 7 The class diagram of the empty container example
empties_businesscase_report.doc
nom n
I f r ao
ti
* Fi t f
sn
rIo
* S odf
c n
enI o
* Thdn
ri f
i o
(from WebServi...
0..n
Page 11 of 11

12. Sequence diagram.
The sequence diagram is used primarily to show the interactions between agents in the
sequential order that those interactions occur. An organization’s business staff can use
sequence diagrams to communicate how the business currently works by showing how
various business objects interact. Besides documenting an organization’s current affairs, a
business-level sequence diagram is used as a requirements document to communicate
requirements for a future system implementation. In addition to their use in designing new
systems, sequence diagrams can be used to document how objects in an existing (“legacy”)
system currently interact.
Information Mapping
Mapping deals with information, attributes or data elements transmitted via document, file, or
message.
•
Mapping between document, file, and messages (medium transformation)
o
o
By mapping to a message we mean a mapping to an XML “stream”, ready to
be sent via a SOAP message.
o
Physical transformation is needed, content remains the same.
o
•
Examples: Fill out a form, print a file, send content of file via message
Existing Applications: UNeDocs (transform paper documents to XML
structure and vice versa.
Mapping from one format to another (format mapping)
o
o
Semantic information about the content of both the source and the target
document is needed
o
•
XML to XML (using DTD’s), CSV to XML, …
Implemented via COTS Software, or a piece of software, which provides a
parser to read the source document, logic, which does the semantic
mapping, and a component that, formats the output.
Mapping of information from different schemata (information mapping)
o
Different actors use different ID’s to describe identical facts and store these
different attributes in their databases.
o
For example: the car producer identifies cars with a chassis number or VIN
(vehicle identification number); the carrier via a combination of order number
and part number, and the yard operator via a RFID.
o
Implementation is only possible with an additional mapping table.
Glossary
Business Software Interface (BSI)
The BSI connects the Business Software to the messaging layer of the network. In particular
the SOAP message from the network is decrypted and validated, the header information is
compared to business information (BPSS) and the content is subsequently passed to the
business software. Required mapping and transformation processes may be included.
Whatever the “Business Software” is (by the means of its architecture), if it is a legacy system
(see below) the BSI can be interpreted as SW which includes the Message handling, an Web
Service, and Glue Code which implements the transformations needed to access the data in
the Legacy System.
In general the business logic is implemented in the Web Service, therefore the BSI does the
message handling part for the Web Service.
empties_businesscase_report.doc
Page 12 of 12

13. Legacy System
Systems, which already exist and are not “aligned” to the needs of an SOA. In particular, the
needed information (specified in the BPSS) cannot be direct accessed by a
procedure/method call (specified in the Sequence Diagram).
Simple Object Access Protocol (SOAP)
SOAP is a lightweight protocol for exchange of information in a decentralized, distributed
environment. It is an XML based protocol that consists of three parts: an envelope that
defines a framework for describing what is in a message and how to process it, a set of
encoding rules for expressing instances of application-defined data types, and a convention
for representing remote procedure calls and responses.
SOAP provides the framework by which application-specific information may be conveyed in
an extensible manner. Also, SOAP provides a full description of the required actions taken by
a SOAP node on receiving a SOAP message.
http://www.w3.org/TR/soap
Service Oriented Architecture (SOA)
A service-oriented architecture is essentially a collection of services. These services
communicate with each other. The communication can involve either simple data passing or it
could involve two or more services coordinating some activity. Some means of connecting
services to each other is needed.
The technology of Web services is the most likely connection technology of service-oriented
architectures. Web services essentially use XML to create a robust connection.
http://www.w3.org/TR/ws-arch/
empties_businesscase_report.doc
Page 13 of 13