I hope this
http://www.orablogs.com/pavlik/archives/The-Session-Concept-in-Web-Services.pdf
is a constructive addition to the discussion.
Mark.
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
>
> 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:] 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 ***
>>
>>
>>
>>
>>
>>
>>
>>
>
--
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)
