Mark:
The link kept stopping me from accessing it. Can anyone else see it?
Duane
Mark Little wrote:
> 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 ***
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
--
***********
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
***********
