8 TECHNOLOGY VIEWPOINT
8.3 T ECHNOLOGY OPTIONS FOR SERVICES
The present version of the technology viewpoint assumes that the implementation of LifeWatch services will be based on web services technologies where “web services” are meant as an abstraction and do not refer to a particular technology e.g. the so called Big Web Services or WS-* standards. The W3C defini-tion of Web Service can be relaxed by suppressing the technology aspects, since they are, in LifeWatch terms, platform specifications on descriptions, interfaces, and schema languages.
The LifeWatch Reference Model will use the following modification of the W3C definition of web ser-vices “a software system designed to support interoperable machine-to-machine interaction over a net-work. It has an interface described in a machine-processible format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”139 The W3C technical report Web Service Architecture140 presents four models that focus on different as-pects of the architecture: the message oriented model, the service oriented model, the resource oriented model, and the policy-oriented model. These models not only focus on different aspects but define differ-ent design paradigms for modelling of application compondiffer-ents and information schemas. This holds in particular for Message Oriented Architectures (MOA), Service Oriented Architectures (SOA), and Re-source-Oriented-Architectures (ROA).
139 W3C definition of Web Services (without the crossed out parts) available at http://www.w3.org/TR/ws-gloss/
140 W3C (2004): Web Services Architecture, W3C Working Group Note 11 February 2004, available at http://www.w3.org/TR/ws-arch/ (November 2009)
Figure 46 Simplified models used on web services design, according to W3C141
8.3.1 Message Oriented Architecture (MOA)
MOA focus on asynchronous interaction for loosely coupled and scalable “event-driven” systems. The design models the data dissemination as sequences of “messages” passing among message handlers, without relating a service to a particular service. Figure 46 a) shows a simplified model of the concepts used on a message oriented model according to W3C: an agent (computational resource) sends and re-ceives messages structured in terms of message headers and bodies over a delivery mechanism (message transport). Ubiquitous computing and sensor technologies are examples of systems relying on MOA. Also the software architecture pattern Event-driven architecture (EDA) is based on MOA.
8.3.2 Service Oriented Architecture (SOA)
Classical SOA is based on services executing actions (operations). Therefore, also the term activity-oriented may be applied for this type of architecture. A service interface hides the data structure behind the actions and offers only operations, each of one executing one of the activities or actions that can be performed. Figure 46 b) shows the concepts of the W3C simplified model: an agent, also called service provider realizes services that are used by another agent, called service consumer. Services are mediated by means of message exchanges and are described through data. The use of (standardized) meta-data is a key for the successfully deployment, discovery, and access of services. SOAP is a protocol for service-oriented architectures using HTTP as transport mechanism, tunnelling all messages in envelopes sent using HTTP-Post requests. SOAP and the W3C Web-Service protocol stack (also called Big Services or WS-*) together with RPC-styled service architectures are the predominant examples of the SOA archi-tecture paradigm.
8.3.3 Resource Oriented Architecture (ROA)
ROA has its origins in a specific set of architectural constraints named REST or Representational State Transfer by Roy Thomas Fielding142. REST exemplifies how the web’s design emerged. REST-based architectures basic concepts is the transfer of representation of resources, that is, according to W3C, “any-thing that can have an identifier” and are relevant to web services. Figure 46 c) shows the simplified W3C model of ROA that focuses on resources being identified through an URI and having none, one, or many
141 Images adapted from: W3C (2004): Web Services Architecture, http://www.w3.org/TR/ws-arch/ (November 2009) 142 Fielding, R., T., Architectural Styles and the Design of Network-based Software Architectures, Ph.D. Thesis, University of
California, Irvine, Irvine, California, 2000.
b) Service oriented model c) Resource oriented model
service
representations and an owner143. An important component missing in the model is the link concept repre-senting relationships between resources. The term ROA is used to describe architectures for web services based on the REST principles, also called RESTful architectures144 and the distinguishing properties are addressability, connectedness, and the uniform interface more attached to database-oriented operations.
ROA, in contrast to SOA, uses HTTP as message protocol and not just as transport mechanism. The “Sta-tus Report on Infrastructures for Biodiversity Research” (Deliverable 5.1.2), Appendix B, provides addi-tional material on comparing SOA and ROA.
While the engineering viewpoint provides the concepts and guidelines for the architectural design of LifeWatch applications based on SOA it is worth to keep in mind that technological decisions may influ-ence the design of application schemas. To illustrate Figure 47 represents two design examples (SOA and ROA) for the ORCHESTRA architectural service User Management Service that controls the setup of user structures in order to be used by the authentication and authorisation mechanisms. The schema shown in a) matches the SOA-view as described by the ORCHESTRA-Reference Model145 and in b) a ROA-design is presented.
The SOA model (a) has just one interface, and thus one address to with client can call a long set of opera-tions. Looking more detailed to the operations, they are restricted to creation, read, update and delete operations, often called C.R.U.D. operations, on different data types (subjects, groups, and principals), which are passed as parameters for the operations. In contrast, the ROA model (b) identifies the key re-sources and apply a set or subset of operations as defined by the resource interface, which are few, name-ly get, put, post, and delete. Clients can access each resource using a unique address (URI), for example using HTTP get on http://{service_base_URL}/subject/JohnDoe returns the entries for a subject with the ID JohnDoe. On a SOAP implementation of the SOA model the operations are mostly146 performed using the HTTP-POST operation and hiding the semantic of the query and the data types in an envelope. The ROA implementation would use HTTP-POST just for adding children to a resource, e.g. using POST on subjects creates a subject and returns an URI that can be used to update or delete the specific subject us-ing HTTP-PUT and HTTP-DELETE on the URI respectively147.
143 The WRC Web Service Architecture expands the definition of resource specified in the Web Architecture document (W3C, 2004: Architecture of the World Wide Web, Recommendation 15 December 2004, http://www.w3.org/TR/webarch/) by incorporating the relationship between resources and owners.
144 The term Resource Oriented Architecture (ROA) was formulated in Richardson, Leonard; Sam Ruby (May 2007). RESTful Web Services. O'Reilly.
145 The interface ServiceCapabilities was omitted in the representation 146 Since SOAP 1.2 also the operator HTTP-GET is supported
147 A detailed discussion about SOA versus ROA is given in the “Report on Infrastructures for Biodiversity Research” (Deliver-able 5.1.2), Appendix B
Figure 47: Warehouse application design as SOA (a) and ROA (b)