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

[Krishna Sankar <ksankar@cisco.com>]

Hi,
	Farrukh, we arrived at the same conclusion almost simultaneously !
<soapbox>
	I think, we should try to work with a few standards as wrappers, in some
form, so that people see ebXML as a flexible framework.  IHMO, one of
ebXML's core strength is this agnosticism and/or the capability to leverage
and co-exist with other standards - at different levels of course. We paint
a powerful picture, if show how ebXML works with a couple of standards, like
we did it with the SJ POC.
</soapbox>

meet you all on about 30 min.

cheers

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Thursday, September 07, 2000 8:34 AM
To: Farrukh Najmi
Cc: richard drummond; ebxml-poc@lists.ebxml.org
Subject: Re: Tokyo POC choreography - my 2c ;-)


OK, I understand the difference. eCo provides discovery capabilities
(similar to UDDI). This is a
value added service above core Registry services. Am I right on this?

--

Regards,
Farrukh

Farrukh Najmi wrote:

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