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

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

it was just a suggestion, since bp has already discussed this.... it is not
clear to me it is half-cocked.... even though it is clear to me you have
enough on your plate and don't need any more.   rik

-----Original Message-----
From: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
Sent: Thursday, September 07, 2000 1:43 PM
To: richard drummond; arofan.gregory@commerceone.com
Cc: ebxml-poc@lists.ebxml.org; Klaus-Dieter Naujok; Bill Smith
Subject: RE: Tokyo POC choreography - my 2c ;-)


Rik,

Sorry to have to step in here but I would like to point out that we are
following a process and a plan that we have collectively agreed to in this
WG. We already have a very aggressive schedule so I absolutely do not
support going off half-cocked. I have said this before and I will repeat it
once again. The POC is *not* a marketing exercise (it may have some ebXML
marketing benefit) and whatever we show must be rooted in sound
specifications. Before we go down the eCo path and divert resources on this
we need to get the right WG engaged - who would that be ? R&R ? If we
aren't seeing progress being made there then let's fix it.

I can not support a process that throws in technologies, frameworks etc. in
an ad-hoc fashion into the pot - I say this knowing the extent to which Sun
contributed to the eCo framework and having access to most of the eCo
experts.

This is not an issue for this WG and needs to be discussed at the STC and
executive level. Clearly the UDDI initiative has created fud and I'm
concerned about it but we need to execute on a vision not track the latest
Press Release. The POC WG can't fix this problem - if you want to create
"facts on the ground" it can be done but let's do it in a systematic way in
the right forum. Thanks in advance.

Regards,
Nick


At 12:30 PM 9/7/2000 -0500, richard drummond wrote:
>arofan, do you have the eco documents? we want to look at them for the
ebxml
>effort and maybe prototype them in tokyo.  thanks, rik
>
>-----Original Message-----
>From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
>Sent: Thursday, September 07, 2000 10: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..."
> > > ----------------------------------------------------------