Task: Detail the Service Components Layer
This task specifies the details of the components that realize services.
Disciplines: Architecture
Purpose
To provide detailed designs of the Service, Functional, and Technical components that realize services.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      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.
        Illustrations
        More Information