GooBiz

Identity : Evolvable Service Specifications

Intent :

Confering easy evolutions to complex service components by allowing refinement and traceability toward lower level components. Such refinement techniques also aim at wrapping up services to interfaces provided by other services or legacy system components without causing alteration on the description of both source and target service interfaces.

 

Solution : This pattern considers complex operations of a business service specified at a given refinement level. It then deduces underlying services to be realized at the immediate lower refinement level. The refinement process may continue til all components of the capability are identified or operations of the service component are interfaced with available services (provided interfaces or primitives).

 

Explanation of the solution :

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 may be particularly useful for analysts / designers that have to adapt services to available component interfaces. The wrapping process is realized 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 component a goal-driven composite service.

 

 

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

 

 

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, a complex operation of a service can be wrapped to interfaces provided by available components without alteration on this operation. This allows analysts to keep business knowledge provided by business experts and to capitalize on such business invariants independently of technical artifacts.

 

 

Notice : Encapsulating service structures inside the functional boundaries of a capability helps to understand how to reconfigure these structures to realize desired effects imposed by changings goals (vision, strategies, tactics, etc...).

 

 

 

 

INTERFACING WITH LEGACY COMPONENTS

 

Another advantage offered by this pattern is that interfaces provided by the server system (i.e legacy systems) 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 reifiying them using underlying services respectively 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]

 

 

Strenghts of the pattern PESS : This pattern aims at wrapping business services discovered using the Pattern for Identifiable Services - PISS to interfaces provided by other services or 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 advantage of such a solution is that business services are wrapped to interfaces provided by other services or legacy system components without alteration on their description. Thus, it contributes to the longevity of services for sustanaible architecture development.

 

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

 

The figure below shows other patterns that are linked to PESS to support realization of target capabilities in face of changes. This set of patterns aims at building up a proactive business architecture on the basis of a Goal & Capability-Driven Development backbone.

 

Figure 3 : Relationships between the pattern PESS and other patterns of the Goal & Capability Driven Development backbone : Click on each referenced pattern icon to visualise its detailed description