[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opacity calumny
> Sometimes we need to value bokeh, as oposed to sharp focus. For those who are curious: http://www.kenrockwell.com/tech/bokeh.htm (Bokeh Explained) Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Matthew MacKenzie [mailto:mattm@adobe.com] > Sent: Wednesday, July 13, 2005 10:37 AM > To: Ken Laskey > Cc: Chiusano Joseph; soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Opacity calumny > > I personally view our various RM elements as "roles", so from > my perspective a piece of software may fill many roles. A > piece of software's ability to fill more than one role is > therefore not really interesting to us. > > Sometimes we need to value bokeh, as oposed to sharp focus. > > -matt > > Ken Laskey wrote: > > > It may act in both the client and the server capacities but > it doesn't > > have to. I know of an example where a DoD system had a > huge number of > > APIs (I seem to remember 1200) and they had a utility that > generated > > WSDLs for each one and said they've complied with making things > > visible and accessible because here were your Web services. > > > > Somehow that seems like complying with the letter of the > law without > > serving the spirit or furthering the intent. > > > > Ken > > > > At 09:49 AM 7/13/2005, Chiusano Joseph wrote: > > > >> > For example, if I take an existing client-server system and just > >> > advertise the interface to that server - does this give me SOA? > >> > >> IMHO, no. The reason is that with client-server, a client > is a client > >> and a server is a server. With SOA, a service may act in both > >> capacities (consumer and producer - or whatever terms you > would like to use). > >> > >> Joe > >> > >> 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:47 AM > >> > To: Chiusano Joseph; soa-rm@lists.oasis-open.org > >> > Subject: RE: [soa-rm] Opacity calumny > >> > > >> > I agree with your assertion of a continuum that goes > from uncoupled > >> > to tightly coupled. However, I am not so sure that the > concept of > >> > loose coupling does not belong in the RM (but not convinced it > >> > does, either). > >> > > >> > > >> > For example, if I take an existing client-server system and just > >> > advertise the interface to that server - does this give me SOA? > >> > What if the client and the server are very tightly > coupled - where > >> > the client sometimes sends messages to the server and sometimes > >> > just directly accesses the data store that the server is using? > >> > What if the client and the server both share the data store, and > >> > only send messages to each other when the data store is updated? > >> > > >> > I am still struggling with this, as I am not sure how to > "measure" > >> > the degree of coupling, and even if I did know how to > measure it, I > >> > am not sure what the threshold would be for SOA. But, > just because > >> > it is hard, I would hate to not address it. I think > that the idea > >> > of loose coupling (however subjective that is) is > inherent to SOA. > >> > If you don't have it, you don't have SOA. > >> > > >> > Thoughts? > >> > > >> > -----Original Message----- > >> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > >> > Sent: Wednesday, July 13, 2005 9:32 AM > >> > To: soa-rm@lists.oasis-open.org > >> > 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 > >> > > >/ > >> > > > > >> > > >------------------------------------------------------------- > >> > > ---------- > >> > > - > >> > > >---------- > >> > > > >> > > > >> > > > >> > > > > > > > -- > > > > > ---------------------------------------------------------------------- > > ----------- > > > > / 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]