UDDI Liason (Was Re: [regrep] UDDI as the registry for ebXML components: Typo?)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

I think that this situation brings up another issue: Do we have a formal
liason to the UDDI TC? If not, I think we should. If so, did they review
this document and ensure that it correctly reflected ebXML Registry as
well as UDDI?

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/leave_workgroup.
> php
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard