Re: [soa-rm] Opaqueness and Transactions

[John Harby <jharby@gmail.com>]

I agree, I think there are many such asynchronous examples.

On 5/4/05, Ken Laskey <klaskey@mitre.org> wrote:
> 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
> ***
> 
>