Is it? After all what is the goal of architecture in an IT context? Surely its to represent what the business wants to achieve. Looking at the Wikipedia definition of Enterprise Architecture for instance it says
Enterprise Architecture is the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction.
And System Architecture goes down as
A system architecture or systems architecture is the design or set of relations between the parts of a system.
Now this is what I've always thought of as being architecture in an IT context. Even something very very techy like ADML describes software architecture as
A software architecture describes the structural properties of software, typically the components and their interrelationships, and guidelines about their use.
The key bit here is it describes the OPERATIONAL pieces (components and interactions) rather than the implementation mechanics.
Now I don't think this fits what REST is at all. REST deals with the implementation mechanics and the principles and practice of that implementation, it doesn't provide you with a style for the modelling of an architecture and its interactions, it provides you with a framework for its implementation.
In his presentation Roy uses the phrase "Architecture is trying to find the common design" before going to talk more about architectural style being more abstract that that. Now the issue here is that in architecture he talks about implementation protocols as being the key to the Web "architecture". REST then becomes one level above that talking not about the protocols but about the "style" of the Web. Now this really got me thinking. This is a long way away from what I mean when I talk about business architectures and it really is about implementation practice... then it dawned on me, this isn't an argument about architectural styles, in fact REST isn't an architectural style.
REST is a design pattern
In software engineering ,a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Now that to me sums up exactly what REST is, and how the Web is the implementation of the REST design pattern, and explains how the REST design pattern can be used to implement your projects and programmes. This doesn't make REST any more, or less, relevant to decisions but for me it explains the different between SOA, as a business driven concept, and REST as an implementation model for that approach. It is fair to say that Web Services has a lack of patterns and practice and that this is an area that should be addressed in terms of Web Service implementation patterns (and anti-patterns), but both REST and Web Services are fundamentally about technology and implementation.
Architecture needs to be about understanding the goals and objectives of the business problem being solved and about the effective modelling of that solution. This then needs to be translated into technology by creating a software architectures which are based, or constrained by, firm design patterns that ensure repeatability of solutions. Confusing the goals of architecture by making it focused on the technology implementation really doesn't help us bridge the gap between IT and the business, indeed it reinforces the gap by emphasising the IT focus as being on technology rather than on the business problems.
REST may well have a place within the implementation of an Enterprise or Solution Architecture, but we shouldn't confuse the goals of architecture (business problem) with patterns (IT implementation), and REST belongs firmly in the later.
Technorati Tags: SOA, Service Architecture
7 comments:
I don't think that REST is a design pattern - it is an architectural style.
I'll admit that the difference between architectural styles and design patterns is not that big but it is still there. For starters it is an additional level of abstraction (vs. design patterns). Also it builds upon architectural constructs (components, their relations and attributes of them). If you read Roy's dissertation you'd see how he defined REST in terms of other architectural styles like client-server, layers etc.
Arnon
Just because it claims to be an architectural style doesn't mean it actually is. Roy's definition, indeed his actual wording, of what REST is says that it is about the design of the implementation. This isn't architecture as it isn't about how you model a solution.
Client-Server isn't an architectural style either, its a poor design pattern. The key here is that architecture should be about the business solution whereas REST is about technology implementation.
I totally agree that an architecture is useless without a business context.
By architectural style I mean a pattern that can be used for the architectural modeling of a sytem. When you apply an architectural style (pattern) you need to look at the quality attributes it promises and match them with the quality attributes you seek within your problem.
The point I tried to make is that design patterns are not exactly the same as architectural ones
I didn't say client/server is a good option just that it is a style you can adopt in a solution just like REST is.
I don't think that REST is a technology implementation - even though a lot of REST proponents tie it to HTTP. A lot of people equate SOA with WS-* web-services that doesn't mean that that's what SOA is
But what is REST beyond an implementation pattern? It would be really useful to have something to point to that talks about modelling business problems using REST, rather than REST being just the implementation approach.
Where is the business REST view?
REST is a design pattern--Quote
REST seems to be an architectural style. I think there is no line written in stone yet about what constitutes an architectural style and a design pattern. That said, I like to think of architectural styles in terms of a collection [and combinations] of design patterns. And then to think of software systems in terms of a collection of architectural styles.
No offense, but this seems like a pretty useless debate to me. Who cares if it's an architectural style or design pattern? If it's useful to the problem you're trying to solve, then use it. Also kind of seems like you guys are talking past each other. There are multiple levels of architecture, e.g. enterprise arch, business arch, solution arch, system arch, etc. and it appears that you guys are arguing about it at different levels.
I can tell you what REST is inside the firewall - irrelevant
Eric Roch
Post a Comment