[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: ebXML PoC -- TR&P conference call
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC