Re: atomic services with no effects or outputs

Exactly, we dont require to always specify PEs for all types of services. 
Although we are required to specify PEs for complex services whereas for 
simple services we can do with just IO concepts matching !!

>Well, for simple sequential service compositions this may be the case, 
>however when we think about complex services(which most of the real life 
>services would be) being composed and executed concurrently, there may be 
>interdependencies and therefore specification of preconditions and effects 
>become necessary.

by *neccessary*, do you mean mandatory ?


>
>Regards,
>
>Monika
>
>Chintan Patel wrote:
>
>>
>>What i believe is that the Services for which the composition task can be 
>>handled by "Genie" by just matching the Input/Output(IO) Concepts without 
>>considering the PreConditions and Effects(PE) then i believe there is no 
>>harm in not specifying the PE for those atomic Services.
>>
>>comments ?
>>
>>Regards,
>>Chintan
>>
>>================
>>Graduate Research Assistant
>>School of Interdisciplinary Computing and Engineering
>>University of Missouri - Kansas City
>>Kansas City - MO -64110
>>
>>Ph : 816-931-9981 (R)
>>     816-235-2396 (O)
>>
>>
>>
>>
>>
>>>From: Monika Solanki <monika@dmu.ac.uk>
>>>To: Mithun Sheshagiri <mits1@cs.umbc.edu>, www-ws@w3.org
>>>Subject: Re: atomic services with no effects or outputs
>>>Date: Fri, 21 Mar 2003 22:03:49 +0000
>>>
>>>Just an info: there is a note in the comment tag of the file that states:
>>>
>>>NOTE: This is a sketch; not a complete example
>>>
>>>The example therefore can be made more sell sufficient.
>>>
>>>For effective service composition, I agree with you, that ideally the 
>>>IOPEs of every collaborating service would have to be exposed. I am not 
>>>sure at this moment, if and how these should be made mandatory, in some 
>>>way in the service description. Probably a parser encapsulating certain 
>>>rules could be used. However there is little that can be achieved without 
>>>the IOPEs.
>>>
>>>Regards,
>>>
>>>Monika
>>>
>>>Mithun Sheshagiri wrote:
>>>
>>>>
>>>>Hi all,
>>>>        There are several atomic services described in the CongoProcess 
>>>>file that neither have outputs nor effects. I was wondering how can 
>>>>these services be of use to us (entities other than the author). In my 
>>>>understanding services either provide you with some information (e.g.. 
>>>>ISBN lookup service with the ISBN number as the output) or do some world 
>>>>altering activity (e.g. the ExpressCongoBuy service whose execution 
>>>>results in the book being shipped to its destination). The former has an 
>>>>output and the latter has some effect. Here the output or effect implies 
>>>>some sort of a change.
>>>>If a service does not indicate a change of state (i.e., if it does not 
>>>>have i/e) then how can someone who discovers the service use it (say for 
>>>>composition). Something does change when the service is executed but the 
>>>>service does not reveal it. I would like to draw an analogy between such 
>>>>services with methods that have return type "void". Take the example of 
>>>>a program that implements a counter. The increment method in this 
>>>>program returns void after incrementing the counter. I further name the 
>>>>method foo. If I advertise this method as a web service how will one use 
>>>>it since he/she has no idea about its internal workings. But if I return 
>>>>a message (add an effect/output) that says "Counter_Incremented" then 
>>>>won't it be much easier to comprehend what the service does (assuming 
>>>>there is a Genie that maps Counter_Incremented to an my concept of 
>>>>counter increment)..
>>>>What I make out of this is that as long as I don't provide an output or 
>>>>effect, only I, as the writer of the program can use it. By describing 
>>>>the effect, I describe the service to the extent that someone else might 
>>>>be able to use it.
>>>>Do I make any sense or have I completely lost it.
>>>>
>>>>mithun
>>>>
>>>>
>>>
>>>--
>>> >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
>>>Monika Solanki
>>>De Montfort University
>>>Software Technology Research Laboratory
>>>Hawthorn building, H00.18
>>>The Gateway.
>>>Leicester LE1 9BH, UK
>>>
>>>phone: +44 (0)116 250 6170 intern: 6170
>>>email: monika@dmu.ac.uk <mailto:monika@dmu.ac.uk>
>>>web: http://www.cse.dmu.ac.uk/~monika/ 
>>><http://www.cse.dmu.ac.uk/%7Emonika/>
>>> >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
>>>"NOTE: The information transmitted is intended only for the person or 
>>>entity to which it is addressed and may contain confidential and/or 
>>>privileged material. Any review, retransmission, dissemination or other 
>>>use of, or taking of any action in reliance upon this information by 
>>>persons or entities other than the intended recipient is prohibited. If 
>>>you received this in error, please contact the sender and delete the 
>>>material from any computer"
>>>
>>>
>>
>>
>>_________________________________________________________________
>>Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
>>http://join.msn.com/?page=features/featuredemail
>>
>
>--
> >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
>Monika Solanki
>De Montfort University
>Software Technology Research Laboratory
>Hawthorn building, H00.18
>The Gateway.
>Leicester LE1 9BH, UK
>
>phone: +44 (0)116 250 6170 intern: 6170
>email: monika@dmu.ac.uk <mailto:monika@dmu.ac.uk>
>web: http://www.cse.dmu.ac.uk/~monika/ 
><http://www.cse.dmu.ac.uk/%7Emonika/>
> >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
>"NOTE: The information transmitted is intended only for the person or 
>entity to which it is addressed and may contain confidential and/or 
>privileged material. Any review, retransmission, dissemination or other use 
>of, or taking of any action in reliance upon this information by persons or 
>entities other than the intended recipient is prohibited. If you received 
>this in error, please contact the sender and delete the material from any 
>computer"
>
>


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

Received on Wednesday, 26 March 2003 14:27:56 UTC