FW: Tokyo POC choreography - my 4c ;-)

[Krishna Sankar <ksankar@cisco.com>]

Hi all,

	I have been agonizing over the reg/rep-discovery-POC scenario. Klaus's
e-mail clearly suggests that we should use the eCo Framework in this area.

	I had a talk with Farrukh, read thru UDDI and eCo specs, read thru some of
the ebXML achieve e-mails, did some independent thinking ..... I have
attached a diagram which shows my thinking and where eCo and UDDI fits in
with the regrep effort.

	We did show standards interoperability at SJ by conducting RosettaNet over
ebXML. We should show additional capabilities and progress at Tokyo.

	One of the areas I was thinking of was the dynamic/configurable trading
networks with discovery et al. I had sent this e-mail before the UDDI
question. Now this is more important to show this capability - to some
extent. We do not have to show all the features but enough to show we are
there.

	There are two ways we can show this :

	a)	By adding the discovery processes in the BP specs and then implementing
them as a part of the reg/rep.
		(Again the excellent use cases by David Burdett illuminate the processes)

	b)	By implementing a few of the eCo APIs as services over the regrep APIs
thus showing interoperability and the extensibility of the framework.

	I like b) because, we do not want to be yet another standard; leveraging is
the key word.

	Looking from the regrep view (which is what I am looking from) and
position, instead of a competing third standard, we now show an
interoperable solution. We are ready for a UDDI provider over our regrep as
well. Now (at least in my mind) the position is clear.

	I am starting to implement the regrep seq diagrams - the
create/approve/deprecate/query/remove -  and the persistence store. The
logic is that we need this basic regrep functionality even for the Oct f2f.
I also want to see if we can do integration test with any of the folks
*before* the Oct meeting - I had sent an earlier mail on this.

	Then, if everything goes well, any or all of us (who provide the registry
functionality) could do the eCo service layer for discovery - as a stretch
goal. We can attempt at least an implementation (without any integration) so
that we can confidently say the regrep is agnostic to standards.

cheers

Note : In case you all wonder why 4c, I am adding 2c to my previous 2c ;-)

	BTW, It suddenly occurred to me that eCo is a CommerceOne initiative and
the UDDI is an Ariba one. Both have participation from IBM !



-----Original Message-----
From: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
Sent: Thursday, September 07, 2000 2:15 PM
To: ebxml-poc@lists.ebxml.org
Subject: Fwd: UDDI and ebXML


FYI in case you missed this. Nick.

>Date: Thu, 07 Sep 2000 12:24:42 -0700
>From: Klaus-Dieter Naujok <knaujok@pacbell.net>
>Subject: UDDI and ebXML
>To: ebXML General List <ebxml@lists.ebxml.org>
>Reply-to: Klaus-Dieter Naujok <knaujok@pacbell.net>
>X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT (4.0.1381;5)
>Priority: Normal
>List-Owner: <mailto:ebxml-help@lists.ebxml.org>
>List-Post: <mailto:ebxml@lists.ebxml.org>
>List-Subscribe: <mailto:ebxml-request@lists.ebxml.org?body=subscribe>
>List-Unsubscribe: <mailto:ebxml-request@lists.ebxml.org?body=unsubscribe>
>List-Archive: <http://lists.ebxml.org/archives/ebxml>
>List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-request@lists.ebxml.org?body=help>
>
>By now most of you have seen the announcement about UDDI. Many of
>you have posted responses and questions to the announcement. The
>most pressing question is how does it relate to ebXML.
>
>Having spend the last 36 hours in talking to some of you, as well
>as getting guidance from my executive members and project team
>leads let me pass on what my view is in regard to UDDI.
>
>First, it is a very positive sign confirming that our efforts are
>on the right track. With many of our own participants joining the
>project, UDDI will hopefully move from the proprietary solution
>towards a open specification and at the same time ensure
>interoperability with ebXML.
>
>In regard how does it relate to our own work. Many of you may not
>be aware of it, but our Business Process and Register & Repository
>Team had right from the start in their work plan Trading Partner
>registration and discovery. Because of previous work done by
>CommerceNet in this area they did not spend much time on the
>topic. This created the impression that this was not an ebXML
>deliverable. You may recall that our main goal is not to reinvent
>the wheel and instead use work that fits our requirements and
>needs. Therefore the plan was to use the eCo specification
>(http://eco.commerce.net/rsrc/index.cfm) instead of developing our
>own. Having talked to the BP and RR team leads this was
>reconfirmed to me again today.
>
>So where does that leave UDDI and ebXML? In my view ebXML should
>continue with its plan to use the eCo specification since it is a
>open specification and fits our needs. Further, it never hurts to
>take a look at other work in order to reconfirm what one is
>currently doing. Adopting UDDI at this stage is premature since
>there has not been an offer to make this an open specification,
>this is planned for much later. Further, UDDI sits on top of SOAP
>and utilize 30 SOAP type messages for querying, requesting and
>receiving information. Yes, it is true that the services
>identified by the trading partner can be of any type, including
>ebXML. However, one needs to interface to the register in order to
>use it, and that will require to use SOAP and the UDDI SOAP type
>messages. Therefore, instead of ebXML changing its specification
>to be UDDI compliant I see a benefit for UDDI to ensure ebXML
>interoperability as their first step towards a truly open
>development effort.
>
>In closing, I don't see that with the UDDI announcement our game
>plan needs to change. There will always be initiatives that may
>create overlap because companies can't wait for standardization to
>finish. In a perfect world those efforts would ensure
>interoperability.  Knowing that many of our own participants have
>joint UDDI in an effort to ensure openness and interoperability, I
>am convinced that over time UDDI will be a tool ebXML implementers
>can utilize.
>
>Regards,
>
>Klaus
>
>--
>Klaus-Dieter Naujok                                ebXML Chair
>Antioch, CA USA                                +1.925.759.1670
>
>PGP Finger: 6A4B 1683 CD99 E7BE F855  CC2F 4569 6BD8 76BD 1117

Drawing1.jpg