Context
Software reuse can be a goal for IT departments that are building service-oriented (SO) solutions that are driven by executable business processes.
Problem
Mixing application-specific logic and atomic reusable logic makes it more difficult to reuse the atomic reusable logic
from composite services.
Note: In the context of our business process-driven systems, by application-specific we mean that
logic which is unique to the implementation of a specific process (and is not reusable across business
processes).
Forces
-
Where the implementation of a service operation contains both the logic that you want to reuse as well as other
logic (which therefore causes unwanted behavior), this reduces the likelihood of that operation being reused.
-
Appropriate reuse factoring does not happen by accident.
Solution
Factor application-specific logic into Participants that realize composite business application services.
These services and their Participants:
The behavior provided by a composite business application service is now the sum of the following:
-
The application-specific logic that is used to realize its operations
-
The atomic reusable logic that is implemented by each of the atomic services and infrastructure services
that its Participant uses to realize the composite service's operations.
As the composite business application services are themselves reusable, this arguably means that they provide a
higher-value level of reuse.
Rationale
Keeping application-specific logic separate from atomic reusable logic will help in the following:
-
Increasing the reusability of your atomic reusable services
-
Providing a further higher-value set of reusable services (any composite business application services that do not
themselves include application-specific logic).
|