SOA Pattern (#12): Service Layers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A service can be designed in a manner that it contains both the reusable logic as well as the process-specific logic. Similarly a service may contain logic that interfaces with legacy systems along with process-specific logic. Keeping these different types of logics within the same service severely restricts the evolution of the service and results in a service inventory that contains non-standardized services as services delivered by different project teams would contain a different blend of logic. By creating a service that contains a combination of agnostic and non-agnostic logic, the reusability potential of such a service is greatly reduced, which goes against the guidelines of the Service Reusability and the Service Composability principles. In order to standardize the way different capabilities are added to the services, the Service Layers pattern introduces a logical grouping of services, whereby the same group of services share a common type of functionality. By restricting the service to a particular type, the service can only encompass a particular type of functionality. This not only helps in easy evolution of the service but also helps to reduce the redundancy levels of the solution logic.
The division of a service inventory into logical groups is somewhat analogous to the different layers created in a typical software program, that is data, business and user interface layers. By dividing the software into a set of layers, the components or classes encompassed by a layer need to be designed in a particular manner so that they manifest the overall characteristics linked with that layer. This helps in bringing a structure to the software program and makes it easy to modify a layer without negatively impacting other layers. The same principle applies in case of service inventory where the application of the Service Layers pattern results in a more manageable service inventory as each layer consists of services that contain a specific type of functionality; hence the impact of change within a service remains minimal as long as it fulfills its contract.
Another important benefit related to creating different service layers is that it gives a bird’s eye view of the different types of functionality offered by the service inventory. This is something that could be of interest to the non-technical business IT team members because by tagging a service that it belongs to a particular layer, it inherits the characteristics of that layer and hence it becomes easier to understand the overall type of functionality provided by the service.
Normally a service inventory would be grouped into a set of task, entity and utility layers; however, it is quite important to understand that these three types are by no means cast in stone. In fact what is required is to first perform an analysis of the different types of functionalities contained within a service inventory and then to choose the most suitable service models that best represent the different kinds of functionalities contained within the service inventory. It should be noted that at least there should be two types of groups of services within an inventory: one that contains agnostic logic and the other that contains process-specific logic. In order to arrive at a set of layers, or more precisely which service models to choose, the creation of a service inventory blueprint is required. From the service inventory blueprint, the intended functionality enclosed by all candidate services can be analyzed to select the different types of service models required to best represent the broader types of functionalities within the inventory blueprint. This also gives an opportunity to move the candidate service capabilities in between different service candidates, belonging to different layers, in order to bring standardization to the design of the actual services so that a service only contains the right type of logic as dictated by its containing layer.
The application of the Service Layers pattern only establishes the different types of service layers that an inventory should contain; however, in order to actually design the services that make up the relevant layer, the Process Abstraction, the Entity Abstraction and the Utility Abstraction design patterns could be applied. It should also be noted that the categorization of a service inventory into different types of layers needs to be revisited as more and more SOA projects are delivered. This is because the categories established right at the start of an SOA initiative may only represent a subset of the business processes and as more and more business processes are automated, the service inventory increases in size and can result in new types of functionality that were not originally deem to be required. This means that until a service inventory becomes mature, a provision for a change in the categorization of the service inventory needs to be kept in mind. Once enough services exist in the service inventory so that they represent a meaningful part of the business domain, the established service models can be implemented as enterprise standards that can be applied to other or future service inventories.
The Service Layers pattern is one of the fundamental design patterns that helps to structure the service inventory in a manner that promises reduced governance overhead; however, its application requires performing top-down service-oriented analysis and design which demands increased resources both in terms of time and efforts.
The SOA Pattern of the Week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book “SOA Design Patterns” (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl (www.soabooks.com).