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

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

<Quote>
to abstract the ebXML RSS and UDDI interfaces to the same API-like JAXR
yet have one unified level of support, not two like the current JAXR
level 0 and level 1.  
</Quote>

I would take it even one step further (first I'd like to clarify that I
fully support Java and JAXR): A programming language-agnostic mechanism
for accessing registries (call it "GRI" or "Global Registry Interface").
This way, one could send a query to a registry for a Web service
description and not know or care whether the query is processed by a
UDDI Registry, or an ebXML Registry (or a vendor product that is not
UDDI- or ebXML-compliant but conforms to GRI). Perhaps in the future one
will be paying for usage of Web services - consider an agent that
searches multiple registries for a service that matches a given
description and is the least costly. Or, the criteria could be quality
of service (however it is expressed). 

The WS-Inspection specification (part of GXA, not currently in an open
standards consortium) takes one small step in this direction by
specifying a method in which a site can be inspected for service
offerings, regardless of the format of the description documents for
these service offerings. I've written about WS-Inspection on p.2 of my
recent GXA article [1].

Joe

[1] http://www.developer.com/java/web/article.php/10935_2209991_2

Duane Nickull wrote:
> 
>  From an architectural perspective, WSA, WS-I, UN/CEFACT eBusiness
> Architecture and ebXML are becoming the same thing.  UDDI has not
> reacted to fullfill requirements for semantic interchange and other
> advanced ISO/IEC 11179 content associations and user defined
> classifications that are required by the latter two architectures.  The
> latest ebXML v2.5 does facilitate the requirements of those architectures.
> 
> What I would like to see, as a pragmatc technologist, if to abstract the
> ebXML RSS and UDDI interfaces to the same API-like JAXR yet have one
> unified level of support, not two like the current JAXR level 0 and
> level 1.  With the newer requirements from the WSAG, it is only
> inevitable that UDDI will have additional requirements and hence be
> forced to add on more funtionality like semantics (already in the WSA
> document).
> 
> Why re-invent a registry?  Let's consolidate UDDI and ebXML.  I
> personally don't care what we call it - how about "WS-Registry".  The
> technical work will not be hard, getting political cooperation is once
> again likely to become the barrier <sigh>
> 
> Duane Nickull
> --
> Yellow Dragon Software Corp. - http://www.yellowdragonsoft.com
> Service Oriented Architectures - ebXML, Web Services, Registry Downloads
> Project Team lead - United Nations CEFACT eBusiness Architecture
> +1 (604) 738-1051
> ***********************************
> 
> Chiusano Joseph wrote:
> > <Quote1>
> > I suggest that you extend the TN a bit to show how to categorize a Web
> > service as a service that is described by WSDL and communicates using
> > SOAP, and that you show how to search the registry for WSDL services
> > (comparable to the Using WSDL with UDDI best practice document -- soon
> > to be replaced by another, more detailed technical note.)
> > </Quote1>
> >
> > Absolutely. That should be the 2nd TN in our Web Services series - I
> > suggested that to the TC several months ago as well.
> >
> > <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.
> >
> > 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,"
> >
> > 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?
> >
> > Thanks,
> > Joe
> >
> > Anne Thomas Manes wrote:
> >
> >>Thanks for the pointer to the technical note. I suggest that you extend the
> >>TN a bit to show how to categorize a Web service as a service that is
> >>described by WSDL and communicates using SOAP, and that you show how to
> >>search the registry for WSDL services (comparable to the Using WSDL with
> >>UDDI best practice document -- soon to be replaced by another, more detailed
> >>technical note.)
> >>
> >>And I now I think I see your point -- 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?
> >>
> >>Anne
> >>
> >>----- Original Message -----
> >>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> >>To: "Anne Thomas Manes" <anne@manes.net>
> >>Cc: <regrep@lists.oasis-open.org>
> >>Sent: Tuesday, July 01, 2003 4:55 PM
> >>Subject: Re: [regrep] UDDI as the registry for ebXML components: Typo?
> >>
> >>
> >>><Quote1>
> >>>It is not a typo. It's meant to say that you probably want to use only
> >>>one registry for both UDDI and ebXML.
> >>></Quote1>
> >>>
> >>>But that's not what the following statement says:
> >>>
> >>>"This introduces significant concerns of cost and manageability, because
> >>>ebXML and Web services impose separate infrastructure requirements and
> >>>platform components."
> >>>
> >>>To me, that statement says that one cannot use ebXML for Web services,
> >>>because the two require separate infrastructure requirements and
> >>>platform components. That is definitely not the case. My concern is that
> >>>others may read this statement and interpret it the same way that I did,
> >>>which does nothing for raising awareness of ebXML Registry and Web
> >>>services (in fact, it deters it).
> >>>
> >>><Quote2>
> >>>Likewise the ebXML team might want to produce a similar technical note
> >>>that explains how you can use regrep to register WSDL services.
> >>></Quote2>
> >>>
> >>>Already done - please see:
> >>>
> >>>http://xml.coverpages.org/RegisteringWebServices.pdf
> >>>(dated 12 March 2003)
> >>>
> >>>Joe
> >>>
> >>>Anne Thomas Manes wrote:
> >>>
> >>>>It is not a typo. It's meant to say that you probably want to use only
> >>>
> >>one
> >>
> >>>>registry for both UDDI and ebXML. This technical note explains how you
> >>>
> >>can
> >>
> >>>>use UDDI to register ebXML services. Likewise the ebXML team might want
> >>>
> >>to
> >>
> >>>>produce a similar technical note that explains how you can use regrep to
> >>>>register WSDL services.
> >>>>
> >>>>Anne
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> >>>>To: <regrep@lists.oasis-open.org>
> >>>>Sent: Tuesday, July 01, 2003 4:07 PM
> >>>>Subject: [regrep] UDDI as the registry for ebXML components: Typo?
> >>>>
> >>>>
> >>>>>In the UDDI Technical Note "UDDI as the registry for ebXML components"
> >>>>>[1], the Problem statement (p.3) states:
> >>>>>
> >>>>>"This introduces significant concerns of cost and manageability,
> >>>>
> >>because
> >>
> >>>>>ebXML and Web services impose separate infrastructure requirements and
> >>>>>platform components."
> >>>>>
> >>>>>Is this entirely accurate, given that one can register and maintain
> >>>>
> >>Web
> >>
> >>>>>services in an ebXML Registry? The entire Problem statement is
> >>>>>reproduced below. I wonder if this is a typo.
> >>>>>
> >>>>>Joe
> >>>>>
> >>>>>1.1 Problem statement
> >>>>>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.
> >>>>>
> >>>>>[1]
> >>>>>
> >>>>
> >>http://www.oasis-open.org/committees/uddi-spec/doc/draft/uddi-spec-tc-tn-udd
> >>
> >>>>i-ebxml-20030508.htm
> >>>>
> >>>
> >>>--------------------------------------------------------------------------
> >>
> >>--
> >>
> >>>>----
> >>>>
> >>>>
> >>>>>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
> >>
> >>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