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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

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

Subject: RE: Couple of thoughts


I disagree.

I believe the type of scenario that is described below is unscalable.  We
will be (hopefully) continually adding new participants to the POC and demo
environment through November as more vendors provide support.  The plan
outlined below will require continual updates to the business scenario to
incorporate each new vendor.

I believe the any-to-any scenario solves that problem.  The basic 2-party
PIP3A4 Create Purchase Order scenario is a real business scenario than can
be presented in a well orchestrated manner at the closing plenary.

Our aim should not be to build a one-off demo, but rather to build the
appropriate, interoperable, ebXML TRP infrastructure that enables us to (1)
prove the viability of ebXML for enabling dynamic trading networks and (2)
dynamically create demonstration scenarios quickly and easily.  I think the
any-to-any configuration is the best and most efficient way of accomplishing
both of those goals.  It allows us to scale the environment to include new
vendors (i.e., trading partners), thereby proving the ability of ebXML to
handle dynamic relationships.  It allows us to demonstrate, if we desire,
both a hub-spoke and point-to-point based relationships.  Finally, it
enables us to create different kinds of demonstrations "on-the-fly" (albeit
a somewhat risky proposition).

In order to get there, a few of simple things need to happen:

1.  Each vendor must declare what roles they will fulfill in the PIP3A4
process: requester, receiver, req/rec, or hub (I believe only Viquity will
play the hub role).

2.  Each vendor must declare what protocols they will support.  Allowing
multiple protocols (a) follows the spirit of the ebXML TRP specification;
(b) enables broader participation from the member base; and (c) provides a
more compelling demonstration.

3.  Each vendor must publish the basic tpa connectivity information for
communication (e.g., the URL for HTTP, email address for SMTP/POP/IMAP, path
for FTP, etc.).  I suggest that, for simplicity, we leave security out of
the mix for this demo.

4.  Each vendor is assigned a DUNS number for their role.

Given that we don't really care about the payload it is not really required
that we agree on the contents of the PO or the PO response.  However, it
might be nice to have each of the requesters declare what data will be in
the payload of the PO and what data they expect to receive in the
ack/acceptance messages.  Given that, I don't think anyone ever considered
doing any back-end integration for the San Jose demo.

With that infrastructure in place, we can use the week in San Jose to craft
the actual choreography of the demonstration scenario that will incorporate
all who are able to participate.  It's certainly not a competition.  It's a
matter of creating the most effective demonstration of the promise of a
standardized TR&P framework.

O.k.  I'm off the soapbox (for now).


Marc Breissinger                                   voice (W): 703-460-2504
Director, Product Strategy - webMethods, Inc.      voice (C): 703-989-7689
Email:  marcb@webmethods.com                               We're hiring!!!
Email2: breissim@earthlink.net              URL: http://www.webmethods.com

> -----Original Message-----
> From: Prasad Yendluri [mailto:pyendluri@vitria.com]
> Sent: Wednesday, July 26, 2000 12:00 AM
> To: ebxml-poc@lists.ebxml.org
> Subject: Couple of thoughts
> Folks,
> Let me throw couple of thoughts into the mix.
> One thing good we did last time around was, use a well defined scenario
> (Travel Profile Update) and associated roles and the roles were played
> by individual companies. Turned out we played multiple roles in the end
> but, the plan was to have a separate organization play a role. It was a
> well defined and coordinated coherent demo.
> I am a little concerned with the anybody sending and receiving to anyone
> approach. I think we need to be able to present a coherent demo, that
> plays out a real business scenario in a well orchestrated manner, that
> we can present at the closing plenary. With anyone sending to anyone and
> people requiring to find their partner etc., I am worried that this
> might come down to some sort of competition, like who can do with how
> many different people etc. based on some private agreements.
> The proposal I made was trying to emulate an ebusiness supply-chain
> scenario, incorporating a Hub at the center; a realistic and already
> prevalent scenario IMHO. Attempting to ship RosettaNet PIP payload made
> it a very powerful story for ebXML indeed. I agree very much that we
> should be focussing on demonstrating ebXML  TR&P capabilities  and less
> (probably not at all) on back-end and product
> integrations/demonstrations.
> Hence I would like to request that we reconsider the anything goes
> approach and work towards a business scenario that incorporates all
> parties interested in participating.
> Regards, Prasad

[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