Service Oriented Architecture

Service-oriented architecture (SOA)

Service-oriented architecture is a design principle in which software is designed and built in pieces that provide well-defined services when requested. The services may involve performing some activity or returning some information or answer. Most current custom software development is designed and programmed using SOA. Vendor packages that can be purchased usually also provide the capability to interact as services that can be invoked through an API. Service-oriented architecture is particularly relevant in integration because the well-defined nature of the services directs the various systems and technologies on the protocol for interactions. SOA best practice principles include a loose coupling of services, such that the particular technology used in implementations of the various services should not be of interest to users or applications trying to invoke those services, but simply the result. Data services in SOA are those that either provide or update information.

The differences between an ESB and an SOA are first that an ESB is a tool or engine whereas SOA is a design philosophy, and second, that ESB is usually used in a heterogeneous application environment of differing technologies that want to pass data around, whereas SOA implies a more heterogeneous technology environment. An ESB might be connecting some applications that have been written as services, but usually includes applications that have not been written consistently and so the ESB provides the needed layers of technical translation and transformation. If all applications that need to interact have been developed using consistent standards and protocols, then an ESB might be unnecessary, but it still provides the orchestration necessary for the interactions. In the real world of integrating new applications with older legacy applications, an ESB is needed. Coding the overhead of orchestration of the interactions of the application into the code of the application software would be a great burden that is easier to offload onto the specialized ESB technology, just as we offload the overhead of data storage to a database management system.

A bit of tension exists between efficient real-time data integration solutions and pure service-oriented architecture. Software designers and application architects may want to implement all things in an application as services, in order to stay true to the design principles of SOA. However, in most applications it may be more efficient for the application programmers to understand how the data is actually being accessed, such as through an ESB or a database management system (DBMS), and designed and coded according to the efficiencies of the underlying data solutions. This issue can be contentious. Much of the functionality of the service layer, or code, around a data service, such as security access checking, may be redundant, duplicating the services performed by the underlying database management software. Solutions coded to retrieve or update data that don’t take into account the underlying solution may be so slow as to be unworkable, with unacceptable delay in response, or latency.

Improvements in solutions and technologies have started to make the need to understand the underlying implementation of data services somewhat less necessary. See the discussion of data virtualization in Chapter 20 later in this book. Achieving balance of data integration solutions and SOA working together depends on finding the right balance in granularity when defining services. For operational efficiency, it is not a good idea to define data services of too fine granularity; it is better to define application services that perform recognizable business functions. Again, this may contrast with some SOA design principles, but in practice it may be necessary to loosen some pure theory in order to achieve better performance efficiency.

Service-oriented architectures include a registry of available services and how they are invoked. Although originally the protocol used with SOA was SOAP (simple object access protocol), it has become common to use alternative protocols such as REST (REpresentational State Transfer).

Service Oriented Computing

Service Oriented Architecture (SOA) is a style of design in which applications are composed in whole or in part of reusable services. SOA aligns information systems technology well with business objectives by modeling an application as a composition of reusable services. In contrast to the object-oriented (OO) paradigm, services are designed to model functions rather than things. They are a natural abstraction of the concept of business services; that is, services that a business provides to its customers and partners. A service can be implemented using an object, but it need not be. For example, it may be implemented using a procedure, stored procedure, asynchronous message queue, or script. Services are characterized by the messages they exchange and by the interface contracts defined between the service requester and provider, rather than by the programs that are used to implement them.

Service orientation has been around for a long time as a concept. However, only recently has it become mainstream, with many large-scale web sites for web search, social networking, and e-commerce now offering service-oriented access to their functions. In part, this wide availability is due to the advent of standard Web Services protocols. Web Services is an implementation technology that enables independent programs to invoke one another reliably and securely over a network, especially the Internet. Many vendors now support Web Services protocols. This enables one to implement SOA in a multivendor environment, which is a requirement for most enterprises.

A TP system that is created in whole or in part using the SOA approach may include multiple reusable services offered by a single transaction program or by multiple distributed services. An SOA-based TP system may include both synchronous and asynchronous communications mechanisms, depending on the message exchange patterns that a given service supports and the execution environment in which it runs. SOA-based TP systems may be assembled using a combination of services from a variety of applications and using a variety of operating systems, middleware platforms, and programming languages.

Figure 1.3 illustrates the components of a service-oriented architecture. They include a service provider that offers a service, a requester that invokes a service, and a registry (sometimes called a repository) that publishes service descriptions. The service descriptions typically include the service interface, the name and format of data to be exchanged, the communications protocol to be used, and the quality of service that the interaction is required to support (such as its security and reliability characteristics and its transaction behavior).

