[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opacity calumny
> Or more precisely, a tight-coupling to the interface but > loose-coupling to the actual "under the hood" guts of the > particular system... Some may consider this combination of tight and loose coupling to mean loose coupling in general terms - i.e. where one needs to characterize coupling in an overall sense. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Peter F Brown [mailto:peter@justbrown.net] > Sent: Wednesday, July 13, 2005 10:11 AM > To: 'Bashioum,Christopher D' > Cc: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Opacity calumny > > Christopher: > > I'm not sure I follow your use of "loose coupling" here: > allowing a service customer very specific access to a part of > a service through an exposed interface would seem to require > a pretty tight coupling, no? > Or more precisely, a tight-coupling to the interface but > loose-coupling to the actual "under the hood" guts of the > particular system...or is that what you meant? > > Regards, > > -Peter > > -----Original Message----- > From: Bashioum,Christopher D [mailto:CBASHIOUM@mitre.org] > Sent: 13 July 2005 03:38 > To: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Opacity calumny > > Ken, et. Al., > > I was reading your email thread and started thinking about > opacity as it relates to the concept of loose coupling. It > seems to me that the real issue is loose coupling as opposed > to opacity per se. One could publish all the specs related > to a service, including the actual code, as part of the > service description. As long as access to the internals of > the service is strictly via the interface, then you still > have loose coupling (and, a service). If, on the other hand, > you don't tell anyone about the internals of a service, but > you still allow access to the internals via globals or > back-door methods, you will not have loose coupling. > > I think opacity is really a surrogate for loose coupling. In > other words, its not about what you know of the service via > its metadata, its what you can access of the internals of the > service (thus the private/public that Frank mentions). Ken - > I think this is also what you were trying to say also (thus, > the ever more violent agreements below). So, that being > said, we should probably address this more > succinctly in the document. > > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Monday, July 11, 2005 5:24 PM > 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]