RE: [soa-rm] Opacity calumny

[Michael Stiefel <development@reliablesoftware.com>]

How about this for a rule of thumb:

Anything that is an engineering tradeoff (opacity, loose coupling, etc) 
does not belong in a RM, but belongs in a RA.

Michael

At 09:47 AM 7/13/2005, Bashioum,Christopher D wrote:
>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
> > >/
> > >
> > >-------------------------------------------------------------
> > ----------
> > -
> > >----------
> >
> >
> >