[
Lists Home |
Date Index |
Thread Index
]
<out of subject>
You probably would not "reconfigure dynamically" (combining those 2
words sounds dangerous to me)
</out of subject>
Why?
<quote1>
Where do I go if a web service fails? To a new one? Which one?
</quote1>
OK, so we need in the web services orchestration stack a component which
tell
If no answer from my web service
choose a new service
Basically, we could choose a new one with the SOAP format of the message: I
need to find a web service with the almost exact "type of" data in and out.
Should we should consider extending UDDI?
For QoS and confidence in a web service (2 different things I know): it
might be a web service which says: this one is good, this one has never been
used in production.
For instance, let's say my application need to make a web research: I could
choose Google API or Altavista (let's assume there is one and Altavista is
really competing with google). Google doesn't give me any answer: the
application is looking through an extended UDDI directory and since
Altavista give me an answer the application is using it.
Basically, the mechanism is more general: it can be used to change a used
service not only bc it fails but also bc the answer is not good enough.
What do you think?
It would be not be that easy to implement in a way the developer doesn't
have anything to do but this could be really useful.
Besides if the API slightly differs in the SOAP format even (through use of
metadata) know if this is important or the service should still be used...
-----Message d'origine-----
De : Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Envoye : jeudi 18 septembre 2003 15:13
A : Nicolas Toper
Cc : xml-dev@lists.xml.org
Objet : Re: [xml-dev] Web Services and Quality
<Quote1>
Basically, the first problem is about QoS: if a web service fail what do
you do. Where do I go if a web service fails? To a new one? Which one?
</Quote1>
One possibility would be that a failed Web service would be taken out of
the equation - that is, it would not be considered in the final "mix" of
Web services whose results are ranked by the requesting Web service.
Another possibility is that the requesting Web service could require (as
one of its criteria) that a Web service be compliant with a widely
accepted reliable messaging protocol (several are under development at
this time) and if it is not, then it won't be considered (i.e. that
could be a "showstopper" criterion).
<Quote2>
Where do I find them (which UDDI directory should I check and what if it
is not avalaible :=))
</Quote2>
This aspect is about Communities of Interest. A UDDI or ebXML Registry
(or network of federated registies) could be established for a given
industry, and vendors/businesses would join this network because of the
visibility (and subsequent business) it would bring them. Here's an
example from a recent announcement (May 2003[1]):
"Picture Services Network, Inc. (PSN) today announced the selection of
Systinet Corporation to provide its Universal Description, Discovery and
Integration (UDDI) registry for the PSN Directory Service. The PSN
Directory Service provides a cost-effective means for any camera
manufacturer, photofinishing company, or online photo service to make it
easy for their customers to find, access or use digital photography
services."
The "not available" aspect would be covered in my response to <Quote1>
above (i.e. the same concept could apply to registries, as registries
would be accessable via Web services).
<Quote3>
The second problem is about choosing a web service: how do I choose
between 2 web services ?
</Quote3>
This is actually much more extensive - it's about how to choose between
a very large (potentially almost infinite) number of Web services.
<Quote4>
Then if you find a web service, how do you consume it after buying it:
</Quote4>
Ah, payment is another aspect that I intentionally left out. Hold that
thought - I don't think we'll get there until the world realizes the
value of paying to use a Web service. I see that as just beyond where
we're heading in this thread.
<Quote5>
the service might be the same functionnaly but have different SOAP API.
Hiow could I reconfigure it dynamically.
</Quote5>
You probably would not "reconfigure dynamically" (combining those 2
words sounds dangerous to me). Let's assume that Web services in this
scenario are all using SOAP in a way that makes them compatible.
<Quote6>
Tim Berner-Lee's OWL (http://www.w3.org/TR/owl-ref/) try to answer to
some of theses problem I think.
</Quote6>
Yes - I'm actually thinking beyond OWL here. Let's assume that OWL is in
place and working quite well, and take it from there.
<Quote7>
Eventually, arrive the problem of the cheaters like the porn web site
you find on google when looking for a CS science paper (actually it did
happen to me but this is slightly outsubject :=))
</Quote7>
I think I'll leave that one alone. ;)
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
[1] http://xml.coverpages.org/ni2003-05-23-a.html
Nicolas Toper wrote:
>
> I'm at work so I don't have my bookmarks around but here are some stuff
that
> might help:
>
>
http://csdl.computer.org/comp/proceedings/euromicro-pdp/2002/1444/00/1444010
> 9abs.htm
>
> http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-jiniology.html
>
>
http://wwws.sun.com/software/jini/whitepapers/rio_architecture_overview.pdf
>
> Basically, the first problem is about QoS: if a web service fail what do
you
> do. Where do I go if a web service fails? To a new one? Which one? Where
do
> I find them (which UDDI directory should I check and what if it is not
> avalaible :=))
>
> The second problem is about choosing a web service: how do I choose
between
> 2 web services ? This is as I said the same problem Google, Yahoo, and so
> on, are confronted with...
>
> Then if you find a web service, how do you consume it after buying it: the
> service might be the same functionnaly but have different SOAP API. Hiow
> could I reconfigure it dynamically.
>
> Tim Berner-Lee's OWL (http://www.w3.org/TR/owl-ref/) try to answer to some
> of theses problem I think.
>
> Eventually, arrive the problem of the cheaters like the porn web site you
> find on google when looking for a CS science paper (actually it did happen
> to me but this is slightly outsubject :=))
>
> so where do we start :=)?
>
> -----Message d'origine-----
> De : Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Envoye : mercredi 17 septembre 2003 17:46
> A : Nicolas Toper
> Cc : xml-dev@lists.xml.org
> Objet : Re: [xml-dev] Web Services and Quality
>
> <Quote1>
> OK you could invoke dynamically web services, but how would you find
> about it? a UDDI directory?
> </Quote1>
>
> Yes - or we could say any registry that stores/maintains Web services
> descriptions. As a member of the OASIS/ebXML Registry TC, I should say
> "such as UDDI or ebXML Registry".
>
> <Quote2>
> OK but does it tell you what is the web service in a way the computer
> could understant?
> </Quote2>
>
> Neither standard currently does this to the level required in my
> scenario below (OASIS/ebXML Registry is planning to include Semantic
> features in the registry architecture in a future version). But if a Web
> services description (such as a DAML-S description) contained the proper
> metadata, the descriptions themselves could be searched. Of course, it
> would be preferable if some of this metadata were inherent in the
> registry architecture, as it could enable more efficient searches.
>
> <Quote3>
> I've seen something with Jini (and of course for Jini). If
> you're interested, I can find back the link and send it on the list.
> </Quote3>
>
> Yes, that would be great. Thanks.
>
> Kind Regards,
> Joe Chiusano
> Booz | Allen | Hamilton
>
> Nicolas Toper wrote:
> >
> > My first question is OK you could invoke dynamically web services, but
how
> > would you find about it? a UDDI directory? OK but does it tell you what
is
> > the web service in a way the computer could understant?
> >
> > About quality, I've seen something with Jini (and of course for Jini).
If
> > you're interested, I can find back the link and send it on the list
> >
> > nicolas
> >
> > -----Message d'origine-----
> > De : Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Envoye : mercredi 17 septembre 2003 17:04
> > A : xml-dev@lists.xml.org
> > Objet : [xml-dev] Web Services and Quality
> >
> > Lately I've been thinking about what's around the corner for Web
> > services (whether we're close to that corner yet or not is a separate
> > issue). The notion of dynamic discovery and collaboration of Web
> > services comes to mind (choreography, business processes, etc.) - but
> > I'm also thinking in terms of how a Web service can judge the "quality"
> > of another Web service. My question is: is anyone aware of any current
> > efforts on rating Web services?
> >
> > To put this question in context, please consider the following scenario:
> >
> > - A travel agency needs to access hotel reservation Web services when
> > making reservations. Rather than have a fixed list of Web services that
> > it always accesses, the travel agency would like to instead dynamically
> > discover Web services at each transaction. This allows the travel agency
> > to avoid having a pre-negotiated agreement with each Web service.
> >
> > - This dynamic approach allows the travel agency to be able to
> > dynamically include newly available Web services (i.e. those not
> > available on a previous transaction), and exclude existing Web services
> > that may no longer be available.
> >
> > - It is assumed that dynamic discovery is through means described by the
> > various Semantic Web-related initiatives taking place (i.e. a Web
> > service can discover another Web service that - for instance - accepts a
> > given credit card, offers fligts by a given airline, etc.).
> >
> > - Since there is no pre-negotiated agreement in this scenario, the
> > travel agent needs a way of determining whether a given Web service is
> > "legitimate" or not. This goes beyond the security/trust realm that can
> > be covered by security tokens, to encompass whether or not the business
> > behind the Web service is legitimate, and not a front for a phony
> > operation. This could be done through the use of a third-party Web
> > Service "certification" authority that is "trusted" by the travel agent.
> > Once the travel agent's Web service agent sees this certification on a
> > Web service, it moves farther with that Web service in its discovery
> > efforts.
> >
> > - Additionally, the Web services (those that the travel agent's Web
> > service attempts to discover) could have some sort of "quality rating"
> > that reflects various factors such as reliability (i.e. whether or not
> > the Web service offers a reliable messaging feature), up time, etc.
> > (others?).
> >
> > - Assuming that the travel agent's Web service has initiatlly "selected"
> > a Web service based on its legitimacy and quality rating: the travel
> > agent's Web service may have a list of criteria specific to its request
> > (hotel reservation) that are required of the discovered Web service, and
> > at various levels (weights). These may reflect the travel agency's
> > business policies. For instance, the travel agency may (for whatever
> > reason) require a 3-day (more lenient) cancellation policy (instead of
> > 1-day notice). Therefore, the requesting Web service may require that
> > any discovered Web service provide information on its cancellation
> > policy - and it subsequently "rates" that policy.
> >
> > - The requesting Web service calculates an overall "weighted score" for
> > each discovered Web service, and returns to the travel agency
> > information from the Web services with the top X scores (X is determined
> > by the travel agency's policies). The aggregated results are then
> > organized according to the travel agency's policies (e.g. sorted by
> > price in ascending order).
> >
> > Kind Regards,
> > Joe Chiusano
> > Booz | Allen | Hamilton
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
