Service Normalization Pattern

Service Normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services[1] that are part of the same service inventory[2] do not contain any redundant functionality.[3] This design pattern emphasizes on creating normalized services, much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

Rationale

When different teams are delivering multiple services as part of automating various business processes, there is a possibility that some of these services might end up having duplicate functionality. For example, the automation of two different business processes, by two different teams, which need to exchange messages with the same legacy system may end up in two different versions of a wrapper service that are created to enable exchange of messages with the services. This overlap in functionality can lead to other problems including which service to be advertised as the official service for the provision of a particular functionality and maintenance of redundant services as they can easily get out of alignment.

In order to deliver services, as part of the same service inventory, that are free of any duplicate functionality, the functional boundary of each service needs to be carefully established so that it is not in conflict with any other service. The Service Normalization[4] design pattern provides guidelines for creating service inventories that contain streamlined services without any functional duplication.[5] By creating normalized services, the purpose of the service also becomes clearer to its potential consumers.[6]

Usage

Diagram A
Diagram A
In the absence of a service inventory blueprint, the automation of Business Process 2 resulted in the creation of the red service which shares most of its functionality with the red service created earlier while automating Business Process 1.
Diagram B
Diagram B
The creation of a service inventory blueprint results in the merger of the two red services into one red service and any functionality not falling within the context of the red service is added to the new orange service.

The application of this design pattern requires knowledge about the functional contexts of all the services because only then it can be guaranteed that the services do not contain any overlapping functionality. This is achieved by creating service models i.e. services without any actual service contracts but having high level details about the kind of functionality that they would be providing. In order to create service models, following activities need to be performed:

  1. Decompose the business process into individual steps that falls within the boundary of a specific service inventory.
  2. Assign each step to an individual function of a service
  3. Make sure that the above functionality is not already provided by some other service.
  4. Even if a service provides part of the new required functionality, instead of creating altogether a new service, the new functionality needs to be added to the existing service as long as the functional context of the functionality being added matches with the existing service’s functional context.

The same process needs to be applied to each business process that falls within the boundaries of the service inventory.

By following the guidelines of the Service Normalization design pattern, the total number of services within the service inventory would also decrease. This is because the development of redundant services is avoided, which further helps in decreasing the governance overhead of the service inventory. The application of this design pattern further supports the application of the Logic Centralization and the Service Refactoring design patterns. This is because the services do not contain any redundant functionality and hence it is easy to retain logic that does not relate to a particular business process in a single service and to evolve a service without breaking any dependencies.

Considerations

The application of this design pattern requires following a top-down service delivery[7] process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of man-hours as well as time. This could be addressed by the adoption of meet-in-the-middle[8] service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory[2] blueprint.

An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.

References

  1. ↑ Services
  2. 1 2 service inventory
  3. ↑ Kanu Tripathi.Service Transaction Handling Without WS-AtomicTransaction[Online].Date accessed: 25 April 2010.
  4. ↑ Thomas Erl, Herbjörn Wilhelmsen.Service Normalization design pattern[Online]. Date accessed: 6 April 2010.
  5. ↑ Thomas Erl.Introducing SOA Design Pattern[Online]. Date accessed: 6 April 2010.
  6. ↑ Yefim V. Natis, Massimo Pezzini.Twelve Common SOA Mistakes and How to Avoid Them[Online].Date accessed: 25 April 2010.
  7. ↑ Top-down service delivery process
  8. ↑ meet-in-the-middle service delivery

Further reading

External links

This article is issued from Wikipedia - version of the Wednesday, May 28, 2014. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.