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


Luc,

Thanks for taking the time to deliver this response.  It is my 
understanding that technical work has been done by a few parties (Joel 
Munter/Ed Mooney, Christina Portillo, Farrukh Najmi and the JAXR team, 
Anne Thomas Manes) to look at how the two registry technologies would 
fit together.  I think everyone has come to the realization that 
cooperation between both is possible and feasible.  Yes, more work 
needs to be done, and maybe someone needs to summarize the technical 
issues.

What is left, from my perspective at least, are the political issues.  
Resistance on the ebXML Regrep side is significantly diminished, and 
all I've seen and heard on the topic with ebXML Regrep suggests a 
willingness to start considering this concept.  No one on the OASIS 
side was terribly happy about going far on the UDDI convergence topic 
when UDDI was not under the umbrella of a democratic standards body 
such as OASIS.

I've seen more support on the UDDI side than dissent (not counting the 
two chairs ;-p), so why not setup a group of people from both sides of 
the fence to discuss some sort of convergence.  If it makes no sense to 
converge, this group will agree to that fact and work on ways to make 
our differences clear to the market and emphasize how the two 
registries can cooperate.  It is clearly a win-win proposition.

Regards,

Matt

On Friday, September 27, 2002, at 12:13  PM, Luc Clement wrote:

> 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