Very strange; it works for me. Anyway, I've attached the document in
case this is a wider problem.
Mark.
Duane Nickull wrote:
> 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 ***
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
--
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)
