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

[Krishna Sankar <ksankar@cisco.com>]

Is it a possibility to use the eCo Framework on the top of registry services
?

cheers

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Thursday, September 07, 2000 8: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..."
> ----------------------------------------------------------