[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opacity calumny
Thanks, Joe. Obviously more than I ever wanted to know on the subject.
But I wish you good bokeh :-)
Ken
At 10:59 AM 7/13/2005, Chiusano Joseph wrote:
> > 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
> > /
> > >
> > >
> > ----------------------------------------------------------------------
> > > ------------
> > >
> > >
> > >
> >
> >
--
---------------------------------------------------------------------------------
/ 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]