Architectural Styles and Technologies

Despite heated debates on the technical merits of the different styles for imple- menting service-oriented software, there is no consensus on a one-size-fits-all style. Instead, it can be said that the different technologies are suited for different kinds of application scenarios [97]. Initially, the concepts of SOC and SOA were strongly related to their by then primary implementation technology: Web Services [15]. The importance of Web Services technologies is reclining today in favor of RESTful services [16]. Recently, also microservices [17, 103] have been coined as the next evolutionary step in SOC. Any of these styles can be used to implement applications that are described in a uniform, platform-independent, and technology-neutral manner, that interact via message exchanges, and that are transparent with respect to their location, i. e., services. Furthermore, all styles are meant to build services that can easily be composed [103, p. 7]. In a SOA, services implemented in different styles can also be combined with each other.

The software applications we analyze in this thesis use at least one of the different styles as the primary means for implementing distributed interactions. In some cases, in particular for BPEL [27], the usage of Web Service technologies [15] is required. In other cases, in particular for BPMN [26], the choice of the service- oriented style is left open. We give an overview over the technologies and principles underlying the different prevalent styles in the following subsections.

2.1.2.1. Web Services

Web Services advertise the utilization of Internet-related standards for the imple- mentation of a SOA [90]. The primary use case for Web Services are integration scenarios that require the interoperation of heterogeneous systems [97]. Such sce- narios are common in the Business-to-Business integration (B2Bi) domain [104].

WSDL and SOAP Web Services are promoted by the World Wide Web Consortium (W3C) and are based on a vast set of international standards. The Web Services architecture white paper defines a Web service as a “software system designed to support interoperable machine-to-machine interaction over a network ” [90, p. 7]. This definition reflects the target application scenario of integrating heterogeneous systems. The core standards for implementing Web Services are the Web Service Description Language (WSDL) [105, 106] and SOAP [107, 108]. WSDL is the language in which interface definitions for services are written and SOAP defines the message format used for interaction. The newest revision of WSDL, version 2.0 [106], is rarely used in practice and the older version 1.1 [105] is much more common. The systems we use here utilize version 1.1 and it is unclear whether version 2.0 will ever receive widespread adoption. All Web Services standards make heavy use of Extensible Markup Language (XML) [109] to guarantee technological neutrality and platform independence. Even interface definitions in WSDL are written in XML.

Figure 2.3.: Structure of a Web Service Definition

Structure of interfaces The uniform structure of a Web service definition [105] is depicted in Fig. 2.3.

A WSDL interface definition starts with a definitions element. It first lists imports of necessary files such as XML Schema Definition (XSD) [110] types that serve as parts of messages, which the Web service sends and receives. The actual messages are defined in the types and messages elements. The central interface definition part is the portType which corresponds to a cohesive set of the operations a service offers. Each operation may define input, output, and fault messages as parameters and return values of an invocation of the service operation. Thereafter, a binding element maps each operation to a transport protocol and message format, i. e., a particular version of SOAP, with which messages are transmitted. Finally, a service element lists one or more ports, which are endpoints with a concrete address under which a service provider can be reached. The distinction between the portType of a service and its port ensures location transparency. To communicate with a service provider, a requester has

to build a SOAP message, consisting of a header and body. The body contains one of the messages specified in the WSDL definition that is referenced as the input of one of the operations of the service. The transport protocol with which the message is transmitted depends on the binding of the service. Most frequently, the Hypertext Transfer Protocol (HTTP) [111] is used for message transmission. If it is specified in the service operation, the service provider may reply with a SOAP message that contains on output message in its body or a fault.

WS-*

standards The Web Services ecosystem encompasses many more standards that are used to specify and implement various quality of service attributes for the pro- vided functionality or interaction. These standards are called WS-* standards. Examples of such standards are WS-Security [112] for specifying message en- cryption, WS-ReliableMessaging [113] for implementing reliable interactions, or WS-Agreement [114] for enabling agreement negotiation among services. The usage of WS-* standards can be enabled by attaching policy specifications [115] to a WSDL definition. WS-* standards have been criticized for their complexity [97], but many of the features enabled through these standards are mandatory in enterprise-level interactions. A prerequisite for the usage of WS-* standards is mutual support for these standards by the execution environments of a service provider and requester. However, studies show that interoperability among different WS-* implementations is poor [116]. In this work, we concentrate on the functional portability of an application and abstract from the portability of additional quality of service requirements. Hence, we refrain from the usage or evaluation of WS-* standards, as far as this is possible.

2.1.2.2. RESTful Services

The perceived complexity of Web Services technologies has lead to a focus on more simplistic types of interaction and to the rise of RESTful services2 [117]. RESTful services are services that follow the REST architectural style [16, Chap. 5]. Similar to Web Services, RESTful services utilize common Internet technologies, in particular HTTP, to enable interoperable machine-to-machine communication over a network, albeit in a more minimalistic fashion [118]. The REST architectural style tries to mimic the design principles of the Internet for constructing the architecture of a distributed application based on interacting services. Due to their perceived simplicity, RESTful services are predominantly used for building service-oriented software today, to the disadvantage of Web Services technologies.

REST

