Loading ...
Sorry, an error occurred while loading the content.
 

RE: [service-orientated-architecture] [ZapFlash] The Seven Levels of Loose Coupling

Expand Messages
  • Anil John
    ... or not) ... contract. ... management... ... Service contract change... Hmm.. The emphasis here seems to be on the Service Contract as the center of the
    Message 1 of 6 , Dec 2, 2007
      >Loose Coupling the Implementation
      >Web Services certainly fits the bill as does REST
      >and other styles of Service implementation. Indeed,
      >it's not the choice of interoperable specification (whether XML based
      or not)
      >that enables this level of loose coupling, but rather the Service
      contract.
      ....
      >Loose Coupling the Service Contract
      >First, a proper Service contract that is interface-neutral
      >will alleviate much of the problem of Service contract change
      management...
      >Active management and Service intermediaries further simplify the
      Service contract change...

      Hmm.. The emphasis here seems to be on the Service Contract as the
      center of the universe.. But if I am understanding the RESTian approach
      correctly, service contracts are not emphasized all that much in that
      particular approach. While I definitely resonate standards based
      definition and access to services, based on my admittedly neophyte's
      understanding of REST, the combination of the usage of HTTP as an
      application protocol that supports REST principles combined with the
      tenet of "Hypermedia as the engine of application state" blows out of
      the water the ease with which you deal with the issues of both of the
      coupling concerns mentioned above.

      >use of late-binding approaches that leverage run-time registries and
      contract-based binding..

      I am sorry, but I have never bought into this particular fantasy in the
      SOAP world.. Until we have resolved the issues of seamless
      interoperability across web service stacks (primarily arising from the
      XML to Object databinding issues), run time binding to services by
      consumers which involve the generation and implementation of dynamic
      client side proxies is nothing more than a VisionQuest! The only
      run-time approach that will work in the current environment that DOES
      "leverage run-time registries and contract-based binding" is limited to
      dynamic binding to different SOAP endpoint's (which could come from a
      run-time lookup against a registry) if and only if a priori
      interoperability testing has been done between potential producer and
      consumer web service code.

      >The Service Description Framework (SDF) shared by ZapThink in our
      Licensed
      >ZapThink Architect (LZA) boot camps is one of those
      >technology-neutral Service contract templates.

      The way that I have heard Chris Bashioum from MITRE (and others) who
      developed the SDF [1] describe it has been more from the perspective of
      "What are the things that are needed to describe a service?" and they
      too have always had a heavy
      service-contract-ish/schema/ontology/taxonomy spin on it...

      [1]
      http://colab.cim3.net/file/work/SICoP/2006-08-15/ServiceDefinitionFramew
      orkSOAFWGv3.ppt

      I just want a Loose Coupling "Make it Easy" Level :-)

      Regards,

      - Anil



      :-
      :- Anil John
      :- http://www.aniltj.com/blog/
      :-
    • Nick Gall
      A few observations: 1. In deciding where to apply loose coupling and what aspects to apply it to, keep the following rule of thumb in mind: Since the goal of
      Message 2 of 6 , Dec 3, 2007
        A few observations:
        1. In deciding where to apply loose coupling and what aspects to apply it to, keep the following rule of thumb in mind: Since the goal of loose coupling is to enable independent change among interacting systems, only loosen couplings between aspects of interacting systems that are likely to change independently, ie at different rates from one another. Systems that are highly likely to always change together do not need to be loosely coupled.
        2. The list below is definitely a list of "aspects" (as Ron mentions) NOT "levels", because they are largely independent of one another, eg, you don't have to achieve implementation loose coupling to achieve semantic loose coupling and vice versa. I think it is misleading to think of the aspects below as levels; but it makes for a better headline.
        3. You can NEVER achieve "complete decoupling" of two interacting systems: to interact in any way, there must be SOME dependencies (coupling) between the two systems. If you don't believe me, read Herbert Simon's "Sciences of the Artificial", where he discusses "decomposable systems", and makes the same point.
        4. This list leaves out the most important aspect of loose coupling: ubiquity. If I and only one other partner adopt the world's most dynamically reconfigurable middleware architecture then he and I are tightly bound to one another. Imagine the two of us dreamed up our own custom variation of WS-*; let's call it WS-Silo. Then between the two of us, we could do all sorts of nifty changes on one side to the interface without disrupting the other side; but we can't interoperate with ANYONE else.
        Item (4) is an extreme example of the problem WS-* has run into. Because of the complexity of the specs, vendor deviations from the specs, variations allowed be the specs, etc., only small numbers of participants can successfully interoperate with WS-*. Almost every deployment of WS-* is effectively WS-Silo:inside the Silo all systems are loosely-coupled, but only to a small number of other systems.

        The advantage of HTTP/REST is that, although I lose some implementation loose coupling (since I'm now tied to HTTP) I gain the mature interoperability of HTTP, so I can  interact with anyone on the Internet. This is why you see so little WS-* outside the firewall and so much inside.

        Bottom Line: When in doubt, choose an interoperability architecture that is somewhat more tightly coupled, but vastly more ubiquitous, over a somewhat more loosely coupled interop architecture that is comparatively rare.

        -- Nick

        On Nov 30, 2007 5:34 AM, Gervas Douglas <gervas.douglas@...> wrote:

         ZapThink

        The Seven Levels of Loose Coupling

        Document ID: ZAPFLASH-20071128 | Document Type: ZapFlash
        By: Ronald Schmelzer
        Posted: Nov. 28, 2007

        When ZapThink talks about Service-Oriented Architecture (SOA), we generally try to avoid semantic arguments about what is and what isn't SOA, but rather try to focus on specific characteristics that identify Service-oriented systems and the benefits they provide organizations that adopt the architectural approach. In particular, we like to focus on three core tenets: loose coupling of Service consumers and providers, composability at a variety of levels of granularity, and event-driven, asynchronous styles of interaction that allow for a wide range of usage scenarios.

        While these characteristics might seem distinct, they are in fact related to each other. The ability to compose arbitrary Services in environments of long-running transactions requires a certain measure of loose coupling. However, architects seem to grapple with the term "loose coupling". Some erroneously think that systems are either loosely coupled or tightly coupled as if the determination of coupling is a binary evaluation. The reality is that the concept of coupling, like that of granularity, is a relative term. Something is more loosely coupled than something else if it allows for a greater degree of variability and freedom for that particular aspect. Simply put, coupling is a measure of dependency and commonality required by a Service consumer and provider to be able to achieve a result.

        In that light, loose coupling is a spectrum. A system can be tightly coupled in one aspect while being loosely coupled in another. Many architects say that they want complete decoupling of systems so that any variation in the system can be handled without having to reimplement any of the Service consumers or providers. As we've discussed in past ZapFlashes, complete decoupling is incredibly difficult and expensive, if not impossible. So, what architects should be aiming for is achieving the right level of loose coupling to facilitate business agility without imposing huge costs.

        As such, what ZapThink has seen is that there are really seven levels, or perhaps aspects, of loose coupling that architects should consider in their SOA initiatives. The more degrees and levels of loose coupling they add to their SOA efforts, the greater those systems can deal with change.

        Loose Coupling the Implementation
        One of the most fundamental promises of SOA is that Service consumers are blind to the implementation technology used by the Service providers, and vice-versa. Indeed, the whole idea of the Service abstraction is that technology implementations are hidden. This most basic of SOA characteristics is realized using standards-based, interoperable specifications or protocols that provide a contract-based interaction between Service consumers and providers. Web Services certainly fits the bill as does REST and other styles of Service implementation. Indeed, it's not the choice of interoperable specification (whether XML based or not) that enables this level of loose coupling, but rather the Service contract. A properly written Service contract will allow Service consumers to bind to a wide range of Service provider implementations without have to know at all whether the Service implementation is done in Java, .NET, PHP, C++, or Basic. All SOA implementations must be at least loosely coupled at the implementation level, but clearly this is not enough to guarantee the sort of complete loose coupling so desired by the business.

        Loose Coupling the Service Contract
        XML, Web Services, REST, and other specifications hide the implementation of the Service such that when the Service implementation changes, the Service consumer does not need to be the wiser about it. However, what happens when the Service contract itself changes? A simple change to acceptable inputs or functional behavior of the system can have profound impact on Service consumers. As such, architects that want to progress their SOA initiatives beyond simply Web Service integration need to address Service contract change management in such a way that contract changes don't cause Service consumer breakage.

        This might seem to be a difficult proposition, but there are plenty of best practices, architectural approaches, and technologies to facilitate this level of loose coupling. First, a proper Service contract that is interface-neutral will alleviate much of the problem of Service contract change management. The Service Description Framework (SDF) shared by ZapThink in our Licensed ZapThink Architect (LZA) boot camps is one of those technology-neutral Service contract templates. In those approaches, new Service contracts don't simply replace old ones. Old contracts are never deprecated unless a transition path is provided for Service consumers. This can be as simple as a transformation or as complex as a Service-oriented process that is triggered when Service consumers request old (and deprecated) versions of the Service contract. As such, contract change must be handled as a matter of policy. Who gets what version of a Service should be controlled via metadata, not programmatically or via configuration of tightly-coupled infrastructure.

        Active management and Service intermediaries further simplify the Service contract change management issue by providing exception management and handling of Service contract differences. And of course, SOA Governance plays a huge role here in helping to manage the sort of change and versioning issues that arise. But probably the best practice in this arena is the use of late-binding approaches that leverage run-time registries and contract-based binding to abstract the binding specifics of Service consumers and keep Service contract changes from propagating. The topic of late binding is itself a deep conversation that requires rethinking the way that Service consumers bind to Service providers, and one too long for this ZapFlash.

        Loose Coupling the Service Policy
        So, putting into play Service contracts that abstract implementations and late-binding, intermediary-enabled, registry-based systems that allow for Service contract change without breakage enables a great degree of variability in the system, but we're still far from done. Indeed, even if the Service contract stays stable, a small change to a Service policy can have tremendous repercussions, as discussed in our Butterfly Effect ZapFlash.

        Companies looking to address Service variability should handle changes to policy the same way they handle changes to Service contract: late-binding, Service intermediary-enabled, registry-based, and governed. A policy is a form of metadata, as are contracts, and in fact, the only difference between a Service policy and a contract is that a policy can apply to any number of Services. Because policies control many aspects of the non-functional parts of a Service, architects need to include in their architectural plans methods and practices for dealing with Service policy versioning and deprecation as well as policy versioning that leverages the technologies and practices established for Service contracts. Companies need to test policies just as they test Service implementations, and manage policies as rigorously as they manage Services. Doing so not only makes the system as a whole more reliable, but enables one more level of loose coupling.

        Loose Coupling the Process
        Of course, loosely coupling the Service consumer from a Service provider only provides agility if the Services aren't composed together. Once you have a business process that composes a bunch of Services together, we have another area of potential tight coupling. What happens when the process changes? Ideally, a Service consumer should not have to know at all when a process is reconfigured. Fortunately, achieving that level of loose coupling is fairly straightforward.

        The movement in the SOA and BPM markets has been towards separating the process definition layer from the underlying implementation. By defining processes in metadata and exposing those processes using Service contracts (the recursive vision of process compose of Service and exposed as Service) abstracts the implementation of the process from the Service consumer. In fact, in such a scenario, a business process is really a form of Service implementation. And just as Service contracts provide loose coupling of Service implementations, they provide loose coupling of Service-oriented processes.

        Loose Coupling the Data Schema
        If we've enabled all the loose coupling levels defined above, companies should be able to make arbitrary changes to their Service implementations, contracts, policies, and processes without breaking a thing (or a sweat). Yet, that's not sufficient to handle the changing needs of the business. What happens when the underlying data schema changes? If a Service consumer and provider need to have a common understanding about that in order to have a conversation, we have tight coupling as defined above. Therefore, organizations need to further their loose coupling goals by enabling dynamic and heterogeneous change to the data schema shared between Service consumers and providers.

        To some, this might seem to be a very complicated task. Computers aren't people, after all, and so they can't process any changes to the format or definition of data. Yet, not all hope is lost here. First, Services aren't really interoperable unless they can understand and process data in common. This means that while there might be semantic dependencies between them (which we will address shortly), there does not need to be structural data dependencies between them. Schemas are key to Service data interoperability. However, what happens when Schemas change? One key approach is to address information and schema management in the same way you approach Service metadata management. Data schema can be treated as a form of metadata and the use of exception management, transformations, Service intermediaries, and Data Services (described in more detail here) are all key to enabling loose coupling of data structure. Implementing a Data Services layer introduces loose coupling in a way that provides a separation of concerns, so that underlying data infrastructure changes are insulated from the business Services above.

        Furthermore, companies need to align the efforts of those maintaining the data schema with those maintaining the Service metadata. Why is it that the folks who maintain the schema are not part of the architectural team? Schema are no different than Service contracts. They represent a form of metadata that encodes business requirements. As such, we frequently admonish companies to bring their data and information architect teams into their enterprise architect fold. The simple act of this alignment and the establishment of metadata-enabled change management will allow for loose coupling of data schema and structure.

        Loose Coupling the Infrastructure
        Before we try to slay the last dragon of loose coupling, it's important to note that all these levels of loose coupling doesn't matter a whit if it all depends on a single vendor's implementation. Too many times we interact with architects who claim that their systems are loosely coupled, but if they move their implementation from one Enterprise Service Bus (ESB) or Service infrastructure to another then all hell will break loose. How can they truly say their implementations are loosely coupled with such a huge dependency in mind? Enterprise architects worth a grain of salt will demand that their Service implementations be infrastructure neutral. That means that at any time, the company can change their infrastructure without having to rebuild all the Service consumers and providers.

        Many vendors promise this sort of interchangeability, but few deliver. In fact, the industry as a whole seems to be moving towards single-vendor SOA platforms that will keep many SOA initiatives tightly coupled at this layer. This ZapFlash serves as warning to firms that want to achieve high degrees of loose coupling: keep your implementation infrastructure neutral and you will be successful. Otherwise, your SOA initiatives will only enable partial business agility.

        Loose Coupling at the Semantic Layer
        The final level of loose coupling is the most challenging of all. Even if a company is enabled to make all the changes it wants to Service implementation, contract, policy, process, infrastructure, and data structure, problems still arise whenever there is change to semantics. As we detailed in our Semantic Integration: Loosely Coupling the Meaning of Data ZapFlash, if we impose the data structures of Service providers on Service requesters, the result is every bit as tightly coupled as previous architectural approaches. In order to provide the promise of seamless data integration, we must transcend simply loosely coupling the application interface and in addition provide loose coupling at the semantic level.

        As we detailed those ZapFlashes, in order to achieve the sort of semantic data integration we are seeking, we must implement dynamic service definitions. In essence, the definition of the Service interface must change based on the context of the Service requester. As a result, a Service can change its contract between invocations. For example, the fact that a Service provider requires first names to be no longer than 40 characters should not require the requester to know that fact. The contracted Service interface is supposed to provide that isolation. Service interfaces must therefore become much smarter. Instead of having to know ahead of time what specific data requirements are needed by a Service, the Service requester should be able to dynamically discover a Service interface that can not only provide the needed functionality, but also understand the information payload.

        The ZapThink Take
        SOA as a whole is an exercise in loosening the coupling of heterogeneous systems that have to cooperate to meet the needs of the business. As such, as companies seek to mature their SOA initiatives, they should be seeking to iteratively loosen the coupling of their systems at the various levels described above. The most amazing part of this loose coupling exercise is that the greater the degree of variability that can be tolerated by the system, the greater agility that you've enabled for the business. Even more so, if companies can manage to address all seven layers of loose coupling while maintaining a flat cost of architecture, then we've reached the desired state of the IT-Business relationship: IT can implement every requirement and desired outcome expressed by the business without imposing any additional time or cost impedance.

        To be specific, in a system that is enabled with all seven layers of loose coupling, changes to Service implementations, business processes, Service contracts, Service policies, runtime infrastructure, data schema, and semantics won't break the system. Can you think of any requirement by business not addressed in those levels of loose coupling? This vision of agility is precisely the aim of SOA, and it clearly requires much broader understanding of SOA than simply loose coupling of the implementation, which is the only capability provided by Web Services.





        --
        Nick Gall
        Phone: +1.781.608.5871
        AOL IM: Nicholas Gall
        Yahoo IM: nick_gall_1117
        MSN IM: (same as email)
        Google Talk: (same as email)
        Email: nick.gall AT-SIGN gmail DOT com
        Weblog: http://ironick.typepad.com/ironick/
        Furl: http://www.furl.net/members/ngall
      • jeffrschneider
        A big +1 on ubiquity. Nick - here is the paper I mentioned to you. It s now 4 years old and could use an update...
        Message 3 of 6 , Dec 8, 2007
          A big +1 on ubiquity.

          Nick - here is the paper I mentioned to you. It's now 4 years old and
          could use an update...
          http://schneider.blogspot.com/couplingindex.htm

          As SOA consultants, we realize that there is no 'right' formula for
          coupling - we just needed guidance...

          Jeff


          --- In service-orientated-architecture@yahoogroups.com, "Nick Gall"
          <nick.gall@...> wrote:
          >
          > A few observations:
          >
          > 1. In deciding where to apply loose coupling and what aspects to
          apply
          > it to, keep the following rule of thumb in mind: Since the goal
          of loose
          > coupling is to enable independent change among interacting
          systems, only
          > loosen couplings between aspects of interacting systems that are
          likely to
          > change independently, ie at different rates from one another.
          Systems that
          > are highly likely to always change together do not need to be
          loosely
          > coupled.
          > 2. The list below is definitely a list of "aspects" (as Ron
          mentions)
          > NOT "levels", because they are largely independent of one
          another, eg, you
          > don't have to achieve implementation loose coupling to achieve
          semantic
          > loose coupling and vice versa. I think it is misleading to think
          of the
          > aspects below as levels; but it makes for a better headline.
          > 3. You can NEVER achieve "complete decoupling" of two interacting
          > systems: to interact in any way, there must be SOME dependencies
          (coupling)
          > between the two systems. If you don't believe me, read Herbert
          Simon's
          > "Sciences of the Artificial", where he discusses "decomposable
          systems", and
          > makes the same point.
          > 4. This list leaves out the most important aspect of loose
          coupling:
          > ubiquity. If I and only one other partner adopt the world's most
          dynamically
          > reconfigurable middleware architecture then he and I are tightly
          bound to
          > one another. Imagine the two of us dreamed up our own custom
          variation of
          > WS-*; let's call it WS-Silo. Then between the two of us, we
          could do all
          > sorts of nifty changes on one side to the interface without
          disrupting the
          > other side; but we can't interoperate with ANYONE else.
          >
          > Item (4) is an extreme example of the problem WS-* has run into.
          Because of
          > the complexity of the specs, vendor deviations from the specs,
          variations
          > allowed be the specs, etc., only small numbers of participants can
          > successfully interoperate with WS-*. Almost every deployment of WS-
          * is
          > effectively WS-Silo:inside the Silo all systems are loosely-
          coupled, but
          > only to a small number of other systems.
          >
          > The advantage of HTTP/REST is that, although I lose some
          implementation
          > loose coupling (since I'm now tied to HTTP) I gain the mature
          > interoperability of HTTP, so I can interact with anyone on the
          Internet.
          > This is why you see so little WS-* outside the firewall and so much
          inside.
          >
          > Bottom Line: When in doubt, choose an interoperability architecture
          that is
          > somewhat more tightly coupled, but vastly more ubiquitous, over a
          somewhat
          > more loosely coupled interop architecture that is comparatively
          rare.
          >
          > -- Nick
          >
          > On Nov 30, 2007 5:34 AM, Gervas Douglas <gervas.douglas@...> wrote:
          >
          > > [image: ZapThink]
          > > The Seven Levels of Loose Coupling Document ID: ZAPFLASH-
          20071128 |
          > > Document Type: ZapFlash
          > > *By: Ronald Schmelzer*
          > > Posted: Nov. 28, 2007
          > >
          > > When ZapThink talks about Service-Oriented Architecture (SOA), we
          > > generally try to avoid semantic arguments about what is and what
          isn't SOA,
          > > but rather try to focus on specific characteristics that identify
          > > Service-oriented systems and the benefits they provide
          organizations that
          > > adopt the architectural approach. In particular, we like to focus
          on three
          > > core tenets: loose coupling of Service consumers and providers,
          > > composability at a variety of levels of granularity, and event-
          driven,
          > > asynchronous styles of interaction that allow for a wide range of
          usage
          > > scenarios.
          > >
          > > While these characteristics might seem distinct, they are in fact
          related
          > > to each other. The ability to compose arbitrary Services in
          environments of
          > > long-running transactions requires a certain measure of loose
          coupling.
          > > However, architects seem to grapple with the term "loose
          coupling". Some
          > > erroneously think that systems are either loosely coupled or
          tightly coupled
          > > as if the determination of coupling is a binary evaluation. The
          reality is
          > > that the concept of coupling, like that of granularity, is a
          relative term.
          > > Something is more loosely coupled than something else if it
          allows for a
          > > greater degree of variability and freedom for that particular
          aspect. Simply
          > > put, coupling is a measure of dependency and commonality required
          by a
          > > Service consumer and provider to be able to achieve a result.
          > >
          > > In that light, loose coupling is a spectrum. A system can be
          tightly
          > > coupled in one aspect while being loosely coupled in another. Many
          > > architects say that they want complete decoupling of systems so
          that any
          > > variation in the system can be handled without having to
          reimplement any of
          > > the Service consumers or providers. As we've discussed in
          past<http://www.zapthink.com/report.html?id=ZAPFLASH-09292004>
          > > ZapFlashes <http://www.zapthink.com/report.html?id=ZAPFLASH-
          2006519>,
          > > complete decoupling is incredibly difficult and expensive, if not
          > > impossible. So, what architects should be aiming for is achieving
          the right
          > > level of loose coupling<http://www.zapthink.com/report.html?
          id=ZAPFLASH-05282004>to facilitate business agility without imposing
          huge costs.
          > >
          > > As such, what ZapThink has seen is that there are really seven
          levels, or
          > > perhaps aspects, of loose coupling that architects should
          consider in their
          > > SOA initiatives. The more degrees and levels of loose coupling
          they add to
          > > their SOA efforts, the greater those systems can deal with change.
          > >
          > > *Loose Coupling the Implementation*
          > > One of the most fundamental promises of SOA is that Service
          consumers are
          > > blind to the implementation technology used by the Service
          providers, and
          > > vice-versa. Indeed, the whole idea of the Service abstraction is
          that
          > > technology implementations are hidden. This most basic of SOA
          > > characteristics is realized using standards-based, interoperable
          > > specifications or protocols that provide a contract-based
          interaction
          > > between Service consumers and providers. Web Services certainly
          fits the
          > > bill as does REST and other styles of Service implementation.
          Indeed, it's
          > > not the choice of interoperable specification (whether XML based
          or not)
          > > that enables this level of loose coupling, but rather the Service
          contract.
          > > A properly written Service contract will allow Service consumers
          to bind to
          > > a wide range of Service provider implementations without have to
          know at all
          > > whether the Service implementation is done in Java, .NET, PHP,
          C++, or
          > > Basic. All SOA implementations must be at least loosely coupled
          at the
          > > implementation level, but clearly this is not enough to guarantee
          the sort
          > > of complete loose coupling so desired by the business.
          > >
          > > *Loose Coupling the Service Contract*
          > > XML, Web Services, REST, and other specifications hide the
          implementation
          > > of the Service such that when the Service implementation changes,
          the
          > > Service consumer does not need to be the wiser about it. However,
          what
          > > happens when the Service contract itself changes? A simple change
          to
          > > acceptable inputs or functional behavior of the system can have
          profound
          > > impact on Service consumers. As such, architects that want to
          progress their
          > > SOA initiatives beyond simply Web Service integration need to
          address
          > > Service contract change management in such a way that contract
          changes don't
          > > cause Service consumer breakage.
          > >
          > > This might seem to be a difficult proposition, but there are
          plenty of
          > > best practices, architectural approaches, and technologies to
          facilitate
          > > this level of loose coupling. First, a proper Service contract
          that is
          > > interface-neutral will alleviate much of the problem of Service
          contract
          > > change management. The Service Description Framework (SDF) shared
          by
          > > ZapThink in our Licensed ZapThink Architect (LZA) boot camps is
          one of those
          > > technology-neutral Service contract templates. In those
          approaches, new
          > > Service contracts don't simply replace old ones. Old contracts
          are never
          > > deprecated unless a transition path is provided for Service
          consumers. This
          > > can be as simple as a transformation or as complex as a Service-
          oriented
          > > process that is triggered when Service consumers request old (and
          > > deprecated) versions of the Service contract. As such, contract
          change must
          > > be handled as a matter of policy. Who gets what version of a
          Service should
          > > be controlled via metadata, not programmatically or via
          configuration of
          > > tightly-coupled infrastructure.
          > >
          > > Active management and Service intermediaries further simplify the
          Service
          > > contract change management issue by providing exception
          management and
          > > handling of Service contract differences. And of course, SOA
          Governance
          > > plays a huge role here in helping to manage the sort of change and
          > > versioning issues that arise. But probably the best practice in
          this arena
          > > is the use of late-binding approaches that leverage run-time
          registries and
          > > contract-based binding to abstract the binding specifics of
          Service
          > > consumers and keep Service contract changes from propagating. The
          topic of
          > > late binding is itself a deep conversation that requires
          rethinking the way
          > > that Service consumers bind to Service providers, and one too
          long for this
          > > ZapFlash.
          > >
          > > *Loose Coupling the Service Policy*
          > > So, putting into play Service contracts that abstract
          implementations and
          > > late-binding, intermediary-enabled, registry-based systems that
          allow for
          > > Service contract change without breakage enables a great degree of
          > > variability in the system, but we're still far from done. Indeed,
          even if
          > > the Service contract stays stable, a small change to a Service
          policy can
          > > have tremendous repercussions, as discussed in our Butterfly
          Effect
          > > ZapFlash <http://www.zapthink.com/report.html?id=ZAPFLASH-
          2006124>.
          > >
          > > Companies looking to address Service variability should handle
          changes to
          > > policy the same way they handle changes to Service contract: late-
          binding,
          > > Service intermediary-enabled, registry-based, and governed. A
          policy is a
          > > form of metadata, as are contracts, and in fact, the only
          difference between
          > > a Service policy and a contract is that a policy can apply to any
          number of
          > > Services. Because policies control many aspects of the non-
          functional parts
          > > of a Service, architects need to include in their architectural
          plans
          > > methods and practices for dealing with Service policy versioning
          and
          > > deprecation as well as policy versioning that leverages the
          technologies and
          > > practices established for Service contracts. Companies need to
          test policies
          > > just as they test Service implementations, and manage policies as
          rigorously
          > > as they manage Services. Doing so not only makes the system as a
          whole more
          > > reliable, but enables one more level of loose coupling.
          > >
          > > *Loose Coupling the Process*
          > > Of course, loosely coupling the Service consumer from a Service
          provider
          > > only provides agility if the Services aren't composed together.
          Once you
          > > have a business process that composes a bunch of Services
          together, we have
          > > another area of potential tight coupling. What happens when the
          process
          > > changes? Ideally, a Service consumer should not have to know at
          all when a
          > > process is reconfigured. Fortunately, achieving that level of
          loose coupling
          > > is fairly straightforward.
          > >
          > > The movement in the SOA and BPM markets has been towards
          separating the
          > > process definition layer from the underlying implementation. By
          defining
          > > processes in metadata and exposing those processes using Service
          contracts
          > > (the recursive vision of process compose of Service and exposed
          as Service)
          > > abstracts the implementation of the process from the Service
          consumer. In
          > > fact, in such a scenario, a business process is really a form of
          Service
          > > implementation. And just as Service contracts provide loose
          coupling of
          > > Service implementations, they provide loose coupling of Service-
          oriented
          > > processes.
          > >
          > > *Loose Coupling the Data Schema*
          > > If we've enabled all the loose coupling levels defined above,
          companies
          > > should be able to make arbitrary changes to their Service
          implementations,
          > > contracts, policies, and processes without breaking a thing (or a
          sweat).
          > > Yet, that's not sufficient to handle the changing needs of the
          business.
          > > What happens when the underlying data schema changes? If a
          Service consumer
          > > and provider need to have a common understanding about that in
          order to have
          > > a conversation, we have tight coupling as defined above.
          Therefore,
          > > organizations need to further their loose coupling goals by
          enabling dynamic
          > > and heterogeneous change to the data schema shared between
          Service consumers
          > > and providers.
          > >
          > > To some, this might seem to be a very complicated task. Computers
          aren't
          > > people, after all, and so they can't process any changes to the
          format or
          > > definition of data. Yet, not all hope is lost here. First,
          Services aren't
          > > really interoperable unless they can understand and process data
          in common.
          > > This means that while there might be semantic dependencies
          between them
          > > (which we will address shortly), there does not need to be
          structural data
          > > dependencies between them. Schemas are key to Service data
          interoperability.
          > > However, what happens when Schemas change? One key approach is to
          address
          > > information and schema management in the same way you approach
          Service
          > > metadata management. Data schema can be treated as a form of
          metadata and
          > > the use of exception management, transformations, Service
          intermediaries,
          > > and Data Services (described in more detail
          here<http://www.zapthink.com/report.html?id=ZAPFLASH-2006103>)
          > > are all key to enabling loose coupling of data structure.
          Implementing a
          > > Data Services layer introduces loose coupling in a way that
          provides a
          > > separation of concerns, so that underlying data infrastructure
          changes are
          > > insulated from the business Services above.
          > >
          > > Furthermore, companies need to align the efforts of those
          maintaining the
          > > data schema with those maintaining the Service metadata. Why is
          it that the
          > > folks who maintain the schema are not part of the architectural
          team? Schema
          > > are no different than Service contracts. They represent a form of
          metadata
          > > that encodes business requirements. As such, we frequently
          admonish
          > > companies to bring their data and information architect teams
          into their
          > > enterprise architect fold<http://www.zapthink.com/report.html?
          id=ZAPFLASH-10222003>.
          > > The simple act of this alignment and the establishment of
          metadata-enabled
          > > change management will allow for loose coupling of data schema and
          > > structure.
          > >
          > > *Loose Coupling the Infrastructure*
          > > Before we try to slay the last dragon of loose coupling, it's
          important to
          > > note that all these levels of loose coupling doesn't matter a
          whit if it all
          > > depends on a single vendor's implementation. Too many times we
          interact with
          > > architects who claim that their systems are loosely coupled, but
          if they
          > > move their implementation from one Enterprise Service Bus (ESB)
          or Service
          > > infrastructure to another then all hell will break loose. How can
          they truly
          > > say their implementations are loosely coupled with such a huge
          dependency in
          > > mind? Enterprise architects worth a grain of salt will demand
          that their
          > > Service implementations be infrastructure neutral. That means
          that at any
          > > time, the company can change their infrastructure without having
          to rebuild
          > > all the Service consumers and providers.
          > >
          > > Many vendors promise this sort of interchangeability, but few
          deliver. In
          > > fact, the industry as a whole seems to be moving towards single-
          vendor SOA
          > > platforms that will keep many SOA initiatives tightly coupled at
          this layer.
          > > This ZapFlash serves as warning to firms that want to achieve
          high degrees
          > > of loose coupling: keep your implementation infrastructure
          neutral and you
          > > will be successful. Otherwise, your SOA initiatives will only
          enable partial
          > > business agility.
          > >
          > > *Loose Coupling at the Semantic Layer*
          > > The final level of loose coupling is the most challenging of all.
          Even if
          > > a company is enabled to make all the changes it wants to Service
          > > implementation, contract, policy, process, infrastructure, and
          data
          > > structure, problems still arise whenever there is change to
          semantics. As we
          > > detailed in our Semantic Integration: Loosely Coupling the
          Meaning of Data
          > > ZapFlash <http://www.zapthink.com/report.html?id=ZapFlash-
          08082003>, if we
          > > impose the data structures of Service providers on Service
          requesters, the
          > > result is every bit as tightly coupled as previous architectural
          approaches.
          > > In order to provide the promise of seamless data integration, we
          must
          > > transcend simply loosely coupling the application interface and
          in addition
          > > provide loose coupling at the semantic
          level<http://www.zapthink.com/report.html?id=ZAPFLASH-2005217>.
          > >
          > >
          > > As we detailed those ZapFlashes, in order to achieve the sort of
          semantic
          > > data integration we are seeking, we must implement *dynamic*
          service
          > > definitions. In essence, the definition of the Service interface
          must change
          > > based on the context of the Service requester. As a result, a
          Service can
          > > change its contract between invocations. For example, the fact
          that a
          > > Service provider requires first names to be no longer than 40
          characters
          > > should not require the requester to know that fact. The
          contracted Service
          > > interface is supposed to provide that isolation. Service
          interfaces must
          > > therefore become much smarter. Instead of having to know ahead of
          time what
          > > specific data requirements are needed by a Service, the Service
          requester
          > > should be able to dynamically discover a Service interface that
          can not only
          > > provide the needed functionality, but also understand the
          information
          > > payload.
          > >
          > > *The ZapThink Take*
          > > SOA as a whole is an exercise in *loosening the coupling* of
          heterogeneous
          > > systems that have to cooperate to meet the needs of the business.
          As such,
          > > as companies seek to mature their SOA initiatives, they should be
          seeking to
          > > iteratively loosen the coupling of their systems at the various
          levels
          > > described above. The most amazing part of this loose coupling
          exercise is
          > > that the greater the degree of variability that can be tolerated
          by the
          > > system, the greater agility that you've enabled for the business.
          Even more
          > > so, if companies can manage to address all seven layers of loose
          coupling
          > > while maintaining a flat cost of architecture, then we've reached
          the
          > > desired state of the IT-Business relationship: IT can implement
          every
          > > requirement and desired outcome expressed by the business without
          imposing
          > > any additional time or cost impedance.
          > >
          > > To be specific, in a system that is enabled with all seven layers
          of loose
          > > coupling, changes to Service implementations, business processes,
          Service
          > > contracts, Service policies, runtime infrastructure, data schema,
          and
          > > semantics won't break the system. Can you think of any
          requirement by
          > > business not addressed in those levels of loose coupling? This
          vision of
          > > agility is precisely the aim of SOA, and it clearly requires much
          broader
          > > understanding of SOA than simply loose coupling of the
          implementation, which
          > > is the only capability provided by Web Services.
          > >
          > > **
          > >
          > >
          >
          >
          >
          > --
          > Nick Gall
          > Phone: +1.781.608.5871
          > AOL IM: Nicholas Gall
          > Yahoo IM: nick_gall_1117
          > MSN IM: (same as email)
          > Google Talk: (same as email)
          > Email: nick.gall AT-SIGN gmail DOT com
          > Weblog: http://ironick.typepad.com/ironick/
          > Furl: http://www.furl.net/members/ngall
          >
        • Steve Jones
          +1 on that +1 The phrase I like to use is appropriate coupling . I ve sadly seen systems built with a more religious intent that have excessive levels of
          Message 4 of 6 , Dec 9, 2007
            +1 on that +1

            The phrase I like to use is "appropriate coupling".  I've sadly seen systems built with a more religious intent that have excessive levels of "loose" coupling in areas where it just makes absolutely zero sense.  Often over a period of a year or so the developers realise this so they start using the same Java/C# stuff at either end so in effect you have XML as a marshalling construct only.

            Loose coupling is great when it is needed and an expensive waste of time where it isn't.

            Steve


            On 08/12/2007, jeffrschneider < jeffrschneider@...> wrote:

            A big +1 on ubiquity.

            Nick - here is the paper I mentioned to you. It's now 4 years old and
            could use an update...
            http://schneider.blogspot.com/couplingindex.htm

            As SOA consultants, we realize that there is no 'right' formula for
            coupling - we just needed guidance...

            Jeff

            --- In service-orientated-architecture@yahoogroups.com, "Nick Gall"
            <nick.gall@...> wrote:
            >
            > A few observations:
            >
            > 1. In deciding where to apply loose coupling and what aspects to


            apply
            > it to, keep the following rule of thumb in mind: Since the goal
            of loose
            > coupling is to enable independent change among interacting
            systems, only
            > loosen couplings between aspects of interacting systems that are
            likely to
            > change independently, ie at different rates from one another.
            Systems that
            > are highly likely to always change together do not need to be
            loosely
            > coupled.
            > 2. The list below is definitely a list of "aspects" (as Ron
            mentions)
            > NOT "levels", because they are largely independent of one
            another, eg, you
            > don't have to achieve implementation loose coupling to achieve
            semantic
            > loose coupling and vice versa. I think it is misleading to think
            of the
            > aspects below as levels; but it makes for a better headline.
            > 3. You can NEVER achieve "complete decoupling" of two interacting
            > systems: to interact in any way, there must be SOME dependencies
            (coupling)
            > between the two systems. If you don't believe me, read Herbert
            Simon's
            > "Sciences of the Artificial", where he discusses "decomposable
            systems", and
            > makes the same point.
            > 4. This list leaves out the most important aspect of loose
            coupling:
            > ubiquity. If I and only one other partner adopt the world's most
            dynamically
            > reconfigurable middleware architecture then he and I are tightly
            bound to
            > one another. Imagine the two of us dreamed up our own custom
            variation of
            > WS-*; let's call it WS-Silo. Then between the two of us, we
            could do all
            > sorts of nifty changes on one side to the interface without
            disrupting the
            > other side; but we can't interoperate with ANYONE else.
            >
            > Item (4) is an extreme example of the problem WS-* has run into.
            Because of
            > the complexity of the specs, vendor deviations from the specs,
            variations
            > allowed be the specs, etc., only small numbers of participants can
            > successfully interoperate with WS-*. Almost every deployment of WS-
            * is
            > effectively WS-Silo:inside the Silo all systems are loosely-
            coupled, but
            > only to a small number of other systems.
            >
            > The advantage of HTTP/REST is that, although I lose some
            implementation
            > loose coupling (since I'm now tied to HTTP) I gain the mature
            > interoperability of HTTP, so I can interact with anyone on the
            Internet.
            > This is why you see so little WS-* outside the firewall and so much
            inside.
            >
            > Bottom Line: When in doubt, choose an interoperability architecture
            that is
            > somewhat more tightly coupled, but vastly more ubiquitous, over a
            somewhat
            > more loosely coupled interop architecture that is comparatively
            rare.
            >
            > -- Nick
            >
            > On Nov 30, 2007 5:34 AM, Gervas Douglas <gervas.douglas@...> wrote:
            >
            > > [image: ZapThink]

            > > The Seven Levels of Loose Coupling Document ID: ZAPFLASH-
            20071128 |
            > > Document Type: ZapFlash
            > > *By: Ronald Schmelzer*
            > > Posted: Nov. 28, 2007
            > >
            > > When ZapThink talks about Service-Oriented Architecture (SOA), we
            > > generally try to avoid semantic arguments about what is and what
            isn't SOA,
            > > but rather try to focus on specific characteristics that identify
            > > Service-oriented systems and the benefits they provide
            organizations that
            > > adopt the architectural approach. In particular, we like to focus
            on three
            > > core tenets: loose coupling of Service consumers and providers,
            > > composability at a variety of levels of granularity, and event-
            driven,
            > > asynchronous styles of interaction that allow for a wide range of
            usage
            > > scenarios.
            > >
            > > While these characteristics might seem distinct, they are in fact
            related
            > > to each other. The ability to compose arbitrary Services in
            environments of
            > > long-running transactions requires a certain measure of loose
            coupling.
            > > However, architects seem to grapple with the term "loose
            coupling". Some
            > > erroneously think that systems are either loosely coupled or
            tightly coupled
            > > as if the determination of coupling is a binary evaluation. The
            reality is
            > > that the concept of coupling, like that of granularity, is a
            relative term.
            > > Something is more loosely coupled than something else if it
            allows for a
            > > greater degree of variability and freedom for that particular
            aspect. Simply
            > > put, coupling is a measure of dependency and commonality required
            by a
            > > Service consumer and provider to be able to achieve a result.
            > >
            > > In that light, loose coupling is a spectrum. A system can be
            tightly
            > > coupled in one aspect while being loosely coupled in another. Many
            > > architects say that they want complete decoupling of systems so
            that any
            > > variation in the system can be handled without having to
            reimplement any of
            > > the Service consumers or providers. As we've discussed in
            past<http://www.zapthink.com/report.html?id=ZAPFLASH-09292004>
            > > ZapFlashes <http://www.zapthink.com/report.html?id=ZAPFLASH-
            2006519>,
            > > complete decoupling is incredibly difficult and expensive, if not
            > > impossible. So, what architects should be aiming for is achieving
            the right
            > > level of loose coupling<http://www.zapthink.com/report.html?
            id=ZAPFLASH-05282004>to facilitate business agility without imposing

            huge costs.
            > >
            > > As such, what ZapThink has seen is that there are really seven
            levels, or
            > > perhaps aspects, of loose coupling that architects should
            consider in their
            > > SOA initiatives. The more degrees and levels of loose coupling
            they add to
            > > their SOA efforts, the greater those systems can deal with change.
            > >
            > > *Loose Coupling the Implementation*
            > > One of the most fundamental promises of SOA is that Service
            consumers are
            > > blind to the implementation technology used by the Service
            providers, and
            > > vice-versa. Indeed, the whole idea of the Service abstraction is
            that
            > > technology implementations are hidden. This most basic of SOA
            > > characteristics is realized using standards-based, interoperable
            > > specifications or protocols that provide a contract-based
            interaction
            > > between Service consumers and providers. Web Services certainly
            fits the
            > > bill as does REST and other styles of Service implementation.
            Indeed, it's
            > > not the choice of interoperable specification (whether XML based
            or not)
            > > that enables this level of loose coupling, but rather the Service
            contract.
            > > A properly written Service contract will allow Service consumers
            to bind to
            > > a wide range of Service provider implementations without have to
            know at all
            > > whether the Service implementation is done in Java, .NET, PHP,
            C++, or
            > > Basic. All SOA implementations must be at least loosely coupled
            at the
            > > implementation level, but clearly this is not enough to guarantee
            the sort
            > > of complete loose coupling so desired by the business.
            > >
            > > *Loose Coupling the Service Contract*
            > > XML, Web Services, REST, and other specifications hide the
            implementation
            > > of the Service such that when the Service implementation changes,
            the
            > > Service consumer does not need to be the wiser about it. However,
            what
            > > happens when the Service contract itself changes? A simple change
            to
            > > acceptable inputs or functional behavior of the system can have
            profound
            > > impact on Service consumers. As such, architects that want to
            progress their
            > > SOA initiatives beyond simply Web Service integration need to
            address
            > > Service contract change management in such a way that contract
            changes don't
            > > cause Service consumer breakage.
            > >
            > > This might seem to be a difficult proposition, but there are
            plenty of
            > > best practices, architectural approaches, and technologies to
            facilitate
            > > this level of loose coupling. First, a proper Service contract
            that is
            > > interface-neutral will alleviate much of the problem of Service
            contract
            > > change management. The Service Description Framework (SDF) shared
            by
            > > ZapThink in our Licensed ZapThink Architect (LZA) boot camps is
            one of those
            > > technology-neutral Service contract templates. In those
            approaches, new
            > > Service contracts don't simply replace old ones. Old contracts
            are never
            > > deprecated unless a transition path is provided for Service
            consumers. This
            > > can be as simple as a transformation or as complex as a Service-
            oriented
            > > process that is triggered when Service consumers request old (and
            > > deprecated) versions of the Service contract. As such, contract
            change must
            > > be handled as a matter of policy. Who gets what version of a
            Service should
            > > be controlled via metadata, not programmatically or via
            configuration of
            > > tightly-coupled infrastructure.
            > >
            > > Active management and Service intermediaries further simplify the
            Service
            > > contract change management issue by providing exception
            management and
            > > handling of Service contract differences. And of course, SOA
            Governance
            > > plays a huge role here in helping to manage the sort of change and
            > > versioning issues that arise. But probably the best practice in
            this arena
            > > is the use of late-binding approaches that leverage run-time
            registries and
            > > contract-based binding to abstract the binding specifics of
            Service
            > > consumers and keep Service contract changes from propagating. The
            topic of
            > > late binding is itself a deep conversation that requires
            rethinking the way
            > > that Service consumers bind to Service providers, and one too
            long for this
            > > ZapFlash.
            > >
            > > *Loose Coupling the Service Policy*
            > > So, putting into play Service contracts that abstract
            implementations and
            > > late-binding, intermediary-enabled, registry-based systems that
            allow for
            > > Service contract change without breakage enables a great degree of
            > > variability in the system, but we're still far from done. Indeed,
            even if
            > > the Service contract stays stable, a small change to a Service
            policy can
            > > have tremendous repercussions, as discussed in our Butterfly
            Effect
            > > ZapFlash <http://www.zapthink.com/report.html?id=ZAPFLASH-
            2006124>.

            > >
            > > Companies looking to address Service variability should handle
            changes to
            > > policy the same way they handle changes to Service contract: late-
            binding,
            > > Service intermediary-enabled, registry-based, and governed. A
            policy is a
            > > form of metadata, as are contracts, and in fact, the only
            difference between
            > > a Service policy and a contract is that a policy can apply to any
            number of
            > > Services. Because policies control many aspects of the non-
            functional parts
            > > of a Service, architects need to include in their architectural
            plans
            > > methods and practices for dealing with Service policy versioning
            and
            > > deprecation as well as policy versioning that leverages the
            technologies and
            > > practices established for Service contracts. Companies need to
            test policies
            > > just as they test Service implementations, and manage policies as
            rigorously
            > > as they manage Services. Doing so not only makes the system as a
            whole more
            > > reliable, but enables one more level of loose coupling.
            > >
            > > *Loose Coupling the Process*
            > > Of course, loosely coupling the Service consumer from a Service
            provider
            > > only provides agility if the Services aren't composed together.
            Once you
            > > have a business process that composes a bunch of Services
            together, we have
            > > another area of potential tight coupling. What happens when the
            process
            > > changes? Ideally, a Service consumer should not have to know at
            all when a
            > > process is reconfigured. Fortunately, achieving that level of
            loose coupling
            > > is fairly straightforward.
            > >
            > > The movement in the SOA and BPM markets has been towards
            separating the
            > > process definition layer from the underlying implementation. By
            defining
            > > processes in metadata and exposing those processes using Service
            contracts
            > > (the recursive vision of process compose of Service and exposed
            as Service)
            > > abstracts the implementation of the process from the Service
            consumer. In
            > > fact, in such a scenario, a business process is really a form of
            Service
            > > implementation. And just as Service contracts provide loose
            coupling of
            > > Service implementations, they provide loose coupling of Service-
            oriented
            > > processes.
            > >
            > > *Loose Coupling the Data Schema*
            > > If we've enabled all the loose coupling levels defined above,
            companies
            > > should be able to make arbitrary changes to their Service
            implementations,
            > > contracts, policies, and processes without breaking a thing (or a
            sweat).
            > > Yet, that's not sufficient to handle the changing needs of the
            business.
            > > What happens when the underlying data schema changes? If a
            Service consumer
            > > and provider need to have a common understanding about that in
            order to have
            > > a conversation, we have tight coupling as defined above.
            Therefore,
            > > organizations need to further their loose coupling goals by
            enabling dynamic
            > > and heterogeneous change to the data schema shared between
            Service consumers
            > > and providers.
            > >
            > > To some, this might seem to be a very complicated task. Computers
            aren't
            > > people, after all, and so they can't process any changes to the
            format or
            > > definition of data. Yet, not all hope is lost here. First,
            Services aren't
            > > really interoperable unless they can understand and process data
            in common.
            > > This means that while there might be semantic dependencies
            between them
            > > (which we will address shortly), there does not need to be
            structural data
            > > dependencies between them. Schemas are key to Service data
            interoperability.
            > > However, what happens when Schemas change? One key approach is to
            address
            > > information and schema management in the same way you approach
            Service
            > > metadata management. Data schema can be treated as a form of
            metadata and
            > > the use of exception management, transformations, Service
            intermediaries,
            > > and Data Services (described in more detail
            here<http://www.zapthink.com/report.html?id=ZAPFLASH-2006103>)
            > > are all key to enabling loose coupling of data structure.
            Implementing a
            > > Data Services layer introduces loose coupling in a way that
            provides a
            > > separation of concerns, so that underlying data infrastructure
            changes are
            > > insulated from the business Services above.
            > >
            > > Furthermore, companies need to align the efforts of those
            maintaining the
            > > data schema with those maintaining the Service metadata. Why is
            it that the
            > > folks who maintain the schema are not part of the architectural
            team? Schema
            > > are no different than Service contracts. They represent a form of
            metadata
            > > that encodes business requirements. As such, we frequently
            admonish
            > > companies to bring their data and information architect teams
            into their
            > > enterprise architect fold<http://www.zapthink.com/report.html?
            id=ZAPFLASH-10222003>.

            > > The simple act of this alignment and the establishment of
            metadata-enabled
            > > change management will allow for loose coupling of data schema and
            > > structure.
            > >
            > > *Loose Coupling the Infrastructure*
            > > Before we try to slay the last dragon of loose coupling, it's
            important to
            > > note that all these levels of loose coupling doesn't matter a
            whit if it all
            > > depends on a single vendor's implementation. Too many times we
            interact with
            > > architects who claim that their systems are loosely coupled, but
            if they
            > > move their implementation from one Enterprise Service Bus (ESB)
            or Service
            > > infrastructure to another then all hell will break loose. How can
            they truly
            > > say their implementations are loosely coupled with such a huge
            dependency in
            > > mind? Enterprise architects worth a grain of salt will demand
            that their
            > > Service implementations be infrastructure neutral. That means
            that at any
            > > time, the company can change their infrastructure without having
            to rebuild
            > > all the Service consumers and providers.
            > >
            > > Many vendors promise this sort of interchangeability, but few
            deliver. In
            > > fact, the industry as a whole seems to be moving towards single-
            vendor SOA
            > > platforms that will keep many SOA initiatives tightly coupled at
            this layer.
            > > This ZapFlash serves as warning to firms that want to achieve
            high degrees
            > > of loose coupling: keep your implementation infrastructure
            neutral and you
            > > will be successful. Otherwise, your SOA initiatives will only
            enable partial
            > > business agility.
            > >
            > > *Loose Coupling at the Semantic Layer*
            > > The final level of loose coupling is the most challenging of all.
            Even if
            > > a company is enabled to make all the changes it wants to Service
            > > implementation, contract, policy, process, infrastructure, and
            data
            > > structure, problems still arise whenever there is change to
            semantics. As we
            > > detailed in our Semantic Integration: Loosely Coupling the
            Meaning of Data
            > > ZapFlash <http://www.zapthink.com/report.html?id=ZapFlash-
            08082003>, if we
            > > impose the data structures of Service providers on Service
            requesters, the
            > > result is every bit as tightly coupled as previous architectural
            approaches.
            > > In order to provide the promise of seamless data integration, we
            must
            > > transcend simply loosely coupling the application interface and
            in addition
            > > provide loose coupling at the semantic
            level<http://www.zapthink.com/report.html?id=ZAPFLASH-2005217>.

            > >
            > >
            > > As we detailed those ZapFlashes, in order to achieve the sort of
            semantic
            > > data integration we are seeking, we must implement *dynamic*
            service
            > > definitions. In essence, the definition of the Service interface
            must change
            > > based on the context of the Service requester. As a result, a
            Service can
            > > change its contract between invocations. For example, the fact
            that a
            > > Service provider requires first names to be no longer than 40
            characters
            > > should not require the requester to know that fact. The
            contracted Service
            > > interface is supposed to provide that isolation. Service
            interfaces must
            > > therefore become much smarter. Instead of having to know ahead of
            time what
            > > specific data requirements are needed by a Service, the Service
            requester
            > > should be able to dynamically discover a Service interface that
            can not only
            > > provide the needed functionality, but also understand the
            information
            > > payload.
            > >
            > > *The ZapThink Take*
            > > SOA as a whole is an exercise in *loosening the coupling* of
            heterogeneous
            > > systems that have to cooperate to meet the needs of the business.
            As such,
            > > as companies seek to mature their SOA initiatives, they should be
            seeking to
            > > iteratively loosen the coupling of their systems at the various
            levels
            > > described above. The most amazing part of this loose coupling
            exercise is
            > > that the greater the degree of variability that can be tolerated
            by the
            > > system, the greater agility that you've enabled for the business.
            Even more
            > > so, if companies can manage to address all seven layers of loose
            coupling
            > > while maintaining a flat cost of architecture, then we've reached
            the
            > > desired state of the IT-Business relationship: IT can implement
            every
            > > requirement and desired outcome expressed by the business without
            imposing
            > > any additional time or cost impedance.
            > >
            > > To be specific, in a system that is enabled with all seven layers
            of loose
            > > coupling, changes to Service implementations, business processes,
            Service
            > > contracts, Service policies, runtime infrastructure, data schema,
            and
            > > semantics won't break the system. Can you think of any
            requirement by
            > > business not addressed in those levels of loose coupling? This
            vision of
            > > agility is precisely the aim of SOA, and it clearly requires much
            broader
            > > understanding of SOA than simply loose coupling of the
            implementation, which
            > > is the only capability provided by Web Services.
            > >
            > > **
            > >
            > >
            >
            >
            >
            > --
            > Nick Gall
            > Phone: +1.781.608.5871
            > AOL IM: Nicholas Gall
            > Yahoo IM: nick_gall_1117
            > MSN IM: (same as email)
            > Google Talk: (same as email)
            > Email: nick.gall AT-SIGN gmail DOT com
            > Weblog: http://ironick.typepad.com/ironick/
            > Furl: http://www.furl.net/members/ngall
            >


          Your message has been successfully submitted and would be delivered to recipients shortly.