[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [Paper on Federated Registries] Re: [Fwd: Semantic Web Services Architecture Committee Requirements Document]
Kathryn, This is also of interest for BPSS. We're currently looking at BSI (Business Service Interface) needs for V3. BPSS already has extensive abilities to define QoS parameters for transport level exchanges. These then of course need to be mapped to a transport service - and that service then needs to report back standard responses (succeed / failure) and conditions. BPSS uses a set of standard flags for that - and we've itemized those in the schema. I've also implemented in the model approach - exchange profiles - so that the QoS can be described and named - and then selected and supported by participants - eg. Normal, Urgent, Required, et al. If you look at the JPG here:- http://drrw.net/visualscripts/BPSS-V2/BPSS-Request-Respond-Model.jpg You will see the Exchange Profiles on the right hand side of the model and the parameters associated (in IE it will "shrink" the image, click on the bottom corner of the image to expand it fullsize again). It would be trivial to modify this BPSS model to document registry QoS and service interchanges. A tutorials on this is available from the resources link: http://drrw.net/visualscripts/#ebxml Enjoy, DW. ----- Original Message ----- From: "Breininger, Kathryn R" <kathryn.r.breininger@boeing.com> To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; <regrep@lists.oasis-open.org> Sent: Thursday, June 03, 2004 5:29 PM Subject: RE: [regrep] [Paper on Federated Registries] Re: [Fwd: Semantic Web Services Architecture Committee Requirements Document] Consider it added. -----Original Message----- From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] Sent: Thursday, June 03, 2004 10:45 AM To: regrep@lists.oasis-open.org Subject: Re: [regrep] [Paper on Federated Registries] Re: [Fwd: Semantic Web Services Architecture Committee Requirements Document] Thanks for sharing Joe. This reminds me of the need for doing an update on the Publishing Web Services TN to add details on how to publish QoS attributes for Web Services and how to use those QoS attributes for Service discovery. Our existing specs handle this use case already but the details need to be spelled out. I propose we add this to our next TC meeting's agenda. Thanks. -- Regards, Farrukh Chiusano Joseph wrote: >FYI: I sent the e-mail below to the SCM subcomittee, then noticed one >of the citations [1] which was a paper on "Discovery of Web Services in >a Federated Registry Environment" - so I thought it might be of >interest to the full TC. Includes references to both UDDI and ebXML >Registry. > >This University of Georgia (US) paper discusses the METEOR-S Web >Service Discovery Infrastructure[2][3], which provides an ontology >based infrastructure to provide access to registries divided based on >business domains and grouped into federations. It also discusses how >Web Service discovery is carried out within a federation. > >[1] http://lsdis.cs.uga.edu/Library/download/MWSDI-ICWS04-final.pdf >[2] http://lsdis.cs.uga.edu/proj/meteor/mwsdi.html >[3] http://lsdis.cs.uga.edu/Projects/METEOR-S/index.php > >Joe > >Joseph Chiusano wrote: > > >>Just announced: The Semantic Web Services Initiative (SWSI) has >>released architecture requirements for Semantic Web Services. >>Highlights are included below - including service lifecycle and >>ontology management. >> >>[1] http://www.daml.org/services/swsa/swsa-requirements.html >> >>Thanks, >>Joe >> >>HIGHLIGHTS: >> >>(1) Semantic Web Services are viewed as a way to extend the >>capabilities of web services in the direction of dynamic >>interoperability, thereby making it possible for clients to >>successfully utilize web services without prior arrangements between >>people that are realized in rigid software protocols, and immutable >>ontologies or meta-data. >> >>(2) The functions addressed by the Semantic Web Services Architecture >>will include: >> >>* Dynamic Service Discovery: The capability for a software agent to >>identify candidate services for particular objectives; includes >>candidate service matchmaking and brokering functions. >> >>* Service Selection and Composition: The capability to dynamically >>select and compose services to achieve some objective; includes >>failure recovery and compensation mechanisms, as well as choreography >>interpretation and execution. Also includes ontology translation >>services. >> >>* Negotiation and Contracting: Ability for two agents to mutually >>formulate a shared agreement in terms of performance to be provided; >>includes dispute resolution and compliance. >> >>* Semantic Web Community Support Services: Capabilities associated >>with sharing semantic descriptions, ontologies, ontology mappings, and >>service catalogs within and across communities, and managing these >>items as well. >> >>* Semantic Web Service Lifecycle and Resource Management Services: >>Capability to management the lifecycle of Semantic Web Services. >> >>* Other: Includes QoS requirements (time, cost, reliabilty, >>operational metrics, etc.), and the capability to discover a service >>based on these factors. >> >>-------- Original Message -------- >>Subject: Semantic Web Services Architecture Committee Requirements >>Document >>Resent-Date: Thu, 3 Jun 2004 11:28:16 -0400 (EDT) >>Resent-From: public-sws-ig@w3.org >>Date: Thu, 03 Jun 2004 11:28:06 -0400 >>From: Mark Burstein <burstein@bbn.com> >>To: public-sws-ig@w3.org >> >>The Architecture Committee of the Semantic Web Services Initiative >>(SWSI) >>has spent the last few >>months putting together an overview of the functional requirements >>that a comprehensive approach to architectures for semantic web >>services should include. While different communities will need more >>or less of some of the features covered, we felt it was worthwhile to >>try to >>take a longer term view in this exercise. >> >>The document is available for review and comment from the SWSA >>committee home page at http://www.daml.org/services/swsa/ >> >>The document itself is located at >> >>http://www.daml.org/services/swsa/swsa-requirements.html >> >>Comments can be sent to public-sws-ig or to me personally at the >>address below. >> >> > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgr oup.php. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]