Re: [regrep] UDDI as the registry for ebXML components: Typo?

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

<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/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