GooBiz

Identity : Evolvable Service Specifications

Intent :

Confering easy evolutions to complex service components by allowing refinement and traceability of their operations toward lower level components. Such refinement techniques aim at wrapping services discovered for the Goal-Driven Service Oriented Architecture (GD-SOA) to interfaces provided by other services or legacy system components without any modification on the description of both source and target services.

 

Solution : This pattern considers complex operations of a business service specified at a given refinement level as underlying services to be realised at the immediate lower refinement level. The refinement process should continue until all of the operations of the service component become executable using available services (provided interfaces or primitives).

 

Explanation :

On the basis of the service specifications (see Pattern for Identifiable Service Specifications - PISS ) provided by business experts (at the CIM level of the MDA), this pattern is particularly useful for analysts / designers that have to adapt object-oriented representations of services to available component interfaces. This wrapping process is realised by the reification of complex operations of a base service using operations of underlying services.

Such a refinement process then requires to focus on operations of the underlying service component in order to render them wrappable to interfaces provided by other components.

The base service with its underlying services that are obtained by refining its operations constitute together a composite service.

The figure below illustrates refinement of the operation enter_visitor() of Visitor [Registration] (service illustrated by the service component at the left). This operation is reified by the nested service component Visitor [entry], situated in the context of the emerging composite service Visitor [Registration] . We call such a composite service a GOO_Comp (Component of Goal Oriented Objects).

 

 

Figure 1 :Refinement of complex operations like enter_visitor() of the service Visitor [Registration] (service illustrated by the component at the left) using underlying service components

 

 

The traceability between a complex operation and its corresponding nested service component -that refines this operation- is ensured by naming conventions. For instance, the operation enter_visitor() of Visitor [Registration] is refined by contextual operations of Visitor[entry] that are orchestrated by their controler operation enter_visitor().

 

 

By applying this pattern, the wrapping process of a complex operation of a base service to interfaces provided by available components is realised without any modification on this operation. This permits analysts to keep business knowledge provided by business experts and to capitalise on such business invariants independently of technical artefacts. Another advantage offered by this pattern is that components of the server system (like legacy systems) that provide their interfaces are not altered after the wrapping process.

 

The figure below shows wrapping of the operations enter_visitor() and notify_visitor() of the service component Visitor[Registration] by reification using respectively the underlying services Visitor[Entry] and Visitor[Notification] .

Contextual operations of such underlying services are obtained by considering operations available within provided interfaces that may be used to realise enter visitor() and notify visitor() of the base service Visitor [Registration].

 

Figure 2 : Refinement of the operations enter_visitor() and notify_visitor() using respectively operations of underlying components Visitor[Entry] and Visitor[Notification]

 

 

Conclusion (Forces of this pattern) : This pattern aims at wrapping business services discovered using the Pattern for Identifiable Services - PISS to interfaces provided by other services or the legacy system components. It confers easy evolutions to service components by allowing refinement and traceability of their operations by the use of lower level components. The force of such a solution is that business services are wrapped to interfaces provided by other services or legacy system components without any modification on their description. Thus, it contributes to the longevity of business services whatever interfaces provided by available components may become - in the context of a sustanaible development architecture.

 

Relations : The pattern PESS is a basic pattern in the context of the Goal-Driven SOA. Evolvable services provided by the pattern PESS are used by the Pattern for Executable Service Specification - PEXS and the Pattern for Coherent Evolution - PCE that aim respectively at early testing services independently of solutions (means) and technologic platforms and bringing a coherent evolution to the system components in face of changes.

 

 

Figure 3 : Relationships between the pattern PESS and other patterns for the Goal-Driven SOA : Click on each referenced pattern icon to visualise its detailed description