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: FW: Couple of thoughts


Forwarding for Chris...

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, July 26, 2000 11:45 AM
To: marcb@webmethods.com
Cc: Prasad Yendluri
Subject: Re: Couple of thoughts


All,

I agree with Marc. I had started to try to carve out
a subset of the tpaML which could be used by each participant
to identify their roles, etc as Marc suggests which might
be a good starting point.

More comments below.

Marc, would you please forward to ebxml-poc. I'm on the list,
but cannot post to it (argh!)

Cheers,

Chris

Marc Breissinger wrote:
>
> All,
>
> 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

absolutely agree!

> 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.

I think that the subset tpaML would be useful for encoding this information.

>
> 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.

We should be thinking now about what back-end integration (or simulation)
could be achievable for November meeting.

>
> 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).
>
> Thanks,
> marc
>
> ==========================================================================
> 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
> >

--
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903



[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