Much of this article is based on [JAM09c].
Allocating services to providers is not a simple exercise in meeting functional
requirements. Nonfunctional requirements and thorny architectural issues also
enter into consideration. These are among the driving factors:
- Functional cohesion to maximize reuse. Are there services that commonly
work in concert with each other? If so, perhaps it makes sense to provision
them with a single provider.
-
Where the services are most likely used, and where they are most likely to
be deployed. It helps to reduce network latency if those who provide the service
and those who use it are close to each other in the network.
-
What qualities of service are required. The Participant
is simply a conceptual wrapper for the underlying Service
Component. It might be necessary to use a specific service component to
provide a specified QoS level for three services. In that case, all three
services might be offered by the same Participant.
- Stability of the functional area.
-
Where the most change is anticipated. If three services are being designed
and one is highly unstable, the design decision (at least initially) could
be to ensure that it is not provisioned on the same Participant as the two
more stable services.
-
How much coupling is tolerable in the domain.
-
Reducing coupling to minimize the effect of change.
-
Applicable platform implementation technologies.
-
Integration and reuse of existing systems.
|