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

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

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