The Service Model has a (Candidate) Service Portfolio
The Service Model has a portfolio view -- either via organization-wide or more localized resources -- to the
services that are to be considered for development or reuse during the current project. |
The Service Portfolio is categorized appropriately
Service exposure decisions are documented
Each candidate service that is to be exposed during the current project must be documented as such. In terms of
the UML representation of the service model, SoaML ServiceInterfaces are created from the Capabilities that are
selected for exposure. The exposure decision can be marked by creating an <<Expose>> dependency
from the ServiceInterface to the appropriate Capability. |
Any protocols that must be followed by consumers and providers of a specific service have been documented.
See Concept: ServiceInterface (SoaML), Example: ServiceInterface (SoaML), Concept: ServiceContract (SoaML), and Example: ServiceContract (SoaML) for further discussion. If two roles are
involved in a protocol, the protocol can be effectively documented using a simple behavior that is directly owned by the
ServiceInterface. ServiceContracts are more effective if the protocol involves the interaction of three or more
roles. |
Service dependencies are documented.
Inter-service dependencies are discovered during Service Collaboration modeling. In the context of UML models, they are
documented by creating service RequestPoints on each Participant that realizes a given service.
If a service depends upon a non-exposed capability, this can be documented (in UML) by incorporating the capability
(non-exposed component, etc.) into the UML behaviors that describe the implementations (methods) of the service
operations.
|
Composite services and associated flows are identified and described.
A composite service is simply one that depends upon other services for its implementation. So, this item is related
to the previous checklist item. Make certain that the UML behaviors (Activities, Interactions, etc) for the service
operation implementations are documented. These behaviors document the service flows that implement each operation of
the composite service. |
Non-functional requirements have been identified and have been assigned to appropriate services.
The required Messages have been defined.
Services operation signatures have been fully specified.
State-management decisions have been documented.
|