> wrote:
>
> Farrukh,
>
> I agree with those QoS use cases. In addition, I get a sense from the
> DoD that their mostly focusing on making sure a Web service user knows
> their options about what to do in the case of failure. For example:
>
> * If this service fails to execute, then the alternative is to
> _______.
> * If this service fails to execute, then contact _________.
Actually, this gets more into Web Services Choreography (exception
cases), and things such as WS BPEL. I believe that this should be
separate from the registry information model, and should be specified in
the choregraphy "scripts", which might be stored in the registry.
> These too can be addressed with the slots and query capabilities. I
> got the DoD QoS talk in a different setting from Joe. Joe, do you
> agree or have any others to suggest?
In the future I will - we're just getting started discussing this for
DOD NCES (Netcentric Enterprise Services).
Joe
> -Paul
>
> BTW, UDDI is addressing range checking in their search capabilities.
> I do participate in UDDI too, but I was on vacation part of last week
> and need to catch up on what went on during the UDDI F2F in New
> Zealand. For some reason the government wouldn't cover me attending
> that one. :-)
>
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:]
> Sent: Monday, April 05, 2004 10:34 PM
> To:
> Subject: Re: [regrep] QoS in ebXML Registry?
>
> Chiusano Joseph wrote:
>
> > During one of my recent client meetings (for service
> > discovery within
> > DoD), the issue of QoS came up as an important topic.
> >
> > I don't have access to the UDDI TC item I reference here
> > (I'm not a
> > member of the UDDI TC), but I understand that the UDDI TC
> > has been
> > working on a TN called "Representing Web Services Quality
> > of Service
> > Information in UDDI"[1]. Without knowing the details
> > beyond what is in
> > [1], have we given any thought to this issue for our
> > specifications?
> >
> > [1]
> > http://lists.oasis-open.org/archives/uddi-spec/200404/msg00005.html
> >
> >
>
> Here are some use cases of QoS queries from that document:
>
> * “show me all Web services implementations that support
> interface X with a request-response performance less
> than 100milliseconds”.
>
> * “list the binding templates of service A with a
> reliability of 99% or higher”
>
> * “are there any binding templates of services owned by
> business entity B that have experienced more than 100
> SOAP faults”.
>
> It should be noted that we can easily do all of above use
> cases thanks to our support for Arbitrary Attributes using
> Slots and our support for Ad hoc SQL and XML Filter Queries.
>
> For example a RegistryObject in an ebXML Registry could
> have:
>
> * A Slot named "RequestResponsePerformance" whose value
> is integer milliseconds.
> * A Slot named "Reliability" whose value is a float %
> value.
> * A Slot named "FaultCount" whose value is an integer
> (Note we already have ability to associate Services to
> Organizations)
>
> Note that we do support full range based queries in ebXML
> Registry unlike UDDI. So we will not be hampered by the
> issue quoted from the UDDI tech note below:
>
> "Given that UDDI does not yet have range-based searching, it
> may also be valuable to allow searches based on ratings.
> It will be valuable to have simple checked taxonomies for
> performance, throughput, reliability and availability
> ratings.
>
> A developer might ask:
>
> * “show me all Web service implementations that support
> interface X with reliability rated ’High’”
>
> An administrator keeping track of the quality of the hosting
> might ask:
>
> * “what binding templates have ‘Low’ performance”
>
> Search criteria can also be used in combination, such as the
> following:
>
>
> * “what binding templates have ‘High’ performance and
> zero SOAP faults”
>
> "
>
> Again all of above use cases would be handled with the same
> ease as the range based queries earlier.
>
> In summary QoS Metadata is just another run-of-the-mill use
> case for the ebXML Registry.
>
> --
> Regards,
> Farrukh
>
> 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.
--
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton
