OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Opacity calumny


bokeh?

I agree the focus of the RM is the roles and the conceptual building blocks 
to support the roles.  We should make sure we do nothing to preclude an 
entity, as appropriate, serving multiple roles but hopefully who fills the 
role is irrelevant.

Ken

At 10:37 AM 7/13/2005, Matthew MacKenzie wrote:
>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]