[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]