Services
Introduction
As a SOA is a collection of services it is important to understand the parts, special characteristics, and different types of services within a SOA. The first part of this paragraph briefly describes the different parts of a SOA whereas the second part will focus on the desired characteristics of services in a SOA. Thereafter, a classification of service types is given.
Parts of a service
[KRA07] divides services into five parts. These different parts of a service can be derived easily by looking at an example of a service:
From a business perspective when requesting a service first of all both requestor and provider need some kind of agreement (i.e. adequate compensation for provision of a service). This agreement is done via a contract which is the first part of a service. Such a contract usually specifies purpose, usage, constraints, and functionality. Moreover, a service contract can also include a machine readable interface definition which improves flexibility. Nevertheless, the most important part of the contract is a detailed description of the functionality performed by the service. Because a service is usually requested by one or more requestors it needs one or more interfaces which are the second part of a service. The third part of a service is the business logic which should be designed to perform the requested service as stated in the contract. The implementation part of a service is responsible for the technical realization of the business logic and builds the fourth part of a service. The last part of a service is the data processed by the implementation.
Service characteristics
All services of a SOA are basically implemented independently from each other. Nevertheless, a service could provide its functionality to another service which then to some extent relies on the providing service. The key point in the design of services is that its implementation is completely independent from its interface [BIH06].
According to [MAS07], services should fulfill the following requirements in order to fully leverage the whole potential of a SOA:
- Loosely coupled: Services should disclose their interface but never their implementation in order to maintain the loose coupling. Furthermore, tight coupling would be in contrast to the idea of achieving a high degree of flexibility.
- Message based interaction: All communication between services is based on asynchronous messaging.
- Dynamic discovery: As services are always software based and do not necessarily have to be situated on the same system as the service requestor there has to be a mechanism to discover which services providing which functionality are available at a certain point in time.
- Self deployment: Services should be able to deploy themselves in order to improve manageability.
- Implementation independence: Services have to be independent from any kind of implementation and are only described by their interfaces in order to support loose coupling.
- Self-government: Services should be decoupled from all other services. Connections between services are solely based on their interfaces whereas one service acts as a service consumer and one service acts as a service provider. This results in loose coupling allowing the replacement of one service by another.
- Policy based behavior: Particular quality of service levels should not be part of a service implementation since it makes the use of one service with different levels of quality impossible (i.e. different encryption mechanisms for different contexts of usage provided by one service).
Types of services
Classifying services into service types creates several advantages. Project estimations based on type of services can be far more precise because different types of services need different implementation and maintenance effort. The implementation strategy can also be chosen based on the type of service because the type roughly indicates the complexity of a service. The classification of services given in this paragraph is heavily influenced by the classification mentioned by [KRA07] and [MAS07]. Other classifications as introduced by [KUL08] use different categories but the identified services are comparable, though. The following paragraph gives a description of the four main categories and the application frontend:
Application frontends
Strictly speaking an application frontend is not a service in a SOA. Nevertheless it is of utmost importance as it represents the most visible part of a SOA. An application frontend directly interacts with the service requestor. It initiates a service on behalf of the requestor and receives the results. It could be realized as graphical user interface as well as a long-living event triggered process.
Basic services
Since these services are providing the basic functionality they are mandatory parts of a SOA. Basic services are characterized by high reusability, low frequency of change, and relatively low implementation complexity. They can be further divided into data-centric and logic-centric services.
- Data-centric services: Compared to a traditional application a data-centric service has a certain similarity to the data access layer since it handles persistent storage facilities. In contrast to the data access layer a data-centric service handles the persistent storage only for one business entity. If another business entity needs other data from the same storage device, there has to be another data-centric service. This vertical slicing adds a tremendous impact to the design decision of assigning entities to data-centric services.
- Logic-centric services: Providing the logical functionality such as calculations and algorithms, these services are also a rarely changing mandatory part of a SOA.
Intermediary services
These services are used to bridge conceptual or technological gaps in a SOA. Subsequently, the implementation complexity is rather high compared to basic services. The unique requirements and frequent changes in these services result in a low reusability potential. The four categories of intermediate services are:
- Technology Gateways: These services act as a bridge between two different technologies. A typical scenario is shown in [1]where two services using the incompatible technologies A and B need to communicate. In order to allow this communication taking place, a service using technology A communicates with the technology gateway service. The technology gateway service ports the message into technology B and forwards it to the service using technology B.
An obvious real life example of the scenario showed in [1] would be the integration of a legacy system using a technology gateway service as intermediary.
- Adapters: An adapter is an intermediary service which only converts message formats. Hence, it is relatively easy to implement but offers great benefit by enabling quick mapping between different applications.
- Facades: They can be technology gateways as well as adapters providing different views on one service. This enhances reusability because it can be used as access layer providing different views to different stakeholders although using exactly the same service.
- Functionality adding services: If existing services need to be extended in terms of functionality and the source code is not available, functionality adding services can be a reasonable workaround. By adding functionality to existing service the existing service itself and all its consumers are not affected.
Process centric services
These services’ primary task is to control the business processes. Hence, they separate process logic from the business logic which is important in order to preserve reusability for the non-process centric services. In contrast to the previously explained processes these processes have to be stateful in order to be able to manage the state of a process and therefore introduce complexity to some extent. However, they also enable the benefits of load balancing.
An alternative approach to process centric services is to include the task of process control in the application frontend. Although this approach moves the process logic out of the scope of the main services it is a sufficient solution for many cases.
Public enterprise services
Public services are different from the ones solely used within the enterprise. These services are offered to service consumers who are rather unknown and no tight relationship and hence less trust between service provider and service consumer exist. To overcome the obstacles of loose relationships, public enterprise services have to pay special attention to the choice of granularity, security, and billing. In terms of granularity these services tend to be coarser grained than other services in order to imply the whole business meaning of the provided service. Moreover, these services have to add tougher security mechanisms to comply with the standards and policies for communication outside of the enterprises systems. Another important aspect is billing. Public services most probably result in some kind of cash flow which needs to be accurate and controllable. Although these requirements can be perceived as a barrier to open a SOA to the public it is in many cases worthwhile because it further extends the benefit of a SOA by this kind of business enablement. Such a benefit could be for instance a new business opportunity or new business partnerships enabled by the use of public enterprise services.
Granularity
Service granularity is a measurement for the size of a service. In this context size refers to the scope of a service as well as the functionality of a service. The fundamental design principle is to allow the accomplishment of one single activity of a business process with one single service interaction [KUL08]. Nevertheless, as mentioned in the service type descriptions, different types of services require a different granularity.
As shown in [2], the reusability potential is lower, if services are too coarse grained because a coarse grained service represents a specialized task, which is more seldom used than a rather basic unit of a process. Additionally, service changes happen more often because more functionality is bundled within one service. Also overhead can occur because messages have to carry more than the needed data in order to satisfy the requirements of a complex interface. This can negatively affect the performance of a SOA. A negative impact on performance also occurs if a service is too fine grained because various messages need to be exchanged in order to accomplish one unit of work. The selection of the right granularity also heavily affects the SOA governance. Maintainability for instance gets more difficult with a growing number of services which is the result of a too fine grained service design (see [2]).
Letzte Änderung: 11.05.2009, 16:09 | 1700 Worte