principles RESTful services are centered around a uniform, technology-neutral inter- face [16, Chap. 5]. The constitutional constraints for such an interface are [117]:

1. the identification of resources,

2. their manipulation through resource representations, 3. self-descriptive messages, and

4. Hypermedia as the engine of application state (HATEOAS).

2_{The terms REST service and RESTful service are both common in practice to denote the} same entity. In this thesis, we use the term RESTful service.

These constraints are typically implemented with standard Internet technologies: Resources are identified through Uniform Resource Identifiers (URIs) and repre- sented in a technology-neutral format, such as XML, HTML, or the JavaScript Object Notation (JSON) [118]. Especially the latter one is preferred today. Resources can be manipulated by transmitting messages in the required represen- tation to the service provider. The universally accepted transport protocol for performing this transmission is HTTP. In contrast to Web Services technologies, different protocols, such as the Simple Mail Transfer Protocol (SMTP) [119] are not considered. Due to the strong ties to HTTP, certain HTTP verbs, in particular GET, PUT, POST, and DELETE, are used to transmit resource representations [118]. POST is used to create a resource, GET to read its representation, PUT to update the state of the resource, and DELETE to re- move it. The verbs, in combination with URIs and resource representations, constitute the uniform, technologically-neutral interface of a RESTful service. The last constraint, HATEOAS, requires that state transitions for resources, i. e., operations available for a resource, are determined dynamically by the provider in the form of hyperlinks encoded in resource representations. This means that the state of a resource is not explicitly maintained by the provider or requester, but encoded into the representation of a resource.

RESTful service interac- tion Based on these constraints, a RESTful service is identified by a base URI, which marks the initial access point for a service requester to the service provider [118]. A service requester can invoke operations on the service via standard HTTP verbs and transfer resource representations via formats such as JSON. By following hyperlinks from the base URI, the requester can discover further resources provided by the service and can invoke state transitions on these resources, i. e., it can trigger the execution of operations by the service provider. Note that an explicit interface description for a RESTful service, similar to a WSDL definition, is uncommon in practice. Nevertheless, specific languages for this task do exist, such as the Web Application Description Language (WADL) [120]. Also WSDL 2.0 [106] could be used for this purpose.

REST and quality of service The profound success and industry adoption of RESTful services can be attributed to the fact that the technologies used for their implementation are well-known, ubiquitous, and largely interoperable in heterogeneous systems [117]. However, RESTful services lack most of the advanced features provided by WS-* standards. For example, point-to-point encryption can be achieved by using the Hypertext Transfer Protocol Secure (HTTPS) [121], but there is no standard way of achieving end-to-end encryption as for WS-Security [97]. Due to such functional limitations, RESTful services are necessarily more simplistic, but also more interoperable. As before, the focus of this thesis resides on the portability of application functionality, therefore more advanced quality of service features are not discussed further.

2.1.2.3. Microservices

The most recent evolutionary step of SOC are microservices [17, 103]. Currently, the microservices architecture is still in the definition phase and not all aspects

are fully specified. Lewis and Fowler [17] advocate the microservice architecture as a form of fine grained SOA. Also other sources state that microservices can be seen “as a specific approach for SOA” [103, p. 9]. As discussed in the previous sections, the main difference between Web Services and RESTful services is the way in which service interfaces are defined and messages are exchanged between provider and requester. The microservices architecture does not propose yet another way for addressing these aspects, but reuses the concepts of REST for providing uniform and technology-neutral interfaces and exchanging messages. Instead, it puts more emphasis on the isolated deployment, autonomy, and self- containedness of services [103, Chap. 1]. As a result, technological heterogeneity, platform independence, composability, and easier replacement are crucial benefits of microservices.

Figure 2.4.: Monolithic Architecture versus Microservices Architecture

Container isolation

The key differences brought by a microservice architecture [17] are depicted in Fig. 2.4. The figure contrasts two different architectures consisting of three ser- vices, A, B, and C, and their execution environments. In both of the architectures in Fig. 2.4, the different services look independent from the service requester point of view. In the left-hand case, these services are hosted in a single container and are linked to each other via shared dependencies, which is not visible from the outside. They might even be provided by the same operating system process. This forms a monolithic architecture, due to the shared environment. In contrast, in the right-hand case, each service is hosted in a separate container. Each container might also be a completely different software product. As a result, there is a higher degree of isolation and location transparency among the different services. The failure of one of the services has no influence on the behavior of the others, which can occur in the case of a monolithic architecture. This strong focus on deployment-related aspects and restrictions on private inter-service relationships is what makes microservices different when compared with Web Services or REST.

Drivers for micro- service adoption The advent of microservices can be attributed to the arrival of techniques for

easier management and provisioning of scalable execution environments, i. e., cloud computing platforms [103, Chap. 1]. Container technologies, such as Docker, enable the relatively simple and fast construction of isolated containers for a single service [122, 123]. Another principle mandated by the microservices architecture is of organisational nature: All lifecycle aspects of a single service, including development and operations, should be performed by a single small-scale team [17]. This is in line with a common agile software development practice, the DevOps movement [124], and also the practices of continuous integration [103, Chap. 6]. In summary, it can be said that the microservices architecture is a form of SOA that is orthogonal to the Web Services or REST architectural paradigms.