Context
Rational Unified Process provides the following definition for coupling:
The degree to which components depend on one another. There are two types of coupling, tight and loose. Loose
coupling is desirable to support an extensible software architecture, but tight coupling might be necessary for maximum
performance. Coupling is increased when the data exchanged between components becomes larger or more complex.
Component, as it is used in this definition, is a piece of software that is encapsulated and forms a unit of
independent deployment and versioning.
When components share artifacts it increases the coupling between them.
The specification of a component is made up of those artifacts that describe it from a black-box point of view.
Included in this are the following:
-
Service specification
-
Parameter types
Even if the implementations of a set of components are totally decoupled, if any of the components share parts of their
specification then this increases coupling.
Problem
Sharing specification artifacts between Participants has some problematic side effects.
Forces
-
Changes to these shared specification artifacts affect multiple Participants.
-
Where specialized versions of parameter types are required, there is a mixture of shared parameter types and
specialized "local" parameter types, which is slightly more complex than just having local parameter types.
-
The size of the shared service specification artifacts library quickly grows in size. Factoring these out
into separate libraries based on some factoring rule itself becomes quite complex.
Solution
Each Participant needs to own its:
Each Participant also needs to own its info types as well, but this is by definition as info types are used to model data
ownership (see Pattern 08: Model Data Control Points).
In this way the specification of the Participant is totally decoupled from other specifications. The only
resources shared between Participants are primitive types.
For composite business application services, where a Participant both provides and
requests services, there is some coupling between the composite business application service and the Participant
providing the services that it requires. You can break this coupling by introducing a local copy of the required
service specification.
Although it seems like substantial additional work to maintain separate copies of certain specification artifacts
(where they look the same across multiple service providers), this can be reduced (or even negated in some cases) by
using Rational Software Architect transformations-for example from domain types to parameter types.
Rationale
Not sharing specification artifacts prevents dependency issues as follows:
-
Changes to the specification artifacts mentioned above have only localized impact.
-
It is more clear as to where specification artifacts come from when they are used, as they are all local-in
other words, there is no combination of local and shared specification artifacts in use in a Participant
specification.
-
No rules are required for when to factor a specification artifact out as a shared artifact.
Note
In this pattern, we talk about keeping architectural elements decoupled, where the architectural elements are
the specification-level modeling elements from the service model. Keeping these architectural elements decoupled does
not imply that the realization or implementation of these elements (for example, the code) will be decoupled as well.
|