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

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

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