4.3. Elements of a Service-Oriented Architecture In this section, we take a closer look at the key elements of the SOA, including the application frontend, services, the service repository, and the service bus. 4.3.1. APPLICATION FRONTENDS Application frontends are the active players of an SOA. They initiate and control all activity of the enterprise systems. There are different types of application frontends. An application frontend with a graphical user interface, such as a Web application or a rich client that interacts directly with end users, is the most obvious example. However, application front-ends do not necessarily have to interact directly with end users. Batch programs or long-living processes that invoke functionality periodically or as a result of specific events are also valid examples of application frontends. Nevertheless, it is entirely possible that an application frontend delegates much of its responsibility for a business process to one or more services. Ultimately, however, it is always an application frontend that initiates a business process and receives the results. Application frontends are similar to the upper layers of traditional multilayer applications. Although you might expect that services more closely resemble the lower layers, this is not the case. The following chapters demonstrate that services have a different structure, which is characterized by vertical slicing. 4.3.2. SERVICES A service is a software component of distinctive functional meaning that typically encapsulates a high-level business concept. It consists of several parts (see Figure 4-3). Contract. The service contract provides an informal specification of the purpose, functionality, constraints, and usage of the service. The form of this specification can vary, depending on the type of service. One non-mandatory element of the service contract is a formal interface definition based on languages such as IDL or WSDL. Although it is not mandatory, a formal service interface definition adds a significant benefit: It provides further abstraction and independence of technology, including programming language, middleware, network protocol, and runtime environment. However, it is important to understand that the service contract provides more information than a formal specification. The contract can impose detailed semantics on the functionality and parameters that is not subject to IDL or WSDL specifications. In reality, many projects must cope with services that cannot provide formal service interface descriptions.[2] In these cases, the service can deliver access libraries or a detailed technical description at the network protocol level. However, it is important to understand that every service requires a service contractparticularly if no formal description based on a standard such as WSDL or IDL is available. [2] Notice that the key task of a project aiming to introduce SOAs at the enterprise level is often not to implement new business functionality, but rather to identify suitable existing application modules and components and wrap them with service interfaces with the appropriate level of functionality and granularity, thus making them available as services in an easier-to-use and better documented manner.
Interface. The functionality of the service is exposed by the service interface to clients that are connected to the service using a network. Although the description of the interface is part of the service contract, the physical implementation of the interface consists of service stubs, which are incorporated into the clients[3] of a service and dispatcher. [3] Application frontends or other services.
Implementation. The service implementation physically provides the required business logic and appropriate data. It is the technical realization that fulfills the service contract. The service implementation consists of one or more artifacts such as programs, configuration data, and databases. Business logic. The business logic that is encapsulated by a service is part of its implementation. It is made available through service interfaces. However, programming against interfaces is desirable, whether or not one applies a service-oriented approach. Data. A service can also include data. In particular, it is the purpose of a data-centric service (see Chapter 5).
Figure 4-3. A service consists of both data and business logic along with interfaces and their descriptions. 
As previously discussed, services are not just the encapsulation of some code of the former lower layers of applications. Every service is an entity of distinctive functional meaning that typically encapsulates a high-level business entity. Services impose a strong vertical slicing of the application that defines the coarse-grained structure of the whole system, similarly to component-oriented software design. Therefore, from the client perspective, a service is a black box entity. 4.3.3. SERVICE REPOSITORY A service repository provides facilities to discover services and acquire all information to use the services, particularly if these services must be discovered outside the functional and temporal scope of the project that created them. Although much of the required information is already part of the service contract, the service repository can provide additional information, such as physical location, information about the provider, contact persons, usage fees, technical constraints, security issues, and available service levels. It should be noted that we focus on service repositories that are mainly used for purposes within the boundaries of a single enterprise. Repositories that are used for cross-enterprise service integration typically have different requirementsin particular, those repositories that are made public through the Internet. These requirements can comprise legal issues (terms and conditions of usage), style of presentation, security, user registration, service subscription, billing, and versioning. Obviously, a service repository is a very useful element of an SOA. Although you can build an SOA and achieve many of its benefits without establishing a service repository, a repository is indispensable in the long term. An architecture can cope without a repository if the scope of a service is just one project, if it has very few services, or if all projects are staffed with the same team members. In reality, though, most enterprise scenarios are characterized by many concurrent projects, changing teams, and a variety of services. A service repository can be arbitrarily simple; at one extreme, no technology might be required. A batch of printed service contracts located in an office and accessible by all projects is already a valid service repository. However, better ways exist to provide this information while retaining the simplicity of the repository. Often, you'll find a type of proprietary database that contains some formalized administrative data and a more or less formal service contract for every version of a service. In some cases, companies have developed their own tools that automatically generate the service description from the formal service definitions (e.g., an HTML generator that takes WSDL as input, similar to a JavaDoc generator). This is particularly useful if the formal service definition is annotated with additional information about the service. Notice that this information is typically very different from the meta-information provided for low-level APIs, such as Java classes. This is due to the different roles that service definitions play in an SOA. Services typically are more coarse-grained, self-contained, and capable of supporting different usage patterns. In particular, services are typically not linked as in code libraries but are bound to at runtime. All the preceding results in different documentation requirements. The following are examples of information that should be contained in an enterprise-wide service repository: Service, operation, and arguments signatures, such as in the form of WSDL and XML Schema definitions. Service owner. In an Enterprise SOA, owners can operate at the business level (responsible for questions and change requests on the functional level), development level (responsible for technical questions and change requests), and operations level (responsible for questions regarding the best ways to link to a service, or operational problems). Access rights, such as information about access control lists and the underlying security mechanism, or a description of the process that must be followed within the enterprise so that a new system can utilize a particular service. Information about the intended performance and scalability of the service, including average response times, and potential throughput limitations. This can be summarized as part of a generic SLA (Service Level Agreement) template. Transactional properties of the service and its individual operations. This includes information on the read/write/update characteristics, whether the operation is idempotent, and associated compensation logic (see Chapter 8, "Process Integrity," for more details).
Manage Your Service Repository Centrally To provide a service repository with high quality services, consider setting up an architecture board. The architecture board's responsibility is to perform constant maintenance, monitoring, and coordination from a central location. It must manage the repository and carefully review the service entries it contains. This includes the fundamental design of the service itself, as well as its description in the service repository. Consequently, the architecture board must be involved from the outset of the development of new services in order to coordinate the service specification across different projects and business units, and it must ensure that a good compromise between ease of implementation, usability, and reusability can be achieved. |
It is important to distinguish between development time and runtime binding of services. Binding refers to the way in which service definitions and service instances are located, incorporated into the client application, and finally bound to at the network level. 4.3.3.1 Development-Time Binding If services are discovered and bound to at development time, the signatures of the service operations are known in advance, as well as the service protocol and the physical location of the service (or at least the exact name of the service in a directory service). Figure 4-4 describes a process in which services are bound to at development time. Figure 4-4. Development time discovery imposes a fairly simple model. The developer is responsible for locating all required information from the service repository in order to create a client that interacts correctly with the service instance. 
Although development time binding is quite a simple model, it is sufficient for most purposes. It enables projects to identify functionality that has been created by former projects and to reuse these services. 4.3.3.2 Runtime Binding Runtime binding is far more complex than development time binding. One can differentiate between different levels of runtime binding: Runtime service lookup by name. This is the most straightforward case, and it is also the most commonly used means of dynamically binding to services: The service definition is known at development time, and the client logic is developed accordingly. The client is enabled to dynamically bind to different service instances by looking up services with specific names in a directory. For example, a client application looks up printing services with different names, depending on the printer name selected by the user. Runtime service lookup by properties. This is similar to the preceding, except that services are discovered by properties, not by name. For example, a printing service can search a service repository for three different predefined printing service interfaces it understands, together with other properties such as location of the printer ("FLOOR == 2") and document formats that the printer is able to print ("DOCTYPE == PostScript"). Runtime service discovery based on reflection. In the final case, the actual specification of the service definition is not known at development time. Assume that a client discovers a service with the right properties ("FLOOR == 2 AND DOCTYPE == PostScript") but with an unknown printing service interface. In this case, some kind of reflection mechanism[4] must be implemented at the client side, which enables the client to dynamically discover the semantics of the service and the format of valid requests. This type of service discovery is the most complex and least widely used because it requires very complex logic to dynamically interpret the semantics of unknown service interfaces.[5] [4] Similar to mechanisms that are used in many object-oriented programming languages, such as Java's reflection mechanism.
[5] Notice that there is a case in between, where systems have to cope with many similar yet different message types, such as 12 different formats of a customer data record. A number of existing EAI tools (e.g., in Microsoft Biztalk Server) enable the user to graphically match fields in different data structures, providing runtime translation between these incompatible data formats. However, these mappings between data structures are provided at development time and are not dynamically determined by the system at runtime.
Runtime service binding that goes beyond the complexity of dynamic service lookup by properties with predefined service interfaces is very rare and is limited to very few application domains. A rare example for a problem domain that really requires highly dynamic service binding is in the wireless world, such as a Bluetooth application: Bluetooth clients dynamically discover services based on location and other properties. But again, even in this scenario, Bluetooth clients typically support a limited set of predefined services. Make Service Binding as Simple as Possible Always aim to make service binding as simple as possible because the level of complexity and risk increases exponentially with the level of dynamics in the service binding process. Service lookup by name with predefined service interfaces represents the best trade-off between flexibility and implementation complexity in the majority of cases. |
4.3.4. SERVICE BUS A service bus connects all participants of an SOAservices and application frontendswith each other. If two participants need to communicatefor example, if an application frontend needs to invoke some functionality of a basic servicethe service bus makes it happen. In this respect, the service bus is similar to the concept of a software bus as it is defined in the context of CORBA. However, significant differences exist between these concepts. Most importantly, the service bus is not necessarily composed of a single technology, but rather comprises a variety of products and concepts. An in-depth discussion of the service bus is found in Chapter 9, "Infrastructure of a Service Bus." For the time being, it will suffice to highlight the following characteristics of a service bus: Connectivity. The primary purpose of the service bus is to interconnect the participants of an SOA. It provides facilities that enable the participants of an SOAapplication frontends and servicesto invoke the functionality of services. Heterogeneity of technology. The service bus must embrace a variety of different technologies. The reality of enterprises is characterized by heterogeneous technologies. Consequently, the service bus must be able to connect participants that are based on different programming languages, operating systems, or runtime environments. Furthermore, you will usually find a multitude of middleware products and communication protocols in the enterprise, and all this must be supported by the service bus. Heterogeneity of communication concepts. Similar to the heterogeneity of technologies, the service bus must also embrace a variety of different communication concepts. Due to the divergent requirements of different applications, the service bus must enable different communication modes. Obviously, you must at least have facilities for synchronous and asynchronous communication. Technical"services." Although the purpose of the service bus is primarily communication, it must also provide technical services such as logging, auditing, security, message transformation, or transactions.
|
