Re: [regrep] A different perspective on OASIS ebXML v3 enhancementproposals.. .

[Matthew MacKenzie <matt@xmlglobal.com>]

Joel,

Your points are valid (although I may disagree on some details), but 
this work (your [1-3]) was started before UDDI was swallowed into 
OASIS.  I think we should finish our v3 cycle, and start v4 with an eye 
toward integration of the two registry technologies.  Vendors, such as 
my own company, will NOT LIKELY be undertaking the pain of marketing two 
separate registry products.  I am hoping to not see a repeat of what is 
happening with UBL and Core Components with UDDI and ebRegRep.

I'm certainly not willing to drop my proposal because someone made a 
limited REST interface to UDDI available.  I am willing, however, to 
take on work items for v4 which help bring the registries together.

-Matt

On Wednesday, August 7, 2002, at 04:50  PM, Munter, Joel D wrote:

>
> All right, I said that I was now a lurker... but with these latest
> proposals, I feel that I must offer some opinions.
> [1] I have read the Cooperating Registries Proposal v0.7
> [2] I have read the Event Notification Proposal 0.5
> [3] I have read the REST Proposal v0.5
>
> While all are well written and include substantial detail, I offer the
> following "controversial" position:
>
> (If you cannot handle controversy, please skip this entire email.)
>
> 80-90% of the requirements covered by these three proposals can be 
> handled
> by a well thought out and judicious use of UDDI.  In my humble opinion, 
> you
> are reinventing much and not adding significant value.  Please take your
> hands away from the keyboard and read on before replying.  I know that 
> you
> want to begin replying, please don't yet.  I see a very big
> not-invented-here attitude.  This was also true when much of the web
> services modeling was added to the OASIS ebXML v2 specifications.  I 
> argued
> then and I am doing so again now.  With UDDI specifications now at 
> OASIS,
> you are all responsible for looking much more deeply into cooperation
> between the two environments.
>
> I ask you all to thoroughly read UDDI V3.
>
> Most of the Use Cases Presented in [1] can be handled through the use 
> of the
> UDDI business relationship structure.  This was available in UDDI v2.
>
> There are tModels and simple taxonomies already available that describe
> peer-to-peer, parent-child, and identity relationships between business
> entities in UDDI.  As services are contained within business entities, 
> guess
> what, with good programming and best practices, that relationship can be
> extended to services within businesses.
>
> The use of the relationship structure can be extended to reflect any 
> number
> of hierarchies of ebXML registries.  These cover almost all of the Use 
> Cases
> listed within [1].  tModels and taxonomies have been discussed 
> previously on
> this list and more recently on the UDDI lists that describe good 
> technical
> approaches at "registering ebXML registries and ebXML based services 
> within
> UDDI.  These Technical Notes and best practices must be finished but are
> available for review in draft form.  Again, this was available in V2
> registries.
>
> UDDI V3 adds multi-registry communication, object transfer, subscription
> protocols, and maybe as a surprise to some of you, even an optional 
> RESTful
> interface to some of the UDDI functionality.  The subscriptions 
> protocol and
> RESTful stuff in UDDI V3 obviate the need for most (but not all) of [2] 
> and
> [3], respectively.  All of the relevant security requirements and
> node/registry policy management that UDDI should add was added in V3.
>
> I ask you all to keep an open mind.  Before you commit to reinventing, I
> again request that you educate yourselves on UDDI V2 and V3.
>
> Thanks,
> Joel Munter
> Distributed Systems, Intel Labs
> joel.d.munter@intel.com
> (480) 552-3076
> (602) 790-0924 (cell)
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>