[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opacity calumny
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 / ---------------------------------------------------------------------------- ------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]