RE: [soa-rm] Opacity calumny

[Ken Laskey <klaskey@mitre.org>]

Peter,

You questions bring to mind another favorite topic of mine: logging.

Here are my examples:

- I make a request for data, maybe specifying the source or maybe just 
letting service magic find it for me.  I do the same thing next Tuesday and 
get a different answer.  Did
-- the value change at the source or
-- did something intrinsic change with the source or
-- was a different source used or
-- was a different back end service used as part of some unseen 
orchestration or ...

- I have a fairly ill-defined problem and I make a request that requires 
significant computation (and delay) to assemble the services and backend 
resources to satisfy my request.  I get a response but with opacity I do 
not know how it was generated.
-- Do I trust the response?
-- If I make the same request next Thursday, I could avoid the response 
assembling process (and delay) if I could just supply/point to the steps 
the service magic assembled today.  How do I do this and still maintain 
some level of opacity?

- I want to consider using new services to improve my current service-based 
processes, but many of the specifics are hidden consistent with 
opacity.  If I've managed to handle the repeatability issues, how do I 
become aware of potential upgrades?

I've advocated the need for a system logging function with a pointer to the 
log returned as a standard part of a response.  (Yes, I've only thought of 
this in the context of request/response and it probably needs to be taken 
further.)  I could "read" the log to eliminate much of the transparency.  I 
could "execute" the log to get repeatability.  I can have the service magic 
review some subset of my logs to recommend alternatives/optimizations.

I think the specifics of the last paragraph are beyond the RM but I think 
the concept of logging may have a place.  Can't remember now if I've 
introduced it anywhere.

Ken

