Questions for an Enterprise Architect
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
A Fair Comparison of REST and WS-* using an Architectural Decision Framework: is the Debate Over?
Posted by Jean-Jacques Dubray on May 06, 2008
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Not sure about "fair"
by
Stefan Tilkov
Posted
Is protocol transperancy real?
by
Subbu Allamaraju
Posted
Re: Is protocol transperancy real?
by
Jean-Jacques Dubray
Posted
Useless
by
Mark Baker
Posted
-
While the authors understand much more about REST (and obviously WS-*) than many other people participating in this discussion, it seems to me that advantages exaggerated while the disadvantages are played down, and vice versa. There are still some misunderstandings, such as the mixup of PUT and POST; the neglecting of hypermedia; the unmentioned fact that XSD (as opposed to WSDL) is available when doing REST, too; and many more. I can't see a single new point that would highlight a WS-* benefit that wasn't mentioned a million times before.
So in the end: no, the debate is not over – assuming anyone still cares to have it. -
- - I would love to see some data saying what percentage of SOAP/WS is over HTTP vs other "transports". This paper says that the "protocl transparency" is a good thing, but does not completely analyze the merits.
- - Yes, SOAP header is extensible, but as far as encryption is concerned, due to canonicalization, the idea is fundamentally flawed. XML is the wrong format to sign/encrypt against.
- - REST is not CRUD. The idea that the "fixed set" is PUT, GET, POST and DELETE is incorrect, as Roy himself said in tech.groups.yahoo.com/group/rest-discuss/messag.... Most of the discussion this paper about stuffing everything into these four verbs is misleading
- - The reference to UDDI in Table 3 is technically inaccurate. UDDI is not tied to SOAP/WSDL, although it is usually used for SOAP/WSDL based services. I still would not recommend UDDI though as a registry for RESTful services :)
- - This paper repeats the same mistake of calling HTTP a "transport protocol".
- - "RESTful web service capable of serving resources in multiple representation formats requires more maintenance effort" - so, don't support multiple representations if you don't have to!
Does this paper prove that one is better than the other? I don't even want to go there! These are two distinct styles, pick something that works for a given problem.
-
Wow, what an awful paper. They should have been evaluating the architectural styles rather than evaluating the current state of the art of the technologies associated with each approach. It's that mistake which leads them to entirely the wrong conclusion when they write "On the conceptual level, less architectural decisions must be made when deciding for WS-* Web services [...]".
I find it surprising that Frank has his name on this because I've appreciated his work for years. -
Subbu:
I am not sure the paper aimed at identifying a winner. I also would like to emphasize that the paper defined a context for the analysis: "Many different styles can be used to integrate enterprise applications.", REST can used well beyond this limited context.
Not to revive an old debate and after reading carefully Roy's post, I'd be curious to understand your final position on:
"REST is not CRUD. The idea that the "fixed set" is PUT, GET, POST and DELETE is incorrect"
I was under the impression that the REST community was indeed arguing for limiting the use of POST, possibly eliminating it.
I would also be curious to see a longer explanation on how Roy's post can be interpreted when the client is not operated by a "human", i.e. in server(as a client) to server scenarios. It still seems to me that a "uniform interface" introduces tremendous levels of coupling in this scenario, as the client code has no other option than being hard wired to various actions embedded in resource representations. After all, REST does not have any assembly mechanism that would enable a client to be configured to inter-act with a particular resource representation type.
4 comments
Watch Thread Reply