[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] UDDI as the registry for ebXML components: Typo?
<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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]