OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [regrep] RE: [uddi-spec] ebXML Registry / UDDI Convergence


Matthew, you make it clear that you want convergence, with
interoperability being a consolation prize and go further suggesting a
new "super-standard" based on both works.

What I haven't heard to date in this thread and in general are well
articulated statements contrasting Reg/Rep and UDDI, not the
technologies but rather their respective missions. From a technology
perspective, UDDI strengths come being focused to providing a registry
solution for Web services; the data structures, APIs, intra- and
inter-registry communication and security model where designed and
evolved to meet these needs. On the other hand, I would expect that
Reg/Rep's strengths derive from a design that is focused on ebXML's
needs which are different and arguably expanded scenarios with respect
to those of Web services.

One should step back and consider the needs on the
scenarios/requirements not the technologies. David Webber's suggestion
that "we need a PPT at a minimum as a discussion point so that people
can understand what each world looks like today" seems reasonable at
this time. 

What I'm hearing and fully support is work on technical notes on
cooperative use cases, an activity that had already been undertaken in
UDDI.org and I would like to see continue within the TC. We should
continue down this path at the very least.  In particular, Ed Mooney
from Sun had authored "UDDI as the Registry for ebXML Components" but
unfortunately UDDI.org due to the transition activities and the need to
complete the V3 spec was not in a position to advance to work further as
a TN prior to the transition to OASIS. We now have the opportunity to do
so, and we should.

If we were to engage on a joint subcommittee to explore
integration/convergence/super-standard as it's been suggested, I'm of
the opinion this would have to be driven by the needs and the desire to
do so by both this and the Reg/Rep TC. I'm not hearing support for this
just yet from this TC's membership at large nor have I heard interest
coming from the Reg/Rep TC. Indeed I hear from Anne that her proposals
met with resistance. At the very least for me to support proceeding with
the formation of a joint committee I would require support of both TCs.
That said, I question the need to do so. I want to stay the course and
proceed with work consistent with our charter. 

Luc Clement

 
-----Original Message-----
From: Matthew MacKenzie [mailto:matt@xmlglobal.com] 
Sent: Friday, September 27, 2002 10:52
To: Bob Atkinson
Cc: David RR Webber - XMLGlobal; uddi-spec@lists.oasis-open.org;
regrep@lists.oasis-open.org

Bob,

As you know, UDDI is now an OASIS specification and that means there is
a much wider audience involved with a say in how these sort of things
happen.  I think it is an appropriate work item to consider given the
new organization, even if it is shot down.

-Matt



On Friday, September 27, 2002, at 10:26  AM, Bob Atkinson wrote:

> This territory was well considered and covered in UDDI.org during the
> v2
> round a few years ago. Nothing has changed in the interim that would 
> indicate that the analysis would be different a second time around.
>
> I suggest that we spend our time on more focused, direct, and 
> constructive work.
>
> 	Bob
>
> -----Original Message-----
> From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
> Sent: Friday, September 27, 2002 9:27 AM
> To: David RR Webber - XMLGlobal
> Cc: uddi-spec@lists.oasis-open.org; regrep@lists.oasis-open.org
> Subject: Re: [regrep] RE: [uddi-spec] ebXML Registry / UDDI 
> Convergence
>
> I'm suggesting a new "super-standard" based on both works, with a 
> modular design just like ebXML Registry has now.  A robust registry 
> needs both replication and federation, so that isn't an issue to me.
>
> -Matt
> On Friday, September 27, 2002, at 08:42  AM, David RR Webber - 
> XMLGlobal wrote:
>
>> Message text written by Matthew MacKenzie
>>>
>> As for coexistence -- I can't see that, not from a business/sales 
>> perspective at least. <
>>
>>>>>>>>>
>>
>> Matt,
>>
>> Now you've got me putting on my Marketing / Bus Dev hat!
>>
>> The big difference I see is the formal replicated v federated models,

>> coupled with the tModel/WSDL v ebXML architecture stack.
>>
>> And this then comes back around to the business needs.
>>
>> So if you are trying to deploy an eMarketplace with lots of eCommerce

>> sites and you want a strict and formal member directory / 
>> participation control structure - with simple push/pull content 
>> interactions - then UDDI makes sense.
>>
>> If you are looking to build a cross industry supplychain B2B world 
>> with multi-threaded business processes between many collaborating 
>> peers then ebXML gives you that.
>>
>> Similarly if you are looking to document reference industry domain 
>> vocabularies, transactions and classifications and codelists, then 
>> ebXML registry is the right choice.
>>
>> Does it makes sense to keep complete separation for ever here?  
>> Clearly three years from now we would like to see a common 
>> infrastructure - and providing support for the two mechanisms - 
>> replicated / federated.
>>
>> But as a marketing person - I'm seeing you'd make the product modular

>> - so customers can buy a simple base registry, and then step-up to 
>> more functionality as they need it.
>>
>> DW.
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC