Task: Component Specification (SOA)

Model Component Interfaces

Components, and in particular Service Components, should not provide operations directly, they should instead use interfaces to describe a set of operations and then provide/realize the interface. This is described in general in the RUP, see Task: Subsystem Design (SOA) and Task: Identify Design Elements.

Example

In our Rent-a-Car example we have identified (through Subsystem Analysis) the need for a Reservation Service Component. To ensure a reusable and flexible design we may also create a corresponding Reservation interface, or use the Service Specification (from Task: Service Specification) to describe the interface to our Service Component. The Component will realize (in UML terms) each provided interface and may also denote it's dependency on other component interfaces using the UML usage relationship, as shown in the diagram below.

Note that we have elided the details of the interfaces themselves for clarity.

Model Component Attributes

In this step, we will define the details of each service component, including attributes, services, policies, and rules. The template that is to document Service Component specification will include the following attributes:

Properties or Attributes
Rules
Variations
Depends on <other components>
Composition of Functional and Technical components
Services Provided
Services Required

Model Component Events and Messages

During this activity, we identify the events that the component must sense and respond to when they get triggered. In-coming and out-going component messages are also specified. For services that are driven by changes to data, a data-centric view must be taken and business processes not within the scope of the service-based solution must be identified and assessed for generation of events and the supplying of data to the consumer services in the service-oriented solution. For example, a new client may be added by multiple business processes within an ISV package. In all cases, the same data may not be captured for the client depending upon the specific context of the business process. Consumer services that need to be aware of new clients through a provider service need to be able to able to handle the invocation of the new client service regardless of the business process that generates it.

Model Component Internal Structure

During this activity, it is important to create at least a class diagram showing the relationships between the functional and technical components of each service component. Standard UML modeling is applied at this stage. Use of patterns is encouraged to structure the resulting object graph in a manner that is extensible and open to changes. If a large degree of change is anticipated, it is recommended to conduct Variability Analysis at this stage.

As described in the previous task, when designing for change, or anticipating significant impact on the design and structure of IT system as a result of the future business changes, then it is wise to employ the Variability Analysis techniques. These techniques refactor commonality and externalize variations using design patterns. The commonality and variations discovered earliercan be used as a starting point and augmented through the use of common design patterns such as Strategy, State [i], Rule Object [ii] ,Type Object, etc.

Analysis done during detailed design identifies commonality and focuses on building pluggable variations and involves six principles that help separate the changing from the less changing aspects of software systems and isolate and encapsulate the changes:

Separate and model changing from non-changing aspects of the domain: Identify, Separate, Encapsulate and Externalize Increasing Variations.
Create type hierarchies for each variation point.
Assign Rule Types to each Variation Type.
Implement three-levels of abstraction; use aggregate inheritance meta-pattern.
Start from reuse levels higher than objects and Build Assets at each reuse Level; Build Small Frameworks around Variation Points. In general, each Framework should have no more than 7+-2 classes.
Each Reuse Element has its own behaviors. Externalize behavior as configurable data that can be read into the application to allow soft-wiring.

[i] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addision-Wesley 1994.

[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number: wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

Model Component Flow

During this activity, we identify the internal flow of control within the service component. This can be represented as a sequence or activity diagram.

ISV Consideration: The Component Internal Flow within an ISV package Component may or may not be exposed and/or configurable depending upon the package. If objects within the ISV Component are exposed and configurable, their flow may be tailored and customized to better meet the solution. However, one should be cognizant of any potential ongoing maintenance issues associated with doing so. In many cases, it will not be possible, nor even necessary, to identify the Component Internal Flow within an ISV package. In this case, the ISV Component should be considered a "black box", with only exposed and realized services documented.