[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Fw: [regrep] UDDI as the registry for ebXML components: Typo?
If I understand correctly, the proposed change implies that the TN's focus is to enable the addressing of information stored in an ebXML registry from a UDDI registry. That is not entirely correct - TN links UDDI to multiple types of ebXML framework components without the requirement that they be registered in ebXML reg/rep. Daniel > -----Original Message----- > From: Anne Thomas Manes [mailto:anne@manes.net] > Sent: Wednesday, July 02, 2003 8:35 PM > To: Uddi-Spec > Subject: [uddi-spec] Fw: [regrep] UDDI as the registry for > ebXML components: Typo? > > > FYI: > > I've been having a lengthy discussion with the regrep TC > regarding the Registering ebXML in UDDI TN. They have some > concern with the phrasing of the problem statement -- > particularly the implication that using ebXML imposes > significant increased cost and management. Here is some > proposed rewording. > > Anne > > ----- Original Message ----- > From: "Chiusano Joseph" <chiusano_joseph@bah.com> > To: "Anne Thomas Manes" <anne@manes.net> > Cc: <regrep@lists.oasis-open.org>; <karl.best@oasis-open.org> > Sent: Wednesday, July 02, 2003 12:20 PM > Subject: Re: [regrep] UDDI as the registry for ebXML components: Typo? > > > > <Quote> > > I'm still having trouble understanding what can be easily > > misinterpreted. Can you perhaps propose some alternate > wording? Is it > > as simple as just saying "ebXML services and Web services" > rather than > > "ebXML and Web services"? > > > > Just trying to understand the problem... > > </Quote> > > > > Thanks Anne. I appreciate your working with us, and I know > you and the > > other UDDI folks have nothing but good intentions. I've > already made a > > motion to have our TC chair vet this with the UDDI TC > chairs (with no > > opposition from our TC so far), but for what it's worth > here's how I > > would change the phrase - but I'll start with the current > version of > > the first and second paragraphs on p.3 of the TN under "1.1 Problem > > Statement", so that the context is clear: > > > > <CurrentParagraphs> > > Multiple consortia have initiated pilot projects using the ebXML > > framework for business-to-business transactions, while corporations > > have also begun adopting ebXML technologies for internal > use. At the > > same time Web service technologies, which have significant momentum > > due to unprecedented industry support, are also being > rolled out. This > > introduces significant concerns of cost and manageability, because > > ebXML and Web services impose separate infrastructure > requirements and > > platform components. > > > > As a universal technology for publication and discovery of service > > metadata, UDDI allows the bridging of the two infrastructures by > > accommodating metadata registrations for Web services as > well as ebXML > > framework components, enabling interoperability among > trading partners > > using ebXML or Web services. However, a prescribed methodology of > > modeling services and components which are conformant to ebXML > > specifications is required to make interoperable solutions > possible. > > </CurrentParagraphs> > > > > <ProposedParagraphs> > > Multiple consortia have initiated pilot projects using the ebXML > > framework for business-to-business transactions, while corporations > > have also begun adopting ebXML technologies for internal > use. At the > > same time Web service technologies, which have significant momentum > > due to unprecedented industry support, are also being rolled out. > > There may be situations in which a UDDI user may wish to > access ebXML > > framework components that are registered in an ebXML registry. This > > Technical Note provides guidance on how to handle such scenarios. > > > > In addition to being a universal technology for publication and > > discovery of service metadata, the fact that UDDI also enables > > discovery ebXML framework components can help enable > interoperability > > among trading partners that use UDDI and ebXML registry. However, a > > prescribed methodology of modeling services and components > which are > > conformant to ebXML specifications is required to make > interoperable > > solutions possible. </ProposedParagraphs> > > > > Thanks, > > Joe > > > > Anne Thomas Manes wrote: > > > > > > See inline... > > > > > > ----- Original Message ----- > > > From: "Chiusano Joseph" <chiusano_joseph@bah.com> > > > To: "Anne Thomas Manes" <anne@manes.net> > > > Cc: <regrep@lists.oasis-open.org> > > > Sent: Wednesday, July 02, 2003 11:14 AM > > > Subject: Re: [regrep] UDDI as the registry for ebXML components: > > > Typo? > > > > > > > <Quote1> > > > > My interpretation of the paragraph is "ebXML services and Web > services", > > > > where "ebXML services" = services that communicate > using the ebXML > > > > infrastructure (ebMS and possibly CPPA and BPSS), and "Web > > > > services" = services that communicate using the SOAP/WSDL > > > > infrastructure. </Quote1> > > > > > > > > That's a fair interpretation, I believe. In light of that, I'll > restate > > > > the quote from the UDDI TN: > > > > > > > > "This introduces significant concerns of cost and manageability, > because > > > > ebXML and Web services impose separate infrastructure > requirements > > > > and platform components." > > > > > > > > So given your interpretation, this would mean ([]'s indicate > > > > substitution of your intepretation into original text): > > > > > > > > "This introduces significant concerns of cost and manageability, > because > > > > [services that communicate using the ebXML infrastructure (ebMS > > > > and possibly CPPA and BPSS)] and [services that > communicate using > > > > the SOAP/WSDL infrastructure] impose separate infrastructure > > > > requirements and platform components." > > > > > > > > I think that's fair - separate infrastructure and platform > > > > components are required in cases where one is > creating/maintaining > > > > a CPPA or > BPSS, > > > > and where one is creating WSDL description and SOAP messages > > > > (using a SOAP toolkit, for instance). > > > > > > We agree. > > > > > > > > > > > I would also emphasize that UDDI does not support > creation of WSDL > > > > descriptions and SOAP messages either. > > > > > > Agreed. I don't think anything in the TN implies that it > does. UDDI > > > is a registry, which is one, small, optional piece of the > SOAP/WSDL > > > Web > services > > > infrastructure. > > > > > > > > > > > <Quote2> > > > > There is more to "infrastructure" than just the registry. The > > > > ebXML infrastructure is different from the SOAP/WSDL > > > > infrastructure, and > users > > > > must deploy different platform components to support the two > > > > infrastructures. </Quote2> > > > > > > > > Yes (please reference my response direction above). I > would then > > > > infer from that that there is more to "infrastructure" > than just a > > > > UDDI registry, as ebXML Registry and UDDI Registry are (in my > > > > mind) very close to being equal in terms of functionality and > > > > capability for registration and maintenance of Web service > > > > descriptions, given v3.0 > of > > > > both specifications. > > > > > > Agreed. And I think this is the point of the TN. If you are using > > > both infrastructures, you don't need both registries. > It's advisable > > > to pick > one > > > or the other. If you decide to use UDDI, here's how to > register your > ebXML > > > services in it. > > > > > > You have a similar document that says if you decide to use RegRep, > here's > > > how to register your SOAP/WSDL services in it. I have no > objection > > > to > this > > > document. It think it's a very useful document. But I do > think that > > > you > need > > > to expand it, as I mentioned before. > > > > > > > > > > > <Quote3> > > > > You can register both SOAP/WSDL services and ebXML > services in a > > > > UDDI registry. Of course you can say the same for an ebXML > > > > registry. </Quote3> > > > > > > > > <Quote4> > > > > But this is a UDDI TN, so it makes sense for this TN to explain > > > > how to use UDDI to support both environments. </Quote4> > > > > > > > > What would you think if we presented information in an ebXML TN > > > > that could easily be misinterpreted by readers regarding UDDI's > capabilities? > > > > > > I'm still having trouble understanding what can be easily > misinterpreted. > > > Can you perhaps propose some alternate wording? Is it as > simple as > > > just saying "ebXML services and Web services" rather than > "ebXML and > > > Web services"? > > > > > > Just trying to understand the problem... > > > > > > Anne > > > > > > > Joe > > > > > > > > Absolutely > > > > > > > > Anne Thomas Manes wrote: > > > > > > > > > > Joe said: > > > > > <snip> > > > > > > <Quote2> > > > > > > the technical note uses the term "Web services" to refer to > WSDL-base > > > > > > Web services, and it implies that ebXML services are not Web > services. > > > > > > Is this your objection? > > > > > > </Quote2> > > > > > > > > > > > > Not exactly - my observation is with the wording of the > > > > > > following > > > > > > phrase: > > > > > > > > > > > > "ebXML and Web services impose separate infrastructure > requirements > > > and > > > > > > platform components." > > > > > > > > > > > > To the reader, "ebXML and Web services" could mean "ebXML > > > > > > services > and > > > > > > Web services" (where "ebXML services" could mean BPSS for > example), or > > > > > > it could mean "ebXML and Web services". Whichever one it is > > > interpreted > > > > > > as, I think it is not accurate because one can register and > maintain > > > Web > > > > > > services descriptions (whether they be WSDL, > DAML-S, etc.) in > > > > > > an > ebXML > > > > > > Registry. > > > > > > > > > > Three points: > > > > > - Given the readership of this TN (presumably UDDI > users), I'm > > > > > not > sure > > > that > > > > > the destinction makes a lot of difference. My > interpretation of > > > > > the paragraph is "ebXML services and Web services", > where "ebXML > services" = > > > > > services that communicate using the ebXML > infrastructure (ebMS > > > > > and > > > possibly > > > > > CPPA and BPSS), and "Web services" = services that > communicate > > > > > using > the > > > > > SOAP/WSDL infrastructure. > > > > > - There is more to "infrastructure" than just the > registry. The > ebXML > > > > > infrastructure is different from the SOAP/WSDL > infrastructure, > > > > > and > users > > > > > must deploy different platform components to support the two > > > > > infrastructures. > > > > > - The whole point of the technical note is to help > users reduce > > > > > one > > > piece of > > > > > that duplicate infrastructure: the registry. You can register > > > > > both > > > SOAP/WSDL > > > > > services and ebXML services in a UDDI registry. Of course you > > > > > can > say > > > the > > > > > same for an ebXML registry. But this is a UDDI TN, so > it makes > > > > > sense > for > > > > > this TN to explain how to use UDDI to support both > environments. > > > > > > > > > > > > > > > > > Adding of the following phrase in the front of the > above one > > > > > > (I > > > believe) > > > > > > skews the message even further: > > > > > > > > > > > > "This introduces significant concerns of cost and > > > > > > manageability," > > > > > > > > > > Do you dispute that maintaining dual infrastructures > introduces > > > additional > > > > > costs and management? > > > > > > > > > > > > > > > > > So my bottom-line question would be: Why should there be a > > > > > > need > for > > > > > > separate infrastructure requirements and platform > components > > > > > > for > ebXML > > > > > > and Web services? > > > > > > > > > > Because most Web services platforms (.NET, WebLogic, > WebSphere, > Oracle > > > 9iAS, > > > > > EAServer, JBoss, WASP, GLUE, Cape Clear, XMLBus, PocketSOAP, > SOAP:Lite, > > > > > etc.) don't support ebXML. And most people that build > SOAP/WSDL > > > > > Web > > > services > > > > > use one of these platforms. > > > > > > > > > > Regards, > > > > > Anne > > > > > > > > ---------------------------------------------------------------------- > > ---- > -- > > > ---- > > > > > > > You may leave a Technical Committee at any time by visiting > > > > http://www.oasis-open.org/apps/org/workgroup/regrep/members/le ave_workgroup. > > php ---------------------------------------------------------------------------- ---- > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup. php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro up.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]