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