OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] Opaqueness and Transactions


Title: Re: [soa-rm] Opaqueness and Transactions
Frank,
 
I concur - we probably should have changed the subject on the thread at one point (as you point out). The thread below had wandered into a territory of inputs and outputs, which is where my question came (it was on whether a service can be a service if it has no inputs or outputs). We did, however, venture into what I believe is valueable territory a bit later in the thread regarding whether a service must have at least one input, even if it has no output.
 
BTW, a service is public if the descriptions of the service are necessary and sufficient for effective interactions with 
the service, *and* if the service is publicly reachable, of course.

 

Joe

 

Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com



From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Wed 5/4/2005 1:14 PM
To: Chiusano Joseph
Cc: Ken Laskey; Duane Nickull; McGregor.Wesley@tbs-sct.gc.ca; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Opaqueness and Transactions

I believe that this thread is off the mark wrt opaqueness.

My understanding of opaqueness, as is understood in the industry, is 
that opaqueness refers to the extent that you need to know how 
something is implemented before you can successfully interact with it.


This is not really related to the formats and extent of data needed 
to use the service.

1. I agree that passing in a Java object is highly suggestive that 
the service is implemented in Java (not proof positive of course).
2. Even if you only pass in text values, certain *kinds* of values 
(such as thread identifiers) are also highly suggestive of 
implementation techniques.

In any case, a *better* distinction might well be the degree of 
documentation offered about a service, together with a commitment to 
that description: a service is public if the descriptions of the 
service are necessary and sufficient for effective interactions with 
the service.

Frank

On May 4, 2005, at 4: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
>>
>>
>>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]