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


[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