[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] UDDI <> ebXML Reg use case
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC