YES ... Sign me up for the ebXML Forum Newsletter

Email Address:

ebXML Forum does NOT send unsolicitied e-mail.

Fair exchange?

A recent list-serve discussion suggests ebXML's technical committees have some work to do before electronic marketplaces, exchanges, and hubs can make good use of ebXML

James Wowchuk of Marketboomer, an Australian company providing electronic marketplace services, on 28 May 2003 asked the ebXML Developers List about ebXML's ability to handle interactions involving intermediaries, such as exchanges and hubs. His question provoked a number of responses, which may have identified gaps in ebXML's current capabilities.

Buyers and sellers, friends and public

In his posting, Wowchuk outlined the business scenarios where e-marketplaces connect the parties doing business, distinguishing between internal and external parties:

There are two main areas of interest for the marketplace conducting transactions: between buyers and sellers that are both part of the marketplace; between parties in the marketplace system and parties in corresponding roles outside the system. (In object oriented parlance, we describe the former as "friends" and the latter as "public") For the hosted marketplace, the hosted Buyer and hosted Seller can be considered to be "virtual" parties, different from the "physical" parties located in their premises. For actual buyers and sellers then, integration services may be needed: linking the "virtual organisation" with the "physical (private) organisation" for some transactions (e.g., sending the actual order, receiving an actual delivery docket). When connecting to parties outside the system, the "virtual" organisation is the public face of that organisation, representing the set of supported business transactions but physically hosted by the marketplace. So it is the transactions of the marketplace that are really being supported.

Wowchuk showed that by dealing with an electronic marketplace, buyers and sellers should need to prepare only a single collaboration protocol agreement (CPA, ebXML's name for the technical aspects of a trading partner agreement) with the e-marketplace, rather than separate CPAs with each company partner participating in the marketplace. But ebXML now appears to require separate CPAs for each trading partnership, when in fact the only ones that count are those between the company and the e-marketplace.

If the trading partners already subscribe to the exchange but need to negotiate terms, they can do so within the facilities of the marketplace. When the trading partners come from outside the exchange -virtual parties as Wowchuk calls them -- the process becomes more public, which compounds the problems.

Wowchuk's immediate question dealt with identification of the TO and FROM tags in a CPA, when dealing with an intermediary, such as an exchange or a store-and-forward hub. In subsequent messages, he identified still other issues that CPAs either do not address or need to clarify:

• Identification of specific role (broker, agent, branch) in business processes involving intermediaries
• Transformation of payload contents from one XML vocabulary to another
• Identification of specific trading partner companies, when the CPA is with the intermediary
• Handling private keys of trading partner companies, when the intermediary provides the digital signature

Not there yet

In response to Wowchuk's questions, Marty Sachs, who chaired the ebXML team that wrote the original CPA and collaboration protocol profile (CPP) specifications, acknowledged that the ebXML architecture does not yet address all of the issues surrounding e-marketplaces. Sachs recommended keeping the basic point-to-point design of ebXML, but adding marketplace functions over the point-to-point layer.

For example, Sachs suggested, "The marketplace layer would have its own header that, among other things, identifies the buyer and seller and carries other standardized information defined by the marketplace." Sachs cautioned that standardizing the marketplace functions would not be easy, given the variety of marketplaces that would need to be accommodated.

Dale Moberg of Cyclone Commerce, who chairs the Collaboration Partner Protocol and Agreement (CPPA) technical committee confirmed in an e-mail response to questions about the committee’s plans, “there is no explicit support for intermediaries in the current CPA beyond certain configuration flags relating to SOAP intermediaries and acknowledgments.”

Smaller enterprises can benefit