Re: [regrep] UDDI <> ebXML Reg use case

[Farrukh Najmi <farrukh.najmi@sun.com>]

Max Voskob wrote:

> Hi there! Me again :)
>  
> I'm working with web services (using C++, C#, .NET, Perl, etc), but 
> my client decided to use ebXML registry due to its superiority.

The very reason why your "client decided to use ebXML registry due to 
its superiority" is because of the power and flexibility of the ebXML 
Registry API. They would not have the same power and flexibility with a 
UDDI API. If they could then they would just use UDDI.

> However, I'd like to use my tools for webservice development. I'm 
> missing out :((( My performance dropped coz all my tools expect UDDI 
> !!! I have to do an awful lot of manual work now. I'm unhappy. 

I am not sure what manual work and what performance drops you are 
referring to. If you are referring to the fact that we use MIME 
attachments in our WSDL and most WSDL binding tools do not support it 
then that is a tool issue. I agree that there are fewer tools for ebXML 
Registry than UDDI but if there is a demand for it (as you suggest) then 
vendors will deliver on that demand.

> I want to use my UDDI client tools with the ebXML registry.

Why do you want to use UDDI client tools with the ebXML registry? I 
assume that is because you are invested in UDDI and you have a need to 
support legacy UDDI client code. 

>  
> Does it sound like a real life situation?

The need to support legacy UDDI code is a "a real life situation" and I 
think that vendors will respond to that need. I think the need should be 
addressed by a product / implementation solution and not by a spec solution.

> Here is a use case for your attention (see the attachment).
>  
> I'd like to ask the same question (feel free to ignore again):



Please Max, lets be fair.

Your question was not ignored. It was answered with careful deliberation 
and thought at:

       http://lists.oasis-open.org/archives/regrep/200302/msg00032.html


The ebXML Registry TC can close our lists to non-members at any time. We 
do not do so because we value all input and feel that we benefit from it.

> Would the honorable TC be interested in formalising use of some UDDI 
> interfaces with ebXML Reg?

Let us for a minute assume that formalising use of some UDDI interfaces 
with ebXML Reg in spec space made sense. If that were the case then I 
would argue that the UDDI TC should specify a binding from UDDI to ebXML 
Registry TC. That would make sense from a layered architecture perspective.

Since you are a member of the UDDI TC, why do you not propose within the 
UDDI TC for them to specify a binding to ebXML Registry? Would that not 
solve your use case?

I could support the ebXML Registry to review and approve any such 
specification binding UDDI to ebXML Registry. I cannot support that 
specification being owned and defined by the ebXML Registry TC. Note 
that this is the exact same issue as binding from CCTS to ebXML Registry 
(that caused much discussion on this list) and I have the same 
consistent position:

-Keep ebXML registry specifications minimal and free of domain specific 
models

-Have other TCs define binding from domain specific models to ebXML Registry

-ebXML Registry TC can offer to help / review / approve other TCs define 
their bindings to ebXML Registry as long as it is clear that the other 
TC owns the specification and is ultimately responsible for it.

-- 
Respectfully,
Farrukh