July 6, 2010

The primary goal of this tutorial to close the gap between the high-level concept of Service-Oriented Architecture (SOA), and the question of how to implement such an architecture once services have been identified. Colloquially, it is often assumed that services in a Web-oriented are implemented as Web services, and these are often exclusively perceived as using the SOAP stack of protocols. Our goal is to describe that Web services can also use other technologies, such as RESTful implementations on top of HTTP. Furthermore, we will explain how a disciplined process can lead from the business level, which is mainly about identifying services on an abstract level, to an IT architecture, and that it is important to not impose architectural constraints (such as defining service in a function-oriented way rather than in a resource-oriented way) too early in the process.

Web Services have been of increasing interest in the past years. While Web Services were first defined as machine-accessible services based on Web technologies, the term quickly was perceived as exclusively referring to SOAP-based services, which mirror the traditional IT integration style of distributed objects with messaging technologies layered on top of Web technologies. This tutorial focuses on an alternative approach towards the design and implementation of Web Services, based on the architectural style of the Web itself, Representational State Transfer (REST). Thus, the tutorial learning objectives specifically include giving an in-depth understanding on how the two different styles of Web Services compare, and why the decision of SOAP vs. REST is fundamental and needs to be made very early in any SOA project. We focus on the question of how to do SOA with REST, and do so by explaining and highlighting the fundamental differences between the more tightly coupledintegration style of distributed objects, and the more loosely coupledcooperation style of REST. Thus, attendees will gain a new perspective that highlights the importance of following Web principles to support the design of Web Services and learn why not all Web Services are made equal and that only RESTful ones are really of the Web, whereas others are just implemented on the Web.

Introduction:This introduction presents the schedule, the tutorial presenters, and some background for the tutorial. Specifically, we briefly mention all the *OA terms that have been invented in recent years, such as SOA (Services), ROA (Resources), WOA (Web), SynOA (Syndication), and EOA (Event), and set them into context. Our main goal is to explain our notion of SOA for the purpose of this tutorial, and what we perceive as the core tasks when moving from SOA to REST.

What is REST?:Representational State Transfer (REST) is defined as an architectural style, which means that it is not a concrete systems architecture, but instead a set of constraints that are applied when designing a systems architecture. We briefly discuss these constraints, but then focus on explaining how the Web is one such systems architecture that implements REST. In particular, the mechanisms of the Uniform Resource Identifiers (URIs), the Hypertext Transfer Protocol (HTTP), media types, and markup languages such as the Hypertext Markup Language (HTML) and the Extensible Markup Language (XML). We also introduce Atom and the Atom Publishing Protocol (AtomPub) as two established ways on how RESTful services are already provided and used on today's Web.

RESTful Service Design:REST is simple to define, but understanding how to apply it to design RESTful services is more difficult. The goal of this part of the tutorial is to present the main design elements of a RESTful architecture and introduce a design methodology for RESTful services. A selection of useful patterns and anti-patterns will be discussed with some examples that will be further developed in the practical part.

REST vs. WS-* Comparison:In this part we summarize the WS-* vs. REST debate by giving a quantitative technical comparison based on architectural principles and decisions. We show that the two approaches differ in the number of architectural decisions that must be made and in the number of available alternatives. This discrepancy between freedom-from-choice and freedom-of-choice explains the complexity difference perceived. However, we also show that there are significant differences in the consequences of certain decisions in terms of resulting development and maintenance costs. The comparison helps technical decision makers to assess the two technologies more objectively and select the one that best fits their needs: REST is well suited for basic, ad hoc integration scenarios, WS-* is more flexible and addresses advanced quality of service requirements commonly occurring in enterprise computing.

REST in Practice:REST's level of abstraction and its simplicity as a small set of constraints can make it hard to get a grasp on how it can be applied for real-world projects. This presentations introduces real-world REST by looking at how REST can be used by reusing existing RESTful designs in terms of representations and interaction protocols; Atom and the Atom Publishing Protocol (AtomPub) are used as examples for existing RESTful designs. In addition, we take a brief look at how to go beyond using these canned REST approaches, and how existing programming framework provide support for designing and implementing RESTful services.