RE: Tokyo POC choreography - my 2c ;-)

[richard drummond <rvd2@worldnet.att.net>]

eco is done, and bp has recommend it as the way to discover things about
businesses.... not better.... just done and known.... rik

-----Original Message-----
From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
Sent: Thursday, September 07, 2000 12:14 PM
To: richard drummond
Cc: ebxml-poc@lists.ebxml.org
Subject: Re: Tokyo POC choreography - my 2c ;-)


All,

Just curious: why would eCo be better from a strategic perspective than
UDDI? Don't they both overlap with ebXML? If so, I would think that
agnosticism would be an appropriate long term strategy, and that the POC
would use the one that offers the most bang. Is that eCo?

Executive team input on positioning would be useful here.

-gvh-

richard drummond wrote:
>
> it has been suggested that because of the uddi thing that we need to show
> progress.. we could use the eco stuff, maybe, to show progress instead of
> the r&r stuff. just offering a suggestion... rik
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: Thursday, September 07, 2000 10:29 AM
> To: richard drummond
> Cc: ebxml-poc@lists.ebxml.org
> Subject: Re: Tokyo POC choreography - my 2c ;-)
>
> Rik,
>
> Dont we want to use ebXML Registry Services rather than eCo framework?
> Please clarify?
>
> --
>
> Regards,
> Farrukh
>
> richard drummond wrote:
>
> > for the registry, could we use the eco frame work stuff for a discovery
> > process. bp has discussed this? rik
> >
> > -----Original Message-----
> > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > Sent: Thursday, September 07, 2000 9:39 AM
> > To: ebxml-poc@lists.ebxml.org
> > Subject: Tokyo POC choreography - my 2c ;-)
> >
> > Hi all,
> >
> >         As promised during our last con call, I was thinking about Tokyo
> POC
> > choreography and here are my thoughts:
> >
> >         I have also added whom we should be co-ordinating with, from my
> limited
> > knowledge. Pl let me know if I am going in the right direction and if
this
> > helps. I can take the first cut at drawing sequence diagrams as well.
> David
> > Burdett has some very nice use cases on some of the process. How can I
get
> > in touch with him ?
> >
> > ------------------- Here are the top level
> > steps -----------------------------
> >
> >         1.      Registry/Repository comes up (RegRep)
> >                 a)      Could be local or remote
> >                 b)      If local *and* remote, we need to worry about
sync
> et al
> >                 c)      May be for Tokyo POC, remote is better
> >
> >         2.      Catalog Aggregator comes up
> >                 a)      I would like to see if we can get some form of
> Catalog Aggregator
> >                 b)      This way, we abstract out the knowledge of the
> product details
> >                 c)      Again could be local or remote
> >
> >         3.      Seller(s) comes up
> >                 a)      May be seller(s) will host catalogs as well
> >
> >         4.      Seller(s) registers with the registry/repository
(regRep)
> >
> >         5.      Seller(s) updates catalogs (Service Layer (?))
> >
> >         6.      Hubs come up
> >
> >         7.      Hubs interact with the registry/repository (regRep, BP)
> >
> >         8.      Buyers come up
> >
> >         9.      Buyers discover sellers/hubs thru the
registry/repository
> (regRep, BP)
> >                 a)      The message set/use case would be in conjunction
> with the BP team
> >                 b)      David Burdett has some very nice use cases on
this
> process.
> >                         How can I get in touch with him ?
> >                 c)      They also discover supported business processes,
> message types et al
> >                 d)      At this time, the profiles are pulled out and
> looked for a match et al.
> >
> >         10.     Buyers enter into TPA with the ones they choose (TPA
Team)
> >
> >         11.     Buyers and sellers/hubs exchange messages (Core
> Components/Messaging)
> >                 a)      Buyer sends an RFP to say 3 sellers
> >                 b)      Sellers/hubs send out quote
> >                 c)      Buyer selects one seller/hub
> >                 d)      Hub/Seller sends out confirmation
> >                 e)      Buyer sends PO
> >                 f)      Seller sends out status (Order Booked, Shipped)
> >                 g)      Seller sends out invoice
> >                 h)      Buyer ack shipment/receipt
> >                 i)      Buyer send out advice of payment
> >
>
> --------------------------------------------------------------------------
> --
> > --------
> >
> > Notes :
> >
> >         i)      All are based on the APIs provided by the various parts
of
> ebXML.
> >         ii)     The POC might develop a few services as a thin layer on
> top of the
> > ebXML - thus showing extensibility of the framework.
> >         iii)    Also, if possible, I would like us to push for more
> dynamic and
> > configurable system.
> >         iv)     I also would like to see if we can demonstrate some
> security - like
> > certificates for interacting with the registry/repository.
> >         v)      Nick, should I be working with Karsten/Steve on this to
> sync with the
> > main proposal?
> >         vi)     All, again, please let know your thoughts, suggestions
et
> al - the
> > good, the bad and the ugly.
> >
> >         cheers
> > ----------------------------------------------------------
> >        |          |             Krishna Sankar
> >       :|:        :|:            Member of technical Staff
> >      :|||:      :|||:           Internet Commerce
> >  ..:|||||||:..:|||||||:..       (Ph) 408-853-8475
> >     Cisco  Systems Inc          ksankar@cisco.com
> > ----------------------------------------------------------
> > "Failure is certain if we don't,
> >            but Success is uncertain even when we do.
> >                          So the choice is Ours, always..."
> > ----------------------------------------------------------