|
| |
Home page>
The ebXML Technology>
The ebXML Technical Infrastructure>
Messaging
Messaging
Traditional business information exchanges have
conformed to a variety of standards-based syntaxes. These exchanges were largely
based on electronic data interchange (EDI) standards born out of mainframe and
batch processing. Some of the standards defined bindings to specific
communications protocols. These EDI techniques worked well; however, they were
difficult and expensive to implement. Therefore, use of these systems was
normally limited to large enterprises possessing mature information technology
capabilities. The proliferation of XML-based business interchanges served as the
catalyst for defining a new global paradigm that ensured all business
activities, regardless of size, could engage in electronic business activities.
The prime objectives of ebXML at its messaging layer were:
-
To facilitate the exchange of electronic
business messages within an XML framework an.
-
To be Protocol Neutral.
-
To be Payload Neutral.
-
To be Secure.
-
To be able to
deliver the messages reliably.
Based on these objectives ebXML
produced the ebXML Message Service Specification.
ebXML Message Service Specification
(ebMS)
ebMS is ebXMLs specification which defines a standard to transport messages in a
secure and reliable manner. See the specification:
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0rev_c.pdf.
Further and old versions of this document could
be found
OASIS
document Index.
ebMS fulfils the objectives
described by the following:
-
The message format is written in
XML (in fact it has subsumed SOAP with Attachments.)
-
ebMS mandates no protocol over
which ebMS should be used.
-
Business messages, identified as the
‘payloads’ of the ebXML messages, are not necessarily expressed in XML.
XML-based messages, as well as traditional EDI formats, are transported by the
ebMS. Actually, the ebMS payload can take any digital form—XML, ASC X12, HL7,
AIAG E5, database tables, binary image files, etc.
-
ebMS uses current security
technologies such XML Digital Signatures and Public Key encryption.
-
ebMS
utilizes reliable messaging elements. These
supply reliability to the communications layer; they are not intended as
business-level acknowledgments to the applications supported by the ebMS. This
is an important distinction. Business processes often anticipate responses to
messages they generate. The responses may take the form of a simple
acknowledgment of message receipt by the application receiving the message or
a companion message reflecting action on the original message. Those messages
are outside of the MSH scope.
The ebXML
Message Service maybe conceptually broken down into three parts:
- A Service
Interface.
- Functions
provided by the Message Service Handler.
- Mapping to
underlying transport system.
These relationships are
actually in the interdependencies between modules.
 These
Modules are:
Header Processing: the creation of the ebXML Message uses input from the
application, passed through the Message Service Interface, information from the
Collaboration Protocol Agreement (CPA) governing the message, and generated
information such as digital signatures, timestamps and unique identifiers.
Header Parsing: extracting or transforming information from a received
ebXML Header element into a form suitable for processing by the Message Service
Handler implementation.
Security Services: digital signature creation and verification,
encryption, authentification, and authorization. These services may be used by
other components of the Messages Service Handler including the Header Processing
and Header Parsing components.
Reliable Messaging Services: handles the delivery and acknowledgement of
messages. The service includes, handling for persistence, retry, error
notification and acknowledgement of messages requiring reliable delivery.
Message Packaging: the final enveloping of an ebXML Message (ebXML header
elements and payload) into its SOAP Messages with Attachments container.
Error Handling: this component handles the reporting of errors
encountered during MSH or Application processing of a message.
Message Service Interface:
an abstract service interface applications use to interact with the MSH to send
and receive messages and which the MSH.
Other Similar Initiatives
Other initiatives
that have developed similar concepts are:
-
RossettaNet: Although these have
now taken ebMS to be their standard message transport layer.
|