At 12:40 PM 7/12/2005, Peter F Brown wrote:
>Too tame? Hmmm...
>
>To spice things up a bit, and maybe a topic for discussion in Vancouver
>therefore:
>
>How does the question of service opacity relate to on-the-fly service
>component redirection *by the consumer* across different interfaces?
>
>To explain, an example:
>Most eServices today take as axiomatic that the entirety of the service
>delivery cycle - for the consumer - takes place in one "envionment" (eg Web,
>WAP) whatever happens behind the scenes.
>
>In Innsbruck, at the Semantic Web Services workshop we looked at future
>scenarios where service execution (like the classic travel service)
>requiring x roundtrips between consumer and provider, that may be RESTful
>and available across environments:
>a) I start a query on my web browser, my internet connection dies (your
>pay-as-you-go WiFi credit runs out; your partner unplugs the modem because
>s/he has been waiting too long to talk to you; etc) and I need to pick the
>service up on an alternative channel (switch from WiFi to dialup mobile
>service, etc.);
>b) I interrupt the query and want to come back at a later time from where I
>left off, without having to start all over again; or
>c) I need to use a digital signature associated with my mobile phone to
>validate a payment request; etc
>
>In these scenarios (scenarii?), the "hand off" from one environment to
>another requires some transparency: in order to be able to pass the full URI
>and service parameters "front of house" (with the consumer in the driving
>seat) means that defined stages of the service should be transparent to the
>user (the classic REST scenario).
>
>What I'm getting at is *when* there is to be service transparency, it should
>be capable of providing predictable handles that are portable and, even if
>"session-specific" (in the sense, this service "instance" is "for you and
>not the guy without the platinum client status") are not machine/environment
>specific.
>
>IMO this level of service abstraction is definitely RM rather than RA
>material...
>
>To deliberately court controversy: if there is service transparency, must it
>be RESTful?
>
>All the best,
>
>-Peter
>
>-----Original Message-----
>From: Ken Laskey [mailto:klaskey@mitre.org]
>Sent: 11 July 2005 23:24
>To: Michael Stiefel; Frank McCabe
>Cc: soa-rm@lists.oasis-open.org
>Subject: Re: [soa-rm] Opacity calumny
>
>Agree, agree, agree.  This list is getting much too tame.
>
>I would suggest that the concept of opacity is relevant to the RM, and the
>fact that there are tradeoffs and examples of tradeoffs is relevant to the
>RM.  I also think relating this to a/c/p is relevant to the RM.  Being an
>engineer, it is difficult to list all the problems and not propose
>solutions, but alas that is not part of the RM.  So what of this is
>appropriate for the RA?
>
>Ken
>
>At 05:09 PM 7/11/2005, Michael Stiefel wrote:
> >I agree as well.
> >
> >Opacity is a design tradeoff and hence a concrete, not abstract issue.
> >All other things being equal more opacity is better than less, but in
> >reality you are trading off opacity for other things such as how much
> >metadata you publish and how much dependency you generate as a result.
> >
> >Michael
> >
> >At 04:31 PM 7/11/2005, Ken Laskey wrote:
> >>Frank,
> >>
> >>To agree even more violently, this raises (and I allude to a little in
> >>the draft) the question of how to provide a means to publish metadata
> >>as it is found to be needed but in a way that supports a consistent
> >>use of the metadata in evaluating an entity against unambiguously
> >>stated a/c/p, which themselves can be augmented and will evolve to
> >>meet business needs of the users (where if I am a design engineer, my
> >>business need is to find the technically correct solution engine).
> >>
> >>This represents a much ignored need as well as a terrible run-on
> >>sentence. :-)
> >>
> >>Ken
> >>
> >>At 04:10 PM 7/11/2005, Frank McCabe wrote:
> >>>Ken:
> >>>
> >>>   I think we are in violent agreement. The essence of the Java
> >>>execution engine example is that it is precisely that the
> >>>implementation is important -- not whether or not its good style!!
> >>>
> >>>   Incidentally, if it is important to know who wrote the
> >>>implementation, then that too should be part of the public description.
> >>>
> >>>   Perhaps another aspect concerns the on-the-wire vs. resource model
> >>>of service semantics. In the resource pov, issues of implementation
> >>>(transparent or otherwise) figure prominently. In the on-the-wire
> >>>pov, you only look at the message traffic; and do not even consider
> >>>the implementation.
> >>>
> >>>  They are related of course: a message is valid if it is well formed
> >>>(in some communication language) and if the implied predicate is
> >>>satisfied (there really is money in your bank account).
> >>>
> >>>  But, a Service Oriented Semantics (SOS) would focus on the on-the-
> >>>wire interpretation and require that the service participants
> >>>faithfully reflect the messages in their systems. I.e., it is similar
> >>>to the model/proof theory distinction: provided that the service
> >>>implementation is a correct Interpretation of the communication, the
> >>>participants can focus on the Formulae being communicated.
> >>>
> >>>That all being said, there are definite limits to descriptions. I.e.,
> >>>there will always be unstated (unstateable?) assumptions that are
> >>>required to be shared for successful interactions.
> >>>
> >>>Frank
> >>>
> >>>On Jul 11, 2005, at 12:49 PM, Ken Laskey wrote:
> >>>
> >>>>Frank,
> >>>>
> >>>>Opacity/transparency is not a dimension on which to distinguish
> >>>>services;  it is more of a fallacy that we may need to explain our
> >>>>way around.  This ties in very much with what I've tried to say
> >>>>about metadata and how metadata characterizing an instance is often
> >>>>the basis upon which the instance is evaluated in the context of
> >>>>assumptions, constraints, and policies (a/c/p) of providers and
> >>>>consumers.  In some circumstances, the amount of information that
> >>>>needs to be published about an entity may maintain little in the way
> >>>>of its opacity, but that is more likely related to a/c/p than it is
> >>>>to WSDL.
> >>>>
> >>>>See more inline.
> >>>>
> >>>>At 03:23 PM 7/11/2005, Frank McCabe wrote:
> >>>>
> >>>>>I read the revised section on services. And an issue that made me
> >>>>>uneasy before has resurfaced -- about opacity.
> >>>>>
> >>>>>I think that the opacity/transparency dimension is not a good basis
> >>>>>for distinguishing services. I am aware of the intuition: that
> >>>>>somehow when you use a service you should not have to worry about
> >>>>>the implementation. But what does it mean to say: "the
> >>>>>implementation is hidden from the service consumer"? If the service
> >>>>>is to add lists of numbers then its implementation is hidden
> >>>>>provided numbers are added up correctly. (I.e., we should not care
> >>>>>about whether its in C++ or C#; multi-threaded or federated).
> >>>>
> >>>>So here the service adds numbers and while we can imagine what is
> >>>>happening, we care no more of the specific than we do when we punch
> >>>>numbers into a calculator.
> >>>>
> >>>>
> >>>>>But, some services are explicitly about implementation issues:
> >>>>>security services, workload distribution services, java remote
> >>>>>execution engine services etc. etc. I.e., it is of the essence that
> >>>>>to use a Java remote execution service, you have to send it a java
> >>>>>class to execute. In that sense, the implementation is critical.
> >>>>
> >>>>But you call a java remote execution engine when you have an
> >>>>appropriate java class to execute.  If it is a general service that
> >>>>is implemented as a java remote execution then the WS interface
> >>>>should more likely be a collector of information that (inside the
> >>>>service) is rewritten as the necessary java class.  You could
> >>>>require a java class as input but I'm not sure that would be
> >>>>considered "good style".
> >>>>
> >>>>
> >>>>>A clearer distinction is public/private. A service is characterized
> >>>>>by a public description of its functionality. The public
> >>>>>description should be sufficient to be able to successfully
> >>>>>interact with the service; and no additional information should be
>required.
> >>>>
> >>>>Not really because what you consider part of the private information
> >>>>I might consider very pertinent to deciding whether your service is
> >>>>suitable for my purposes, i.e. I need it to be public.  For an
> >>>>extreme example, I used to work for your company and I know one of
> >>>>your developers is clearly incompetent and I'd never use anything
> >>>>that idiot touched.
> >>>>
> >>>>The challenge is in defining "should be sufficient to be able to
> >>>>successfully interact with the service".  I think we need to discuss
> >>>>opacity in these terms because it is strongly connected with SOA and
> >>>>may be more useful as a vague concept than as an absolute measure.
> >>>>
> >>>>
> >>>>>Frank
> >>>>
> >>>>Ken
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>--
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>--
> >>>>-----------
> >>>>   /   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                                              /
> >>----------------------------------------------------------------------
> >>------------
> >>
> >>
> >
> >
>
>--
>
>----------------------------------------------------------------------------
>-----
>    /   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                                              /
     ----------------------------------------------------------------------------------