Figure 1.3. Basic Architecture of Service Orientation. A service provider publishes its interface in the registry. A service requester uses the registry to find a service provider and invokes it. The corresponding Web Service technologies are WSDL, UDDI, and SOAP.

A caller communicates with a service by sending messages, guided by a message exchange pattern. The basic pattern is a one-way asynchronous request message, where a caller sends a request message to the service provider and the service provider receives the message and executes the requested service. Other common patterns are request-response and publish-subscribe.

The registry is an optional component because the requester can obtain service description information in other ways. For example, a developer who writes the requester can find the service description on a web site or be given the service description by the service’s owner.

One mechanism to implement SOA is Web Services, where a service requester invokes a service provider using the protocol SOAP.¹ The service interface offered by the service provider is defined in the Web Services Description Language (WSDL). The service provider makes this interface known by publishing it in a registry. The registry offers access to service descriptions via the Universal Description, Discovery, and Integration (UDDI) protocol. A service requester and provider can be running in different execution environments, such as Java Enterprise Edition or Microsoft. NET.

Web Service interfaces are available for virtually all information technology product categories: application servers, object request brokers, message oriented middleware systems, database management systems, and packaged applications. Thus, they provide interoperability, meaning that applications running on disparate software systems can communicate with each other. Web Services support transaction interoperability too, as defined in the Web Services Transactions specifications (discussed in Section 10.8).

Services simplify the assembly of new applications from existing ones by combining services. Tools and techniques are emerging to simplify the assembly of services, such as the Service Component Architecture for Java and the Windows Communication Foundation for Windows.

A TP application may exist as a combination of reusable services. The use of reusable services doesn’t change the functions of the front-end program, request controller, or transaction server. However, it may affect the way the functions are designed, modeled, and implemented. For example, in Figure 1.2, the decision to build the request controller as a reusable Web Service may affect the choice of implementation technologies, such as defining the interface to the request controller using WSDL and invoking it using SOAP. That decision may also affect the design by enabling an end-user device such as a web browser to call the request controller service(s) directly, bypassing the front-end program. We’ll talk a lot more about TP software architecture in Chapter 3.

Representational State Transfer (REST) is another approach to SOA, rather different than that of Web Services. The term REST is used in two distinct but related ways: to denote the protocol infrastructure used for the World Wide Web, namely the Hypertext Transfer Protocol (HTTP); and to denote a software architectural pattern that can be implemented by web protocols. We use it here in the former sense, which we call REST/HTTP. We will discuss the REST architectural pattern in Section 3.3.

REST/HTTP focuses on the reuse of resources using a small set of generic HTTP operations, notably GET (i.e., read), PUT (i.e., update), POST (i.e., insert), and DELETE. This is in contrast to Web Services, which uses services that are customized for a particular application. Each HTTP operation is applied to a resource identified by a Uniform Resource Identifier (URI). A registry function, as shown in Figure 1.3, is needed to translate each URI into a network address where the resource can be found. On the Internet, this is implemented by the Domain Name System, which translates domain names such as www.mydomain.com into IP addresses.

In REST, generic HTTP operations are used to perform application-specific functions. For example, instead of invoking a Web Service AddCustomer, you could use REST to invoke the POST operation with a URI that makes it clear that a customer is being inserted, such as www.company-xyz.com/customers. In general, the application-specific information that identifies the function and its parameters must be embodied in the representation of the resource. This is why this style of communication is called representational state transfer. In practice, the representation that is transferred is often in a standard, stylized form, such as JavaScript Object Notation (JSON).

The format of the representation is specified in the HTTP header; the content-type and accept fields specify the format of the input and output, respectively. Thus, instead of specifying data types in a service’s interface definition, the caller specifies the data types it would like to receive. This flexibility makes it easier for diverse kinds of callers to invoke the service.

REST/HTTP is popular for its speed and simplicity. Web Services require parameters in SOAP messages to be represented in XML, which is expensive to parse. XML is self-describing and highly interoperable, but these benefits are not always important, for example, for simple services. A very simple interface makes it easier and faster to manipulate in limited languages such as JavaScript.

Service-Oriented Architecture

In addition to the multitier application architecture, application design methodologies play a role in the structure of TP applications. Service-oriented architecture (SOA) is one such design methodology, which was discussed in Chapter 1. In SOA, the designer identifies a service that a business provides for its customers and partners. The designer maps this business service to a software service, which is an operation. Typically, a set of related operations are grouped together in a service interface. Each operation in a service interface is implemented as a software component that can be invoked over a network by sending it a message. In SOA, operations are intended to be relatively independent of each other, so they can be assembled into applications in different combinations, connected by different message patterns.

In a TP system, a service can implement a transaction or a step within a transaction. That is, it can play the role of a request controller or transaction server. In either case, it is invoked by sending a message to the service. In this sense, the notion of a service is nicely aligned with multitier TP system architecture.

