Interoperability

A key issue for ebXML is interoperability ” called "the primary requirement of the ebXML initiative" ”and the specifications spell out the meaning of that concept.The specifications identify four focus points of interoperability:

• The ebXML architecture itself

• Messaging

• Extensibility

• Taking advantage of existing technology

For ebXML, the idea of interoperability goes well beyond most dictionary definitions of the term . We now consider each of these aspects in turn .

Architecture

The ebXML architecture provides a picture of the technology for making the exchange of business data happen. The specifications list the features of the architecture that make it possible for companies to exchange data seamlessly. They also point out that incorporating these features can help meet other requirements, such as the ability to operate across various computing platforms.

But the specifications recognize that meeting all of these requirements may not be immediately achievable. Where all parties are not at the same level of maturity in using ebXML, one or more of the companies exchanging the data may need to create special-process steps, including mapping or conversion routines, which can bridge the gaps but add time and cost to the exercise.

These architectural features identified by the specifications include common understandings of certain issues:

• Business processes. The companies exchanging data must be involved in the same transaction, as part of the same business process. For a company to send a shipping notice to another company as part of an order/delivery process, for example, both companies need to have their systems prepared for that particular exchange. If the receiving party is unable to interpret or adequately process the message it receives, this can lead to failure of that part of the business process. A company may inadvertently send such a message to a trading partner, and therefore remedial actions will be required at that point in the process.

• Meanings of terms. When companies exchange data, they need to use common semantics for the data exchange. For example, in the printing industry the term signature has a specific meaning that's much different from that of most of the rest of the business world. Thus, when doing business with a printing company, a trading partner has to make certain that the word signature used in the financial context is distinguished from the printing industry's special meaning.

• Character encoding. For data exchanges in the standard ASCII character set used for Roman alphabets, representing the data rarely presents a problem. For non-Roman character sets, however, that representation can become a problem. Fortunately, the Unicode standard and ISO standard 10646 already provide a common way of representing characters .

• XML representation. For data expressed in XML, all of the parties to the exchange need to have common element tags and attributes, as well as a similar XML document structure for the data to be meaningful. In other words, the messages exchanged among the parties should reference the same XML layout and structure; technically this is achieved by using a document-type definition (DTD) or schema.

• Security implementation. All of the parties in an exchange of data need to be on the same level of security and have the same privileges with the data. If one party encrypts a message, for example, and another party cannot decrypt the data, the exchange of data does no good.[9]

Messaging

The ebXML specifications give the interoperability requirements for the transport, routing, and packaging of messages, so that trading partners can reliably send and receive their business data. In addition, the guidelines for message exchanges are designed to be applicable independently of the physical systems developed for sending and receiving the data. This approach acts as insurance against obsolescence as newer interchange technologies come along.

• Network and data-transfer protocols. All of the parties need to operate under the same basic technical procedures for transferring the data. For example, if one party uses email to send the data but the other parties are anticipating web-based messages such as those using the Simple Object Access Protocol (SOAP), the exchange will require a transfer system that can link their messaging delivery together. Clearly, the more compatible individual systems are, the better the reliability that will be achieved in message transfers.

• Reliable message delivery. In ebXML, reliable messaging is defined as the delivery of a message no more than once, which means only one delivery or no delivery at all. In some cases, not receiving a message can be better for a company than receiving multiple messages. For example, if a company received multiple invoices, it might respond with multiple payments, but no invoice triggers no action in response.

• Neutral syntax. If industries have special requirements for message transport, packaging, or routing, they need to store those requirements in a neutral syntax so that trading partners can retrieve those policies with systems running under any computing platform.

• Message configuration. The specifications require ebXML to give details of the message format and structure, showing the configuration of the envelopes, headers, and payloads. These details make up most of the ebXML messaging specifications.

• Queries to servers. The requirements call for ebXML servers to respond to queries about the services that they support. While ebXML included this function in its specifications, it became an activity of the registry functionality of ebXML rather than message-delivery servers.[10]

Extensibility

The specifications note the need for businesses to put more than the basic ebXML functions into a system. For example, systems built or packaged to support ebXML will sometimes support internal business processes, such as exchanging messages among organizational units or reporting company financial data on an intranet. Therefore, ebXML systems need to accommodate these extensions, while at the same time preserving the basic standard functions.[11]

Taking Advantage of Existing Technology

Requirements for ebXML's interoperability include the ability to relate to previous methods for electronic data exchange, as well as migrating from new technologies to ebXML. Some of the first ebXML applications will likely take place in companies already using EDI or other XML vocabularies. These companies will certainly want to integrate their investment in these systems with ebXML, and thus any definition of interoperability needs to include this vital aspect.

An important part of the connection between current data exchange technologies and ebXML is the common data items in the current exchanges and ebXML messages. While these data items may be expressed in a different syntax, they still represent the same ideas, particularly when they don't change across contexts.

Internally, ebXML calls these common items core components , and they can be reused both within and across messages. Business processes using the core components then provide the precise meaning of these items by providing the context for the definition.

Time data items, for example, are vital for business and used in many ways and in many different messages. Time is expressed in many EDI and XML transactions using the ISO standard 8601 as hh:mm:ss in 24- hour notation. Thus, a physical time defined as 17:52:00 has a precise meaning and can be used interchangeably in many different messages and applications. But while the meaning is precise, it's also limited. It needs a context to make it useful for business understanding. If the time data in a message sent by an airline to a travel agent reads 17:52:00 ETA (where ETA stands for estimated time of arrival ), it has more business meaning and utility than simply the time value itself.

The ebXML specifications include a requirement to express core components in a neutral syntax, which makes them deployable among both XML vocabularies and EDI transactions. This syntax neutrality also must extend to spoken languages as well as markup languages, to help make the core components more applicable across business processes and contexts, as well as support ebXML's other requirements for globalization. The specifications consider this requirement so important that if the ebXML working groups cannot find a methodology to generate core components, they recommend that ebXML build its own.

The specifications cite the importance to businesses of providing a migration path to ebXML from their current EDI transactions based on accredited standards and previous XML vocabularies. Providing a migration strategy or methods is considered beyond the scope of the initiative. Nonetheless, the specifications encourage the developers of the technology to keep an eye on this migration issue.[12]