[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opaqueness and Transactions
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
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]