Olaf Zimmermann and his colleagues from IBM Research have developed last year an Architectural Decision Metamodel to facilitate Enterprise Application Development.
capturing architectural decisions remains a challenge for practicing architects. Reported inhibitors for capturing decisions include no appreciation from project sponsors, lack of time, and insufficient tool support
They propose a conceptual framework for three decision capturing steps:
- Decision identification - reality: decision identification [is] solely based on personal experience [and often] ad hoc
- Decision making - reality: decisions makers often are biased... They rely on past experiences ... [or] ... industry trends
- Decision enforcement - reality: coaching, architectural templates, and code reviews are the dominating decision enforcement approaches
By providing a structured, proactive approach to decision modeling, they aim at:
improv[ing] the quality of the decision making with decision dependency modeling, catalogs of decision drivers, and recommendations for decision making techniques
A couple of weeks ago, Cesare Pautasso, Olaf Zimmermann and Frank Leymann presented a paper at the WWW 2008 conference, held in Beijing, detailing a comparison of "RESTful Web Services vs. Big Web Services" providing insight to "Make the Right Architectural Decision".
First the authors review in great detail the perceived strength and weaknesses of each technology :Many different styles can be used to integrate enterprise applications. [This] choice... is a big architectural decision. The “Big” Web services technology stack (SOAP, WSDL, WS-Addressing, WS-ReliableMessaging, WSSecurity, etc.) delivers interoperability for both the Remote Procedure Call (RPC) and messaging integration styles. More recently, an alternative solution has been brought forward to implement remote procedure calls across theWeb: so-called RESTful Web services.
Key architectural decisions in distributed system design, such as the choice of integration style and technology, should be based on technical arguments and a fair comparison of concrete capabilities delivered by each alternative. Instead, the WS-* vs. REST debate has unfortunately degenerated into biased and religious arguments which create only confusion and expectations that cannot be fulfilled.
In this paper, [the authors] take a quantitative approach to compare the two integration styles technologies based on architectural principles and decisions.
SOAP and the WS-* Stack
In spite of their perceived complexity, the SOAP message format and the WSDL interface definition language have gained widespread adoption as the gateway technologies capable of delivering interoperability between heterogeneous middleware systems.
Paradoxically, the power delivered by current WS-* tooling that make it so easy to turn existing software components into Web services can also be misused. Thus, it is important to avoid leakage across abstraction levels. Interoperability problems can occur when, for instance, native data types and language constructs of the service implementation are present in its interface. This weakness can be mitigated by stating and enforcing certain design and coding guidelines such as contract-first development.
REST
RESTfulWeb services are perceived to be simple because REST leverages existing well-known W3C/IETF standards (HTTP, XML, URI, MIME) and the necessary infrastructure has already become pervasive...
Such lightweight infrastructure, where services can be built with minimal tooling, is inexpensive to acquire and thus has a very low barrier for adoption.
[However], There is some confusion regarding the commonly accepted best practices for building RESTfulWeb services.Hi-REST recommendations have been established informally, but are not always fully followed by so-called Lo-REST implementations...[in practice] only 2 verbs (GET for idempotent requests, and POST for everything else) are used... [because] proxies and firewalls may not always allow HTTP connections that use any other verb... restrictions have led to a series of workarounds, where the “real” verb is sent using either a special HTTP header (X-HTTP-Method-Override) or – like with Ruby on Rails – a hidden form field (−method). .
Then they establish a comparison method based on the Architecture Decisions framework. They used the literature to identify candidate decisions and alternatives. They developed several integration scenarios recording the architectural decisions when using REST and WS-*. They created one decision model for each integration style which allowed them to compare objectively the two models using metrics such as the number of decisions, the number of alternatives per decision...
The authors then went on to compare the principles, the concepts and the technology. Their findings include:
On the principle level, the two approaches have similar quantitative characteristics.
On the conceptual level, less architectural decisions must be made when deciding for WS-* Web services, but more alternatives are available.
On the technology level, the same number of decisions must be made, but less alternatives have to be considered when building RESTful Web services.
In particular, they authors have demonstrated that:
Thus, the perceived simplicity of REST now can be understood from a quantitative perspective
[However], according to our experience several of the decisions that are very easy to make for RESTful services lead to significant development efforts and technical risk, for example the design of the exact specification of the resources and their URI addressing scheme.
The authors conclude:
... use RESTful services for tactical, ad hoc integration over the Web (à la Mashup) and to prefer WS-* Web services in professional enterprise application integration scenarios with a longer lifespan and advanced QoS requirements.