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

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

You may not like to hear this...

----- Original Message -----
From: "Daniel Feygin" <feygin@unitspace.com>
To: "'Anne Thomas Manes'" <anne@manes.net>; "'Uddi-Spec'"
<uddi-spec@lists.oasis-open.org>
Sent: Thursday, July 03, 2003 2:22 AM
Subject: RE: [uddi-spec] Fw: [regrep] UDDI as the registry for ebXML
components: Typo?


> If I understand correctly, the proposed change implies that the TN's focus
> is to enable the addressing of information stored in an ebXML registry
from
> a UDDI registry.  That is not entirely correct - TN links UDDI to multiple
> types of ebXML framework components without the requirement that they be
> registered in ebXML reg/rep.
>
> Daniel
>
>
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Wednesday, July 02, 2003 8:35 PM
> > To: Uddi-Spec
> > Subject: [uddi-spec] Fw: [regrep] UDDI as the registry for
> > ebXML components: Typo?
> >
> >
> > 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/le
> ave_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
>
>
> You may leave a Technical Committee at any time by visiting
>
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
> up.php
>
>