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] Loose Coupling


The original definition was:

"A SOA Fabric is an abstract concept to represent the environment in which a service within a service-oriented system resides, is discovered, is invoked, and is evolved."

Using "service-oriented environment" instead of "service-oriented system" will yield the following (please note also the change of "evolved" to "managed"):

"A SOA Fabric is an abstract concept to represent the environment in which a service within a service-oriented environment resides, is discovered, is invoked, and is managed."

Which is an awkward double-use of "environment".

Suggested new version, which removes "within a service-oriented environment":

"A SOA Fabric is an abstract concept to represent the environment in which a service resides, is discovered, is invoked, and is managed."

Who likey?

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Friday, May 20, 2005 6:25 PM
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Loose Coupling
> 
> That is the term I have favored too.
> 
>  From the charter:
> 
> *Reference Model *- A reference model is an abstract 
> framework for understanding significant relationships among 
> the entities of some environment, and for the development of 
> consistent standards or specifications supporting that environment.
> 
> +1
> 
> D
> 
> Christopher Bashioum wrote:
> 
> > I like that better
> >
> >     
> --------------------------------------------------------------
> ----------
> >     *From:* Smith, Martin [mailto:Martin.Smith@DHS.GOV]
> >     *Sent:* Friday, May 20, 2005 6:16 PM
> >     *To:* Christopher Bashioum; soa-rm@lists.oasis-open.org
> >     *Subject:* RE: [soa-rm] Loose Coupling
> >
> >     “Environment”?
> >
> >      
> >
> >     Martin
> >
> >      
> >
> >      
> >
> >     -----Original Message-----
> >     *From:* Christopher Bashioum [mailto:cbashioum@mitre.org]
> >     *Sent:* Friday, May 20, 2005 1:44 PM
> >     *To:* soa-rm@lists.oasis-open.org
> >     *Subject:* RE: [soa-rm] Loose Coupling
> >
> >      
> >
> >     Joe,
> >
> >      
> >
> >     I am uncomfortable with the term "system" - as that strikes me
> >     as more concrete than architecture.  Did we really agree to use
> >     that term?  If so, I guess I just read past that earlier - maybe
> >     while focusing on some other point. 
> >
> >          
> >
> >         
> --------------------------------------------------------------
> ----------
> >
> >         *From:* Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> >         *Sent:* Friday, May 20, 2005 10:19 AM
> >         *To:* soa-rm@lists.oasis-open.org
> >         *Subject:* RE: [soa-rm] Loose Coupling
> >
> >         A service-oriented system is a system that is based on SOA
> >         principles. I used the term "SOA-based system" a while back,
> >         and Duane recommended using "service-oriented system".
> >         "Evolved" instead of "managed" is fine with me.
> >
> >          
> >
> >         Thanks,
> >
> >         Joe
> >
> >          
> >
> >         Joseph Chiusano
> >
> >         Booz Allen Hamilton
> >
> >         Visit us online@ http://www.boozallen.com
> >         <http://www.boozallen.com/>
> >
> >          
> >
> >              
> >
> >             
> --------------------------------------------------------------
> ----------
> >
> >             *From:* Christopher Bashioum 
> [mailto:cbashioum@mitre.org]
> >             *Sent:* Friday, May 20, 2005 9:55 AM
> >             *To:* soa-rm@lists.oasis-open.org
> >             *Subject:* RE: [soa-rm] Loose Coupling
> >
> >             Joe,
> >
> >              
> >
> >             what is a "service oriented system?".  Also, I would be
> >             more comfortable with the definition if you dropped the
> >             word 'evolved' and added the word 'managed'. 
> >
> >                  
> >
> >                 
> --------------------------------------------------------------
> ----------
> >
> >                 *From:* McGregor.Wesley@tbs-sct.gc.ca
> >                 [mailto:McGregor.Wesley@tbs-sct.gc.ca]
> >                 *Sent:* Friday, May 20, 2005 9:47 AM
> >                 *To:* chiusano_joseph@bah.com; 
> soa-rm@lists.oasis-open.org
> >                 *Subject:* RE: [soa-rm] Loose Coupling
> >
> >                 Joe,
> >
> >                  
> >
> >                 Your definition seems reasonable.
> >
> >                  
> >
> >                 Wes
> >
> >                 -----Original Message-----
> >                 *From:* Chiusano Joseph 
> [mailto:chiusano_joseph@bah.com]
> >                 *Sent:* May 19, 2005 10:37 PM
> >                 *To:* soa-rm@lists.oasis-open.org
> >                 *Subject:* RE: [soa-rm] Loose Coupling
> >
> >                  
> >
> >                 Can someone please provide what they believe to be a
> >                 definition of "SOA Fabric"? By this I don't mean "I
> >                 don't know what it is so I am seeking meaning", but
> >                 rather "I am not sure that we are all in semantic
> >                 alignment/agreement for this term".
> >
> >                  
> >
> >                 I will start with my definition: "A SOA Fabric is an
> >                 abstract concept to represent the 
> environment in which
> >                 a service within a service-oriented system 
> resides, is
> >                 discovered, is invoked, and is evolved."
> >
> >                  
> >
> >                 Please poke lots of holes in it.:)
> >
> >                  
> >
> >                 Joe
> >
> >                  
> >
> >                 P.S. I didn't even get into the notion of a "SOA
> >                 Fabric Softener":p
> >
> >                  
> >
> >                 Kind Regards,
> >
> >                 Joseph Chiusano
> >
> >                 Booz Allen Hamilton
> >
> >                 Visit us online@ http://www.boozallen.com
> >                 <http://www.boozallen.com/>
> >
> >                  
> >
> >                  
> >
> >                 
> --------------------------------------------------------------
> ----------
> >
> >                 *From:* Rex Brooks [mailto:rexb@starbourne.com]
> >                 *Sent:* Thursday, May 19, 2005 10:15 PM
> >                 *To:* Hamid Ben Malek; Michael Stiefel;
> >                 soa-rm@lists.oasis-open.org
> >                 *Subject:* RE: [soa-rm] Loose Coupling
> >
> >                 I don't actually intend to get into this, 
> but I wanted
> >                 to point out, Hamid, that you are assuming or
> >                 presuming that we all go along with concept 
> of an SOA
> >                 Fabric as the best, or even one of the 
> contenders for
> >                 the best working description and governance 
> model for
> >                 SOA. I don't happen to subscribe to that viewpoint,
> >                 nor do I subscribe to the Enterprise Service Bus
> >                 Model. However, there are important concepts and
> >                 modeling elements  within both of those schools of
> >                 thought on SOA with which I do agree and have every
> >                 intention of adopting for myself, whether or not the
> >                 TC decides to include those concepts in the 
> Reference
> >                 Model. As for loose-coupling, I consider it one of
> >                 those options best described in a primer or 
> as part of
> >                 a user guide or implementation guide, as a
> >                 best-practice recommendation just because it is more
> >                 flexible.
> >
> >                  
> >
> >                 That doesn't mean that I think all tightly coupled
> >                 SOAs will be inferior, just more limited 
> and difficult
> >                 to work with.
> >
> >                  
> >
> >                 Ciao,
> >
> >                 Rex
> >
> >                  
> >
> >                 I would encourage folks to have a look at
> >
> >                  
> >
> >                 At 6:17 PM -0700 5/19/05, Hamid Ben Malek wrote:
> >
> >                 Michael,
> >
> >                 You have a good analysis; however, you are missing
> >                 many points. I unfortunately cannot explain this
> >                 clearly by email because it needs few pages of
> >                 verbosity. I certainly hope I will have 
> time to write
> >                 a good article in which I explain these 
> things. I just
> >                 hope to make the deadline for spec review (next
> >                 Wednesday) and submit the article along with my
> >                 reviews included in the spreadsheet. Let me try here
> >                 to summarize the points you are missing in your
> >                 analysis below:
> >
> >                  
> >
> >                 I believe that in your analysis, the concept of
> >                 "loose-coupling" is not well understood in its right
> >                 context. When we talk about loose-coupling 
> in SOA, it
> >                 refers to a much strict concept that 
> touches directly
> >                 the boundaries of the services and the service
> >                 consumers. If the coupling remains inside the SOA
> >                 Fabric and does not directly touch a 
> service and/or a
> >                 service consumer, this kind of coupling is not a
> >                 "coupling" in the context of SOA. For example, when
> >                 you talk about "policy requirements" and 
> things alike,
> >                 these concepts are actually handled by the 
> SOA Fabric
> >                 and not directly by a service and/or a service
> >                 consumer in the sense that the implementation of it
> >                 may have to change or accommodate in a 
> certain way to
> >                 ensure interoperability. The third principle of SOA
> >                 (about "Contracts and Schemas") is really 
> ensuring the
> >                 strict concept of "loose-coupling" by pushing any
> >                 other types of couplings to the SOA Fabric which is
> >                 able to handle to job and take off the work 
> load from
> >                 service consumers by using data transformations.
> >
> >                  
> >
> >                 Regards,
> >
> >                  
> >
> >                 Hamid.
> >
> >                  
> >
> >                  
> >
> >                 -----Original Message-----
> >                 From: Michael Stiefel
> >                 [mailto:development@reliablesoftware.com]
> >                 Sent: Thursday, May 19, 2005 5:37 PM
> >                 To: soa-rm@lists.oasis-open.org
> >                 Subject: [soa-rm] Loose Coupling
> >
> >                  
> >
> >                 While I agree that in general loose coupling is good
> >                 in a SOA, the
> >
> >                 definition of a SOA should not include 
> loose coupling.
> >
> >                  
> >
> >                 Loose coupling is a design attribute, and 
> therefore a
> >                 concrete not an
> >
> >                 abstract attribute. It is also a question of degree.
> >                 How much loose
> >
> >                 coupling you have is a tradeoff among various design
> >                 factors.
> >
> >                  
> >
> >                 In theory you could have a tightly coupled SOA. How?
> >                 If the policy
> >
> >                 requirements of the service were so rigid, 
> and tightly
> >                 patterned after many
> >
> >                 implementation details, I would consider that a
> >                 tightly coupled SOA.
> >
> >                  
> >
> >                 However, our SOA RM should include the idea of
> >                 multiple services and the
> >
> >                 appropriate abstract attributes that go along with
> >                 that. I would think we
> >
> >                 could then use that as a reference point to 
> talk about
> >                 how tightly coupled
> >
> >                 a particular concrete architecture would be.
> >
> >                  
> >
> >                 Michael
> >
> >                  
> >
> >                  
> >
> >                 At 07:48 PM 5/19/2005, Don Flinn wrote:
> >
> >>Hamid
> >
> >> 
> >
> >>I agree with your differences between the older
> >                 distributed models,
> >
> >>where CORBA is an example, BUT I believe that some of
> >                 the members of the
> >
> >>TC would reject them for inclusion in the RM as being
> >                 too concrete.  For
> >
> >>example, loose-coupling has been rejected by some
> >                 members as being too
> >
> >>concrete a concept.  IMHO this is one of the
> >                 distinguishing features
> >
> >>that differentiate an SOA from the previous
> >                 distributed systems.
> >
> >> 
> >
> >>Don
> >
> >> 
> >
> >>On Thu, 2005-05-19 at 15:46 -0700, Hamid Ben Malek wrote:
> >
> >> > Frank,
> >
> >> >
> >
> >> > Using Matt's expression, Corba could be put in the
> >                 category of "OO +
> >
> >> > extra things". Corba is Object-Oriented, has
> >                 discovery services,
> >
> >> > interfaces, language neutral, a communication bus,
> >                 and so many other
> >
> >> > features. However, Corba is definitely NOT SOA.
> >                 Why? There are many
> >
> >> > reasons for this. It suffices to only cite one
> >                 reason which is related
> >
> >> > to the third SOA principle (⤦Contracts and
> >                 Schemasâ¤ù). Corba does not
> >
> >> > satify the third principle (actually it does not
> >                 satify other
> >
> >> > principles too). Corba is RPC-based, and the
> >                 message that goes inside
> >
> >> > the wire is a binary OO-RPC call. The limitations
> >                 of OO-RPC calls for
> >
> >> > applications that go beyond the enterprise scope
> >                 are well known
> >
> >> > (problems related to very tight-coupling,
> >                 versioning problems, etc⤆).
> >
> >> > The third principle in SOA roughly states that the
> >                 calls between SOA
> >
> >> > services and between a client and an SOA service
> >                 are all XML messages
> >
> >> > and that only the contrats and schemas are shared
> >                 between services and
> >
> >> > clients (no RPC interfaces such as those described
> >                 in Corba by IDL, or
> >
> >> > other OO artifats). The third principle ensures
> >                 loose-coupling through
> >
> >> > the use of contracts and schemas. This is not the
> >                 case in Corba.
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > Regards,
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > Hamid.
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > -----Original Message-----
> >
> >> > From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> >
> >> > Sent: Thursday, May 19, 2005 2:43 PM
> >
> >> > To: Don Flinn
> >
> >> > Cc: SOA-RM
> >
> >> > Subject: Re: [soa-rm] SOA System
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > Well,
> >
> >> >
> >
> >> >    I wasn't aware that CORBA name servers had
> >                 anything other than
> >
> >> >
> >
> >> > IDLs in them; but be that as it may ....
> >
> >> >
> >
> >> >    Is there a problem in recasting CORBA as an SOA?
> >                 Or casting SOA
> >
> >> > as
> >
> >> >
> >
> >> > distributed computing?
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >    There will be many factors that affect
> >                 scalability in the design
> >
> >> >
> >
> >> > of an architecture. The service-orientedness is
> >                 just one of those
> >
> >> >
> >
> >> > factors. To paraphrase an old maxim, there are few
> >                 ways to be
> >
> >> >
> >
> >> > scalable and many ways to be fragile:)
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >    I.e., SOA is one property of an architecture -
> >                 the focus on
> >
> >> > public
> >
> >> >
> >
> >> > interactions etc. etc. To model that we need
> >                 descriptions, semantics
> >
> >> >
> >
> >> > etc.
> >
> >> >
> >
> >> >    To build a high-class SOA, we will need to
> >                 consider other things;
> >
> >> >
> >
> >> > and we will need to apply the SOA RM to the
> >                 architecture.
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >    Clear as mud, I guess, as my 'ole pappy used to say.
> >
> >> >
> >
> >> > Frank
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > On May 19, 2005, at 2:30 PM, Don Flinn wrote:
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > > Hi Frank
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > > My point was not to discuss CORBA's problems or
> >                 lack of such.  (I
> >
> >> > was
> >
> >> >
> >
> >> > > one of the OMG/CORBA specification chairs during
> >                 CORBA'S hay-
> >
> >> > days :-)
> >
> >> >
> >
> >> > > But to ask at what level of abstraction does our
> >                 RM specify that
> >
> >> > which
> >
> >> >
> >
> >> > > makes it a reference model for an SOA.  I know
> >                 that an SOA is
> >
> >> >
> >
> >> > > different
> >
> >> >
> >
> >> > > from previous distributed models, but what
> >                 qualities in our abstract
> >
> >> >
> >
> >> > > model do we discuss that makes it different from
> >                 a specification of
> >
> >> > a
> >
> >> >
> >
> >> > > generic distributed model.
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > > You mentioned "the focus on the public
> >                 description of things".  Is
> >
> >> >
> >
> >> > > this
> >
> >> >
> >
> >> > > the only thing that makes an SOA different and
> >                 what our reference
> >
> >> >
> >
> >> > > model
> >
> >> >
> >
> >> > > should discuss?  Even there, again using poor old
> >                 CORBA, at an
> >
> >> >
> >
> >> > > abstract
> >
> >> >
> >
> >> > > level the CORBA naming service is a public
> >                 description of things.
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > > What I'm driving at and what we all are trying to
> >                 grapple with is
> >
> >> >
> >
> >> > > where
> >
> >> >
> >
> >> > > on the abstract spectrum should we be. At one
> >                 extreme, one enters
> >
> >> > the
> >
> >> >
> >
> >> > > world of metaphysics and the question become
> >                 "What is the meaning of
> >
> >> >
> >
> >> > > life :-)"  My question is simpler, maybe. Where
> >                 on the abstract
> >
> >> >
> >
> >> > > spectrum
> >
> >> >
> >
> >> > > should we be to model an SOA as opposed to any
> >                 distributed model?  I
> >
> >> >
> >
> >> > > don't believe that we can produce a usable
> >                 specification if the
> >
> >> >
> >
> >> > > model is
> >
> >> >
> >
> >> > > abstracted to such a high level that we are
> >                 delivering a reference
> >
> >> >
> >
> >> > > model
> >
> >> >
> >
> >> > > for any distributed computing model. 
> >                 Specifically, what are the
> >
> >> >
> >
> >> > > abstract qualities that distinguish an SOA from a
> >                 generic
> >
> >> > distributed
> >
> >> >
> >
> >> > > model?
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > > Don
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > > On Thu, 2005-05-19 at 10:57 -0700, Francis McCabe
> >                 wrote:
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > >> And the problem is ....
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >> I think that CORBA's problems did not come at
> >                 this level of
> >
> >> >
> >
> >> > >> abstraction, but in the low-level realization. 
> >                 E.g., IDL is C++ in
> >
> >> > a
> >
> >> >
> >
> >> > >> different syntax. It is rigid, and not capable
> >                 of incorporating
> >
> >> >
> >
> >> > >> descriptions of policies, etc.
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >> SOA *is* different from random distributed
> >                 computing, because of
> >
> >> > the
> >
> >> >
> >
> >> > >> focus on public descriptions of things.
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >> Frank
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >> On May 19, 2005, at 10:20 AM, Don Flinn wrote:
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >>> To All
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>> As we abstract and restrict our reference
> >                 model, I begin to wonder
> >
> >> >
> >
> >> > >>> what
> >
> >> >
> >
> >> > >>> makes this reference model a SOA reference
> >                 model as opposed to say
> >
> >> > a
> >
> >> >
> >
> >> > >>> CORBA reference model.  CORBA had interfaces as
> >                 one of its primary
> >
> >> >
> >
> >> > >>> constructs and had a specific language, IDL, to
> >                 define the
> >
> >> >
> >
> >> > >>> interfaces.
> >
> >> >
> >
> >> > >>> The interfaces were the external front-end to
> >                 Impls, which at our
> >
> >> >
> >
> >> > >>> level
> >
> >> >
> >
> >> > >>> of abstraction were the same as services and
> >                 CORBA had the notion
> >
> >> > of
> >
> >> >
> >
> >> > >>> metadata.  It also had a Discovery & Advertise
> >                 entity, the naming
> >
> >> >
> >
> >> > >>> service.  This comparison is not limited to
> >                 CORBA, but could
> >
> >> > include
> >
> >> >
> >
> >> > >>> DCE, DCOM, J2EE, etc. to a greater or lesser
> >                 extent.  So my
> >
> >> >
> >
> >> > >>> question is;
> >
> >> >
> >
> >> > >>> At the level of abstraction that we are going,
> >                 what makes our
> >
> >> >
> >
> >> > >>> reference
> >
> >> >
> >
> >> > >>> model a SOA reference model and not a generic
> >                 distributed
> >
> >> > computing
> >
> >> >
> >
> >> > >>> model?  If the answer is the latter, is this
> >                 what the world is
> >
> >> >
> >
> >> > >>> expecting
> >
> >> >
> >
> >> > >>> from us?
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>> Don
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>> On Thu, 2005-05-19 at 09:10 -0700, Francis
> >                 McCabe wrote:
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>>> Matt, et. al.
> >
> >> >
> >
> >> > >>>>   In case this thought has not been raised in
> >                 future
> >
> >> > emails ... :)
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>   I believe that I am correct in stating that,
> >                 in practice, the
> >
> >> >
> >
> >> > >>>> best
> >
> >> >
> >
> >> > >>>> aspects of languages like Java is not features
> >                 such as
> >
> >> > inheritance
> >
> >> >
> >
> >> > >>>> but the ease with which applications can be
> >                 slotted together.
> >
> >> >
> >
> >> > >>>> The key
> >
> >> >
> >
> >> > >>>> feature that enables this Lego®-style
> >                 assembly is the
> >
> >> >
> >
> >> > >>>> *interface*. It
> >
> >> >
> >
> >> > >>>> turns out that interfaces make the task of
> >                 programming large
> >
> >> >
> >
> >> > >>>> systems
> >
> >> >
> >
> >> > >>>> significantly easier.
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>   The logical development of the type-only
> >                 interface is the
> >
> >> >
> >
> >> > >>>> *semantic* interface. But in any case, modern
> >                 SOAs represent one
> >
> >> >
> >
> >> > >>>> aspect of the trend towards focusing on
> >                 interfaces as a way of
> >
> >> >
> >
> >> > >>>> controlling complexity and enabling rapid
> >
> >> > development/deployment
> >
> >> >
> >
> >> > >>>> etc.
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>   So, at one level of abstraction, it may be
> >                 useful to think of
> >
> >> >
> >
> >> > >>>> SOAs
> >
> >> >
> >
> >> > >>>> as a system of interfaces that allow
> >                 architectures to be crossed,
> >
> >> >
> >
> >> > >>>> ownership domains to be crossed, different
> >                 implementation
> >
> >> > languages
> >
> >> >
> >
> >> > >>>> to be used, different versions to coexists,
> >                 etc. etc.
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>   Our task is to try to pick out the keystones
> >                 that bear the SOA
> >
> >> >
> >
> >> > >>>> hallmark; which seem to me to be what we have:
> >                 services as
> >
> >> > *action
> >
> >> >
> >
> >> > >>>> boundaries*, semantic interfaces, tons of
> >                 descriptions.
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>> Frank
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>> On May 18, 2005, at 7:22 PM, Matthew MacKenzie
> >                 wrote:
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>> Michael,
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>> On 18-May-05, at 5:55 PM, Michael Stiefel wrote:
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>> Matt, re your comment that "SO is OO,
> >                 basically, with some
> >
> >> > value-
> >
> >> >
> >
> >> > >>>>>> add infrastructure such as discovery and
> >                 description."
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>> Now this raises an interesting point in our
> >                 definition of
> >
> >> > service
> >
> >> >
> >
> >> > >>>>>> abstraction. Normally people cite as one of
> >                 the differences
> >
> >> >
> >
> >> > >>>>>> between SO and OO the fact that the former
> >                 is more loosely
> >
> >> >
> >
> >> > >>>>>> coupled.
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>> Would you maintain that OO systems that can
> >                 work with wire
> >
> >> >
> >
> >> > >>>>>> formats
> >
> >> >
> >
> >> > >>>>>> of object systems (such as COM and CORBA)
> >                 that allowed runtime
> >
> >> >
> >
> >> > >>>>>> dynamic binding of heterogenous systems fall
> >                 into the SO
> >
> >> >
> >
> >> > >>>>>> category?
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>> I maintain that in certain situations that
> >                 they *could* fall
> >
> >> > into
> >
> >> >
> >
> >> > >>>>> the SO category.  I think that the "loosely
> >                 coupled" argument is
> >
> >> >
> >
> >> > >>>>> sort of weak, because I am not completely
> >                 certain that even
> >
> >> > things
> >
> >> >
> >
> >> > >>>>> like web services end up creating loosely
> >                 coupled systems!
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>> Or do you see looser coupling as a useful
> >                 feature that is much
> >
> >> >
> >
> >> > >>>>>> more easily achieved with newer
> >                 implementation technologies
> >
> >> > such
> >
> >> >
> >
> >> > >>>>>> as Web services, and therefore have nothing
> >                 to do with SO.
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>> I love loose coupling...but yeah, I do just
> >                 view it as "a good
> >
> >> >
> >
> >> > >>>>> thing", and not a necessary element of SOA.
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>> -matt
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>>
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>>>
> >
> >> >
> >
> >> > >>> --
> >
> >> >
> >
> >> > >>> Don Flinn
> >
> >> >
> >
> >> > >>> President, Flint Security LLC
> >
> >> >
> >
> >> > >>> Tel: 781-856-7230
> >
> >> >
> >
> >> > >>> Fax: 781-631-7693
> >
> >> >
> >
> >> > >>> e-mail: flinn@alum.mit.edu
> >
> >> >
> >
> >> > >>> http://flintsecurity.com
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>>
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > >>
> >
> >> >
> >
> >> > > --
> >
> >> >
> >
> >> > > Don Flinn
> >
> >> >
> >
> >> > > President, Flint Security LLC
> >
> >> >
> >
> >> > > Tel: 781-856-7230
> >
> >> >
> >
> >> > > Fax: 781-631-7693
> >
> >> >
> >
> >> > > e-mail: flinn@alum.mit.edu
> >
> >> >
> >
> >> > > http://flintsecurity.com
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> > >
> >
> >> >
> >
> >> >
> >
> >>--
> >
> >>Don Flinn
> >
> >>President, Flint Security LLC
> >
> >>Tel: 781-856-7230
> >
> >>Fax: 781-631-7693
> >
> >>e-mail: flinn@alum.mit.edu
> >
> >>http://flintsecurity.com
> >
> >                  
> >
> >                  
> >
> >                  
> >
> >-- 
> >
> >                 Rex Brooks
> >                 President, CEO
> >                 Starbourne Communications Design
> >                 GeoAddress: 1361-A Addison
> >                 Berkeley, CA 94702
> >                 Tel: 510-849-2309
> >
> 


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