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

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

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..."
> > ----------------------------------------------------------
begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard