[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opaqueness and Transactions
I could have a service that sends the local weather to anyone on
the
soa-rm mailing list. I don't know how it determines what
local means
to everyone on the list. Other than invoking this
service, I give it
no input (its description tells me it will send to
the soa-rm list and
I believe it) and it sends nothing back to me as
the requester.
However, magically everyone gets their local
weather. Is this a good
design? That question is out of
scope as long as this can been a
service in an
SOA.
Ken
On May 4, 2005, at 7: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
>>
>>
>>
>>
------------------------------------------------------------------------
------------------
Ken
Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean VA
22102-7508
*** note change of phone extension from 883 to 983 effective
4/15/2005
***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]