OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: The role of the intermediary marketplace.

There has been limited discussion on the role of intermediaries, but I'm
looking for more specific direction about the role of the hosted
marketplace, that is where server applications are provided for both buyer
and seller connecting across the Internet to conduct business.  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 (eg 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.

What is common is that given a 1000 buyers and 1000 sellers, we effectively
wish to only define 2000 CPAs between the hub/marketplace and each of the
parties.  The buyers are not going to talk to the seller directly, rather
they will use the facilities of the marketplace to support the messaging
for each business collaboration and transaction.  The alternative would
require up to a 1,000,000 CPAs.

So the obvious way to go is define a CPA between the hub and buyer and
another CPA between hub and seller.  But in such a case, when the order is
from a buyer, who is the "FROM" tag set to?  Logically it must be the
Buyer.  And at the seller's physical end, when they are creating a response
document, they will presumably set the "TO" tag to the Buyer, despite it
going to a URL hosted by the marketplace.

Our solutions has been a bit of a cludge - we create the 1,000,000 CPAs for
each friendly buyer-seller relationship, but these are empty save two
pointer into the actual CPAs between the hub and the two private parties.
And when looking at the CPP for a virtual organisations, it really just
points to the CPA between the marketplace and the organisation.  Since the
CPAs and CPPs for these organisations are not centrally published, the
marketplace can create its own management of these.

This works okay when when both buyer and seller are internal and the CPAs
are used for integration: negotiation is not done automatically, instead it
is done through the hosted system.  However in the situation where the
marketplace would wish to conduct transactions with organisations outside
the system, publishing and negotiation become necessary.  Now the
establishment of virtual vs physical becomes more difficult and
synchronising with an external registry problematic.

It appears obvious to me that some changes are needed in the CPP and CPA
structures to more adequately handle the spoke-and-hub model used by
marketplaces and store-and-forward hubs.  Is anything being done and how
could it be?

James Wowchuk             james.wowchuk@marketboomer.com
Chief Technology Officer  marketboomer Pty Ltd
 _--_|\                   Post:  Level 11, 121 Walker Street
/      \                         North Sydney, NSW 2060
\_.--._/ <---Sydney NSW   Phone: +61 (2) 8907 9333
       v      Australia   Fax:   +61 (2) 9854 1942

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC