Abstract
Current integration solutions are still based on technologies developed for the original Web problem, which is browsing remote hypermedia documents with text as the main media type. Text-based data descriptions such as XML and JSON and stateless and connectionless protocols such as HTTP are still the norm to achieve distributed integration. However, the Web today is much more dynamic, in that resources are no longer passive hypermedia documents but are active and implement services. SOA and REST are the most used architectural styles to implement distributed integration, and each exhibits advantages and disadvantages. This chapter illustrates that they are dual architectural styles—one oriented towards behavior and the other towards state—and contends that it is possible to combine them to maximize the advantages and to minimize the disadvantages. A new architectural style, designated Structural Services, is proposed and described. Unlike REST, resources are able to offer a variable set of operations, and unlike SOA, services are allowed to have structure. To minimize resource coupling, this style uses structural interoperability based on the concepts of structural compliance and conformance, instead of schema sharing (as in SOA) or standardized and previously agreed upon media types (as in REST). To delineate how this style can be implemented, a new distributed programming language is presented.
TopIntroduction
The main integration technologies available today are based on the SOA (Erl, 2005) and REST (Webber, Parastatidis, & Robinson, 2010) architectural styles, with SOAP Web services (WS) and HTTP RESTful services as the main workhorses. They constitute two different approaches to solve the same problem: application integration. SOA has the goal of a low semantic gap, since it models real world entities by resources with services that express their capabilities. This is good in modeling terms, but entails a coupling between the provider and the consumer that hampers dynamic changeability and adaptability. If the provider’s interface changes, the consumer’s interface also needs to change in accordance. There is no apparent structure, since service composition is hidden behind each service interface.
One of the main goals of REST is to reduce the coupling between provider and consumer, both to increase scalability and adaptability. Real world entities are modeled in a data-oriented manner by resources, all with the same syntactical interface (same set of operations). Semantics are restricted to a set of data types (or schemas), either standardized or previously agreed upon between the interacting entities. The variability of the characteristics of entities is modeled by visible structure (resources composed of other resources) and the semantics of the agreed data types.
Unfortunately, the decoupling goal of REST is somewhat elusive. Messages cannot be understood simply by exploring their data structure, touching links blindly. Semantics and behavior need to be considered as well, and this is determined by the type of resources used. For example, if the provider decides to change its specifications, the code at the consumer will most likely be unable to cope with that.
What happens in practice is that REST on HTTP is simpler to use than SOA style SOAP Web services and many applications are simple enough to adopt a data-oriented interface i.e., REST style. This means that, although REST represents a modeling shift from real world entities (lowering the modeling level and increasing the semantic gap), it is still simpler to use than a full-blown SOA environment. Unless, of course, the application is sufficiently complex to make the semantic gap visible and relevant enough. This is why REST is preferable in simpler applications and SOA is a better match for complex, enterprise-level applications.
Nevertheless, REST gets one aspect right: in a distributed context, interoperability has to be based on structural composition of previously known entities. Forcing these to have one single set of operations, however, does not increase adaptability in the general sense; it only leads applications to adopt a data-oriented style, which is not adequate for all classes of applications.
The following questions then arise:
- •
Why do we have to choose between the service-oriented (SOA) and data-oriented (REST) styles, instead of combining both and using the best approach for each part of the application?
- •
How can we increase adaptability without enforcing some particular application style?
This chapter revisits the integration problem with an open mind, without being restricted a priori by existing technologies. The only assumption is that there are entities that need to interact, by using messages. Then, an integration model is defined and its various characteristics compared with those of current technologies, showing how this model can solve some of their limitations.
The main goal of this chapter is to propose and describe a new architectural style, designated Structural Services, which combines the best characteristics of the SOA and REST styles. On the one hand, services have a user defined interface which can be published, discovered and used. On the other hand, services are implemented by resources, which have structure (composed of other resources). Operations are first class resources and messages are themselves resources, able to include references to other resources. As a result, applications can be designed in SOA or REST styles, according to the needs of the application.
Key Terms in this Chapter
Compliance: An asymmetric property between a consumer C and a provider P ( C is compliant with P ) that indicates that C satisfies all the requirements of P in terms of accepting requests.
Architectural Style: A set of constraints on the concepts of an architecture and their relationships.
Service: The set of operations supported by a resource and that together define its behavior (the set of reactions to messages that the resource exhibits).
Conformance: An asymmetric property between a provider P and a consumer C ( P conforms to C ) that indicates that P fulfills all the expectations of C in terms of the effect caused by its requests.
Resource: An entity of any nature (material, virtual, conceptual, noun, action, and so on) that embodies a meaningful, complete, and discrete concept, makes sense by itself, and can be distinguished from although able to interact with other entities.
Consumer: A role performed by a resource A in an interaction with another B , which involves making a request to B and typically waiting for a response.
Interoperability: An asymmetric property between a consumer C and a provider P ( C is compatible with P ) that holds if C is compliant with P and P is conformant to C .