ebXML PoC -- TR&P conference call

[Philippe DeSmedt <PDeSmedt@viquity.com>]

All,

A reminder that there will be a conference call of the ebXML
proof-of-concept TR&P sub-team today, Wednesday, at 8AM Pacific time, for
about 45 minutes.

The call-in numbers are 877-241-3594 (toll-free) and 334-323-4224 (toll),
and the passcode is 611793.

The prupose is to define scenarios and roles for the participants in the
proof-of-concept, specifically the TR&P portions.

The following need to be addressed:
1. multiple transport protocols: at San Jose, we only showed HTTP; we'll
also want to show SMTP;
2. we'll need to show the reliability aspects of the spec;
3. we need to define the following roles: buyer, supplier, and hub; and
define which solution providers will provide which piece(s);
4. as far as TR&P are concerned, we are payload-neutral (i.e., the choice of
which payload to carry can be made by other sub-groups or the PoC team as a
whole);
5. in terms of topology, hub-and-spoke and point-to-point can both be shown;
6. we need to decide how to interact with the other pieces of ebXML
(registry/repository, BPM, TPA, etc.);

My strawman proposal is based on the above:
1. have a topology where HTTP-transported messages are processed through a
hub, and SMTP-transported messages are point-to-point;
2. solution providers will need to implement the reliability spec, and
during the demo, we'll need to simulate failure scenarios to show that we
can recover; we'll need compelling GUIs to show how this would work;
3. the roles of buyer, supplier, and hub are identical to those defined for
the San Jose demo; for the Tokyo demo, Viquity will supply a hub, and may
also be one of the end-points (as a buyer and/or supplier) (to be decided);
other solution providers will need to identify which role(s) they want to
play;
4. we can use GCI payloads, but we'll leave that up to PoC as a whole to
decide;
5. as per 1., we can show hub-and-spoke and point-to-point (with 1. defining
which types of messages are handled with which transport);
6. some of the message header information (e.g. references to TPAs) need to
be populated with 'real' data (i.e., from a repository of sorts); we'll need
to find out from the relevant ebXML teams what the mechanisms are to access
that data, put it in the headers, and have the trading partners adequately
process it;
7. participants in the demo may not just be solution providers; they may be
actual trading entities (e.g. if we go with GCI, some of the participants
may be retailers, CPG companies, etc.); we'll need to address how they can
participate (i.e., what roles they play, what pieces they would need to
construct, etc.); 

In essence, we'll build on the San Jose demo, but round it out with
reliability, and more 'real' header information. Also, as more solution
providers participate, we may need to come up with a different partitioning
of roles and different topologies. We'll also need to have very focused
scenarios to be able to show that many participants.

Let's further discuss in the call. Thanks.

-Philippe
_______________________________
Philippe De Smedt
Architect
Viquity Corporation (www.viquity.com)
1161 N. Fair Oaks Avenue
Sunnyvale, CA 94089-2102
(408) 548-9722
(408) 747-5586 (fax)
pdesmedt@viquity.com