This alignment between SOA and TP depends only on the fact that SOA decomposes applications into independent services. It does not depend on the particular technology that is used to define service interfaces or to communicate between services, such as RPC or Web Service standards.

2.3 Service-Oriented Architecture

SOA is a technology-independent architectural style, although the most common implementation of SOA relies on Web Services (the ones adhered to W3C/OASIS protocols [18,19]) and, more recently, on REST Services (also known as RESTful Web Services) [20]. One of the reasons that favors the adoption of MDD approaches to produce SOAs is that developers can reduce the learning curve of the related technologies and standards, for example, in the case of Web Services, developers would have to cope with a huge amount of notations such as WSDL, UDDI, SOAP, XML, WS-Security, WS-BPEL, etc.

Chapter Two Service-Oriented Architecture

Service-oriented architectures allow for business logic to be invoked across a network and can be discovered and used dynamically. A service is a behavior that is provided by a component for use by any other component-based service using only the interface contract. It stresses interoperability and may be dynamically discovered and used.

4.2 Network as a service

4.2.1 Service oriented architecture

The service oriented architecture (SOA) is the concept of building a software system based on multiple integrated logical units. These units known as services allow better construction and management to solve large problems in different domains. The basic components of SOA are elucidated in Fig. 8. The architecture depends on the Services used by the Service User entity. The Service Provider hands over these services and the Service Registry coordinates the services’ information and publishes them for the Service User [38].

Fig. 8. Components of SOA.

SOA satisfies the requirements of different applications by balancing the computational resources. It virtualizes and integrates these resources in form of services entities. Therefore, the basic aspect of SOA is the “coupling” between different systems. Every system has information about the behavior and implementation of its partners. The information gathering procedure facilitates the coupling feature in SOA.

SOA eliminates the tight coupling and lack of interoperability between diverse middleware in a network. It has been endorsed by Cloud Computing (CC) services; Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). Fig. 9 elucidates SOA in CC environment. CC implements SOA in its different fields to exploit the resources’ virtualization feature. This in turn allows SOA to introduce Network as a Service (NaaS) into CC [7].

Fig. 9. SOA in cloud computing environment.

4.2.1 Service oriented architecture

The service oriented architecture (SOA) is the concept of building a software system based on multiple integrated logical units. These units known as services allow better construction and management to solve large problems in different domains. The basic components of SOA are elucidated in Fig. 8. The architecture depends on the Services used by the Service User entity. The Service Provider hands over these services and the Service Registry coordinates the services’ information and publishes them for the Service User [38].

Fig. 8. Components of SOA.

SOA satisfies the requirements of different applications by balancing the computational resources. It virtualizes and integrates these resources in form of services entities. Therefore, the basic aspect of SOA is the “coupling” between different systems. Every system has information about the behavior and implementation of its partners. The information gathering procedure facilitates the coupling feature in SOA.

SOA eliminates the tight coupling and lack of interoperability between diverse middleware in a network. It has been endorsed by Cloud Computing (CC) services; Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). Fig. 9 elucidates SOA in CC environment. CC implements SOA in its different fields to exploit the resources’ virtualization feature. This in turn allows SOA to introduce Network as a Service (NaaS) into CC [7].

Fig. 9. SOA in cloud computing environment.

Summary

This chapter outlined Web services and service-oriented architectures. It showed the importance of a robust messaging format in the use of Web services. The chapter also highlighted the importance of the ongoing standardization of the various semantic vocabularies. The chapter ended with an explanation of service-oriented architectures.

Chapter 4 will weave the concepts of service-oriented architecture into a discussion of cloud computing.

2.1.2 Service-Oriented Architecture for IoT

Since IoT connects SOs of varying features, capacities and capabilities to each other over networks to facilitate provision of services in varied contexts, there is a great deal of heterogeneity involved. Service-Oriented Architecture (SOA) has been applied extensively for

Various researchers have proposed numerous solutions and architectures to integrate RFID, WSNs, IoT and applications [32–43]. New ideas have been proposed to create a multi-layered SOA for IoT [9]. Various three-layered [15,30,44] and four-layered architectures have been proposed for IoT [45]. But these architectures are domain dependent and not generic in nature. Domingo proposed a three-layer architecture for IoT applications to help persons with disabilities [44]. The three layers are: Perception layer, network layer and application layer as depicted in Fig. 10. Xu et al. have proposed a four-layered architecture for IoT based on functionalities [9]. The four layers are: Sensing layer, Networking layer, Service layer and Interface layer as shown in Fig. 11. The description of these layers is given in Fig. 12.

Fig. 9. IoT layers and protocols.