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

["Anne Thomas Manes" <anne@manes.net>]

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