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

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

sun knows how to convert uml bus. models to dtd's for us in the demo... will
this be enough?  rik

-----Original Message-----
From: Mark Hale [mailto:hale@ajubasolutions.com]
Sent: Thursday, September 07, 2000 10:51 AM
To: Krishna Sankar; ebxml-poc@lists.ebxml.org
Subject: RE: Tokyo POC choreography - my 2c ;-)


Krisna,

For completeness, we need to capture this in a business process model as
defined in the BP group.

	Thanks,

	Mark


________________________________________________________________________
Mark A. Hale                                            650-940-4155 tel
Standards Architect                                     650-230-4065 fax
Ajuba Solutions                             mark.hale@ajubasolutions.com
2593 Coast Avenue                          http://www.ajubasolutions.com
Mountain View, CA  94043


-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Thursday, September 07, 2000 7: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..."
----------------------------------------------------------