RE: [soa-rm] Opaqueness and Transactions

I could have a service that sends the local weather to anyone on the
soa-rm mailing list. I don't know how it determines what local means
to everyone on the list. Other than invoking this service, I give it
no input (its description tells me it will send to the soa-rm list and
I believe it) and it sends nothing back to me as the requester.
However, magically everyone gets their local weather. Is this a good
design? That question is out of scope as long as this can been a
service in an SOA.

Ken

On May 4, 2005, at 7:52 AM, Chiusano Joseph wrote:

>> -----Original Message-----
>> From: Ken Laskey [mailto:klaskey@mitre.org]
>> Sent: Tuesday, May 03, 2005 11:41 PM
>> To: Duane Nickull
>> Cc: McGregor.Wesley@tbs-sct.gc.ca; soa-rm@lists.oasis-open.org
>> Subject: Re: [soa-rm] Opaqueness and Transactions
>>
>> I am trying to deal with this in the service section write-up
>> but unfortunately I haven't gotten back to it since New
>> Orleans. However, here are some thoughts.
>>
>> A service "does something" and that's why you invoke it. To
>> a certain extent you can say it is opaque if it requires no
>> inputs and gives no outputs
>
> Then is it truly a service? (you do somewhat express that point below,
> however) Without inputs, how would it know what to process? It is
> possible to have no outputs, however (although it is not a good design
> technique IMO). Consider a service that changes the state of something
> -
> for example, decrements an inventory by one - based on input from a
> user. When completed, the service may not provide an output to the user
> (an example of an output it could provide, of course, would be a
> message
> such as "Thank you - the inventory has now been decremented by 1 for
> this item"), yet the processing was still done. Again, not a good
> design
> technique IMO.
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>
> other than to say it did what it
>> "advertised" but then one can still draw conclusions on its
>> internal processing based on that. One can probably draw
>> better conclusions based on information exchanges through the
>> published service interfaces. In any case, the only thing
>> that is completely opaque is something that sits in a closed
>> box and appears to do absolutely nothing. :-)
>>
>> OTOH, a service may publish metadata that reduces its opacity
>> but does so to support a consumer's need to make sure it is
>> invoking the appropriate service. So some level of
>> transparency may be required and that may be in response to
>> external needs rather than requirements of the service
>> processing. There are also other possibilities but let's not
>> get into intentional obfuscation.
>>
>> I will try to do justice to this in the write-up but I expect
>> there to be many, many comments.
>>
>> Ken
>>
>> On Apr 29, 2005, at 5:52 PM, Duane Nickull wrote:
>>
>>> Wes:
>>>
>>> I have re-thought this a lot too. I now think that a better axiom
>>> would be to state that a service controls its' level of
>> opacity. This
>>> is also an aspect of the concept of the autonomous nature
>> of services.
>>>
>>> Services are expected to be implemented across a wide variety of
>>> boundaries and environments. Assuming vastly different
>> implementation
>>> models, a service must remain somewhat autonomous in nature and
>>> assumptions of consistent behavior due to central authorities or
>>> consistent implementation environments cannot be made carte blanche.
>>>
>>> Some of the logic behind the autonomous nature of services is that
>>> they must be able to reclaim resources needed to perform
>> their duties.
>>> A service may have several levels of contracts with
>> multiple service
>>> consumers. If a quality of service guarantee is offered to
>> one group
>>> of service consumers, while a second group is offered services on a
>>> "best efforts" basis, the service may decide to end leases on it by
>>> the group with the best efforts group in order to reclaim resources
>>> need to fulfill its contractual obligations with the guaranteed
>>> service group.
>>>
>>> Does any of this make sense or am I in need of a weekend?
>>>
>>> Duane
>>>
>>> McGregor.Wesley@tbs-sct.gc.ca wrote:
>>>
>>>> Hi All,
>>>>
>>>> I would like clarification on the following items if possible:
>>>>
>>>> Opaqueness
>>>>
>>>> I believe there are degrees of opaqueness. If a service interface
>>>> allows JAVA classes as a parameter to the actual call, one
>> definitely
>>>> knows that the service supports JAVA at some level, implying the
>>>> consumer has some knowledge about the internals of the
>> service (not
>>>> much but some). The service is not completely opaque.
>>>>
>>>> If the service only allowed XML as incoming data and object
>>>> constructs, then the parser of choice could be in any
>> language or any
>>>> other combination of service calls. I would then say the
>> service is
>>>> more opaque.
>>>>
>>>> Proposal: There are degrees of opaqueness within the SOA RM and we
>>>> need to define them.
>>>>
>>>> Transactions
>>>>
>>>> If a service is a combination service, example, service A
>> is composed
>>>> of service B and C, are we going to describe the method by which B
>>>> and C asynchronous responses are delivered to the appropriate
>>>> reception point within service A?
>>>> Proposal: We need to describe by what method or model we support
>>>> service composition at run-time.
>>>>
>>>>
>>>> All comments welcome especially by those who have not said much so
>>>> far!
>>>>
>>>> Enjoy your face to face,
>>>>
>>>> Wes
>>>>
>>>> -----Original Message-----
>>>> From:      Ken Laskey [mailto:klaskey@mitre.org] Sent:
>> April 20, 2005
>>>> 4:16 PM
>>>> To:        Duane Nickull; SOA-RM
>>>> Subject:   Re: [soa-rm] service composition scenarios
>>>>
>>>> Duane,
>>>>
>>>> I agree with your analysis. If there is a reason to know
>> details of
>>>> what the service is doing, e.g. a language translation is
>> needed as
>>>> part of what the composite service will do and the user
>> wants to make
>>>> sure a certain class of translation engines is used, then this
>>>> information should be part of the service description/metadata and
>>>> there may be rules/policy to evaluate for the user to make
>> sure the
>>>> composite server is appropriate. Constructing an orchestrated
>>>> composite service may be done through another service, but such a
>>>> service will be like any other to the RM. However, the
>> example does
>>>> indicate there may be a need for specific metadata and
>> rules/policy
>>>> capability and this may or may not go beyond the idea of a generic
>>>> service. (Or, we may say that an SOA requires certain
>> instances of a
>>>> generic service be present.)
>>>>
>>>> Ken
>>>>
>>>> At 03:54 PM 4/20/2005, Duane Nickull wrote:
>>>>
>>>>> TC:
>>>>>
>>>>> Although this may not be part of the core RM, this is probably an
>>>>> interesting discussion to have. The concept of service
>> composition
>>>>> has been raised a few times on the list. I wanted to state a few
>>>>> observations about this concept. Please see attached diagram for
>>>>> details.
>>>>>
>>>>> 1. Services are opaque by nature. That means that the service
>>>>> consumer cannot see anything beyond the interface (service
>>>>> interface) it uses.
>>>>> If one service is actually aggregating two other services, the
>>>>> service consumer cannot and should not know this. From a service
>>>>> consumers viewpoint, a service is merely an agent or
>> interface that
>>>>> offer some function(s). Whether those functions are
>> mapped to a set
>>>>> of classes in some native language or another service is not
>>>>> important or relevant (other than the service metadata
>> stating what
>>>>> invoking the service means or does)
>>>>>
>>>>> 2. The service function (for service A) is described in
>> the service
>>>>> description specific to that service. If completing the function
>>>>> depends on two or more serial or parallel paths of execution
>>>>> successfully completing behind the service interface
>> (like calling
>>>>> services B and C) within a certain time frame, that is
>> not relevant
>>>>> to state in the service description for service A. The service
>>>>> consumer is only concerned with the service's ultimate success or
>>>>> failure. Mapping the functionality to success and failure is the
>>>>> responsibility of the service provider.
>>>>>
>>>>> Do you agree with this? This supports the notion of opaqueness.
>>>>>
>>>>> 3. # 1 and # 2 above are mandatory to comply with a services
>>>>> autonomous nature as described in the W3C WSA and subsequent
>>>>> services architectures. A service alone must determine
>> whether the
>>>>> service succeeds or fails. If a service consumer can see any
>>>>> specifics behind the service, this violates several of the core
>>>>> principles of SOA. If visibility beyond the offered service is
>>>>> required, then the service does nor meet the demand of
>> the service
>>>>> consumer. Accordingly, the service provider and consumer should
>>>>> discuss and re engineer.
>>>>>
>>>>> When implementing, more complex patterns of service
>> invocation can
>>>>> be facilitated while keeping these three axioms. If a
>> transaction
>>>>> sequence is needed, a service interface can offer two services - a
>>>>> put() and a commit().
>>>>>
>>>>> Duane
>>>>>
>>>>> --
>>>>> ***********
>>>>> Senior Standards Strategist - Adobe Systems, Inc. -
>>>>> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -
>>>>> http://www.unece.org/cefact/ Adobe Enterprise Developer
>> Resources -
>>>>> http://www.adobe.com/enterprise/developer/main.html
>>>>> ***********
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> -
>>>> -----------
>>>>   /   Ken Laskey
>>
>>>>           \
>>>> |    MITRE Corporation, M/S H305    phone: 703-983-7934   |
>>>> |    7515 Colshire Drive                    fax:
>> 703-983-1379
>>>> |
>>>>   \   McLean VA 22102-7508
>>
>>>>   /
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> -
>>>> ------------
>>>>
>>>> *** note: phone number changed 4/15/2005 to 703-983-7934 ***
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> ***********
>>> Senior Standards Strategist - Adobe Systems, Inc. -
>>> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -
>>> http://www.unece.org/cefact/ Adobe Enterprise Developer
>> Resources -
>>> http://www.adobe.com/enterprise/developer/main.html
>>> ***********
>>>
>>>
>> --------------------------------------------------------------
>> ----------
>> ------------------
>> Ken Laskey
>> MITRE Corporation, M/S H305     phone: 703-983-7934
>> 7515 Colshire Drive                        fax:        703-983-1379
>> McLean VA 22102-7508
>>
>>
>>
>>
------------------------------------------------------------------------
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone: 703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508

*** note change of phone extension from 883 to 983 effective 4/15/2005
***

soa-rm message