Task: Detail the Service Components Layer |
|
 |
This task specifies the details of the components that realize services. |
|
Purpose
To provide detailed designs of the Service, Functional, and Technical components that realize services. |
Relationships
Roles | Primary:
| Additional:
| Assisting:
|
Inputs | Mandatory:
| Optional:
| External:
|
Outputs |
|
Main Description
In this task, we leverage prior work performed during Task: Document Service Realization Decisions to detail the designs of the
Service, Technical, and Functional components that realize services. We assume that we have the following level
of artifacts in hand:
-
A completed Service Model;
-
A Component Model, including (at least) external specification of Service, Functional, and Technical components,
their relationships, and the behavioral flows between them;
-
Architectural Decisions, including realization decisions for each Service Component.
Unless this is a greenfield development, it is likely that a Component Design artifact, which documents the internal
details of the components, exists with some usable content.
We further assume that IBM's SOA Solution Stack is being used as the SOA functional reference architecture.
The results of this task include the following:
-
Detailed designs of the Service, Functional, and Technical components, ready for implementation;
-
Details of how the components will be integrated at run-time; and
-
Details of how the components will leverage the resources from the Operational Systems layer of the SOA Solutions
Stack.
The following steps are not necessarily performed in sequence. Rather, view them as a collection of actions to be
performed as the service components are detailed.
|
Steps
Design the interfaces between the Service Components and the Operational Systems layers
Task: Document Service Realization Decisions results in mappings being created
between some Service Components and components in the Operational Systems layer that will realize them. Guideline: Making Realization Decisions describes some of the techniques that
can be used for service-enabling these pre-existing assets. This step involves developing the details of how those
realizations are to be implemented. Document these decisions in the Component Model or in Component Design.
|
Design the internal details of to-be-built components
In some cases, new components must be created for the Service Components layer. Use standard object-oriented and
component design techniques, such as are described in the Component Based Software Architecture practice of the IBM
Practice Library, to specify the internals of these components. Alternatively, apply the techniques described in the
Service Specification practice recursively to drive down to the lowest levels of design detail. Be certain to
reuse appropriate patterns, such as those described in Guideline: Service Component Patterns and in numerous IBM redbooks on patterns.
Document this work in the Component Design work product. |
Specify necessary interactions with the layer's run-time infrastructure
In many cases, the components in this layer will not need special knowledge of the run-time infrastructure that surrounds
them. If this is not the case, be certain to honor the necessary interactions in the detailed design.
Document this work in the Component Design work product. |
Allocate code elements to micro-layers within the Service Components layer
Think through how future code elements will be packaged in order to control visibility and access.
Some things to consider in making these packaging decisions include the following:
-
All components that provide application-independent business functionality can go in one layer.
Application-independent business functions are things like "customer management" and "product management" that
apply to a range of different applications.
-
All components that provide technical functions, such as error handling, authentication, logging and audit could go
in another (logical) layer. These components are both business and application independent. In some cases,
proximity of technical to functional components might require they be placed in a common layer. These are
architectural decisions and need to be documented as such.
|
Document run-time relationships between component instances
Until the ultimate (leaf-level code module) level of decomposition is reached, the components in this layer are akin
to the Participants which were specified in the Service Specification practice. That is,
they are components that (should) expose their capabilities using well-defined and well-described interfaces.
Accordingly, the run-time (instance-level) structure and behavior of the components which are found at each level of
decomposition can be described using the same techniques -- such as conventional Collaborations and
ServicesArchitectures -- which were used during Service Specification. Describe higher-level interactions in the
Component Model, and detailed interactions (driving component internals) in Component Design. |
|
Properties
Predecessor |
|
Multiple Occurrences |  |
Event Driven |  |
Ongoing |  |
Optional |  |
Planned |  |
Repeatable |  |
More Information
|