W3C home > Mailing lists > Public > public-sws-ig@w3.org > October 2004

RE: ambiguous match and business transaction

From: Chiusano Joseph <chiusano_joseph@bah.com>
Date: Sat, 2 Oct 2004 20:12:15 -0400
Message-ID: <2BD3860A32296145AE43B60823240F270C8372@mclnexbh02.resource.ds.bah.com>
To: "doeuk.nosing" <doeuk.nosing@wanadoo.fr>, <public-sws-ig@w3.org>
[See comment on "Concerning business transaction" point below]

From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On Behalf Of doeuk.nosing
Sent: Monday, September 27, 2004 2:19 AM
To: public-sws-ig@w3.org
Subject: ambiguous match and business transaction

	Hi all,


	Here is a bunch of questions or purpose that I want to discuss


	- Concerning the service Profile .... I read that the service profile permits agents or other programs to check unambiguously the matching between a requested WS and a advertised WS, only with input and output (I don't really understand how the condition and effect works) ... But imagine you can found 2 services that have the input / output, but don't do the same thing ... like this example : You have 2 inputs, 2 Numbers and 1 output, also a number. The service A do input1  input2 while the service B do input1 - input2. How a matching algorithm can make a difference between this 2 services (because they have the same input/output) ?


	- Concerning business transaction .... Imagine that we have a very nasty Web service A which cheats on his profile. He advertises that he sells computers. It requires an input that is a credit card number in order to process to the paiement. But when the WS will be consumed, it will failed and cancelled the transaction. But it will have my credit card number .... Won't it ? How to prevent against fakes profile ? (because the choice of a WS is done by programs, it is easy to cheat)


	I see you did not receive a response on the above point yet: What this comes down to is electronic trust, and potentially SLAs (service-level agreements). For example, Web Service A is provided by a service provider (that we will call Service Provider A). The service consumer would need to have an SLA with Service Provider A that makes Service Provider A responsible for the authenticity and non-harmful nature of Web Service A. 


	What is missing in this is something that I foresee a need for in the future - and that is some type of insurance policy (call it "service insurance") by which a service provider can be held liable for damages by a service that they offer (whether the damages be theft of personal information as you describe above, or interruption to business operations if a service is down for longer than the agreed-upon permissible time, etc.). A service consumer would then be entitled to some monetary award by filing a claim with the service insurance provider. This is an incentive for a service provider to ensure the authenticity, non-harmfulness, and dependability of their services. I foresee the existence of this new type of insurance provider within the next 10 years. 


	An e-business registry - such as UDDI or ebXML Registry - might also be involved here. In this case, the service consumer would have an SLA with the registry provider, who vouches for the authenticity, non-harmfulness, and dependability of the services within its registry.


	Hope that helps.


	Kind Regards,

	Joe Chiusano

	Booz | Allen | Hamilton 
	Strategy and Technology Consultants to the World


	- Concerning composition of services .... Imagine we are looking for a WS. So we must check the IOPE of a bunch of WS and take the WS that match perfectly my requested WS. But imagine, there is no WS that completely match my requested WS, but they only partially match. Is it possible to compose them? For example: I am looking for a travel, so I want to buy a train ticket and rent a room in  a hotel for 1 week. There are only ticket seller and hotel WS, but there are no WS that can offer the 2. Is there a way to mix these 2 WS in order to buy my complete travel?


	Thx a lot for your help
Received on Sunday, 3 October 2004 00:12:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:13 UTC