[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opacity calumny
I believe that the degree of coupling is something outside the scope of an RM, as it is more of a concrete aspect. It does, however, belong in an RA and within concrete domain architectures. Joe (not Duane hijacking Joe's e-mail account;) Kind Regards, Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Bashioum,Christopher D [mailto:CBASHIOUM@mitre.org] > Sent: Wednesday, July 13, 2005 9:14 AM > To: Michael Stiefel; soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Opacity calumny > > Agreed - so is there something about the loose coupling and > the design of the interfaces that is peculiarly SOA (and thus > would fit in the RM), or is a tightly coupled interface still > ok? I tend to think that we need to capture something in the > RM that focuses on loose coupling - which is similar to the > OO concept of public vs. private (Frank's earlier assertions). > > -----Original Message----- > From: Michael Stiefel [mailto:development@reliablesoftware.com] > Sent: Wednesday, July 13, 2005 9:01 AM > To: Bashioum,Christopher D; soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Opacity calumny > > I agree. > > Access through interface does not, however, automatically get > you loose coupling. Poorly designed interfaces can produce > tight coupling. > > Michael > > At 09:37 PM 7/12/2005, Bashioum,Christopher D wrote: > > 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]