Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Boris Lublinsky on Sep 23, 2009
JBoss has formally announced a new REST-* initiative during JBoss World at the beginning of the month.
REST-* is trying to clearly separate itself from WS-* by pointing the following differentiators:
WS-* is an excellent set of specifications defining various protocols and envelope formats for implementing middleware services over a network. While a vast improvement over CORBA it does suffer from a few disadvantages that the REST-* community hopes to fix, mainly:
WS-* doesn't leverage HTTP WS-* uses HTTP as a transport protocol. WS-* services mainly use HTTP as a connection setup mechanism and ignore the rich and proven features that make the Web so successful... Because we are focusing on RESTful principles the specifications put out by this organization will fully leverage the HTTP protocol and not try to re-invent its technology
WS-* has a high barrier to entry The WS-* stack is hard to implement and requires a complex stack on both the client and server to use... We hope to minimize the barrier to entry in our suite of specifications.
WS-* requires an envelope format The WS-* stack requires SOAP, an envelope format for WS-* sent message... The HTTP message format is good enough. It is simple, robust, and flexible enough.
The architectural goals of this initiative are:
Low barrier to entry Clients that use the specification should have a very low barrier to entry. They shouldn't need to install a library or large stack of software to use a specification...
Edge Cases should be Extensions Edge cases that complicate the main specification should be defined in a separate sub-specification. Extensions should strive to be layered on top of the main specification.
Pragmatic REST While a specification should strive to follow RESTful principles, simplicity should never take a back seat to being a pure RESTafarian. If you need to bend the rules of REST to create a simpler design, then that's the path that should be taken.
80/20 Rule Specifications should remain simple... Specifications should cover 80% of the most common use cases. Edge cases should not be in the main specifications...
Avoid Envelope formats Whenever possible, avoid envelope formats... Envelope formats encourage tunneling over HTTP instead of leveraging HTTP... In most cases HTTP headers should be enough to transfer metadata about the request, response, or resource.
Isolate data formats to extensions If possible, specifications should try not to define new data formats.
According to the announcement, JBoss is attempting to create a fully collaborative community, similar to JBoss.org, not something driven by vendors for vendors. They are envisioning an open source approach to:
... defining new protocols... but one of the main points about this whole effort is to document guidelines and best practices for doing things in a RESTful manner (both with and without HTTP). That might include security, management, etc.
(By the way, the above quote from Mark Little already contradicts with the architectural goals mentioned before, by hinting to both new protocols and non HTTP support).
According to Mark:
If the only thing we end up being is an aggregator for links to "standard" ways of accomplishing this or that then that's a successful outcome too... this was started: because our community wanted it. They kept running up against the same questions and lack of clear answers from various sources such as books, experts in this space and other resources. In some cases they'd get many different answers. Does that mean the answers don't exist? No. But if people who really understand REST can't agree on something then what hope is there for those who just want to go and use it? That's what REST-* is about: bringing together communities to try to come up with clear guidelines so that there's a place for everyone to go when they need those answers.
Although this new initiative is trying to stay away from REST vs WS debate:
The benefits of REST over WS-* has been debated across many articles, blogs, and public mail lists. We don't want to rehash all of it here. Please do a Google search on "REST vs. WS-*" if you want more information.
It effectively does so, by making some (not completely founded) references to WS* features. For example, it tries to say that WS* is heavy, while REST is a light-weight. Well, both standards can be implemented "by hand", in which case (assuming HTTP transport) both require about the same amount of code. On another hand, if a runtime support for automatic marshalling/unmarshalling and message routing is used, the amount of code is also about the same (for example, RestEasy - which is a very nice framework - distribution contains 38 jars). If the comparison is done for the same level of abstraction, the amount of required code is about the same. And the list goes on.
So, it comes as no surprise that the REST* announcement caused quite a few replies on Internet. Steve Jones’s post - REST-* can you please grow up - sums it up quite well:
The REST-* effort might end up documenting what already exists which indicates that part of the challenge is that lots of people don't really know what REST is and certainly struggle as they look to build higher class systems and interoperate between organizations. Part of this is of course about up-front contracts and the early vs. late validation questions. But part of it also appears to be pure snobbery and a desire to retain arcane knowledge.
He continues by stating that:
If REST really is some sword of Damocles that can cut through the integration challenges of enterprises and the world then what is the problem with documenting how it does this and having a few standards that make it much clearer how people should be developing. Most importantly so people (SAP and Oracle for instance) can create REST interfaces in a standardized way that can be simply consumed by other vendors solutions. It can decide whether WADL is required and whether Atom and AtomPub really cover all of the enterprise scenarios or at least all of the ones that count (i.e. lets not have a REST-TX to match the abomination of WS-TX).
Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
Any article on REST-* that does not include Roy T. Fielding's comments is woefully incomplete, IMO ;)Quite frankly, this is the single dumbest attempt at one-sided "standardization" of anti-REST architecture that I have ever seen. It even manages to one-up the previous all-time-idiocy of IBM when they renamed their CORBA toolkit "Web Services" in a deliberate attempt to confuse customers into thinking they
had something to do with the Web.
tech.groups.yahoo.com/group/rest-discuss/messag...
These folks don't get it. This is a huge step in the wrong direction. Like Roy said: Just close the stupid site down.
<blokquote>Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.</blokquote> Thank you Boris, IMHO, even Roy would benefit reflecting on your conclusion. REST or even REST-* is not and cannot be made equivalent to WS-* (and vice versa, of course).
Can we finally agree that the word "service" is as, if not more important, then "Web"
@Boris: No. I'm afraid that would be a mistake.
This seems misguided. Why screw with something good. The challenges people hit with REST is that it doesn't try and do everything, that is a good thing. The approach fits very well for many web applications but not all. Can we just help people identify when to use REST or Web Services?
BTW looking at the goals (www.jboss.org/reststar/overview/goals.html) isn't that what REST has achieved already?
Cheers,
Ross
One aspect of WS-* that I felt made sense is that the specs were developed in some vendor neutral organizations, W3C and OASIS. This sounds like spec development by a single vendor, would Microsoft be contributing as they did in WS-*? How about Oracle?
I'm not sure on the debate as to whether this makes sense at all but I would think that these types of specs should be developed in a neutral fashion.
Nooooo, not yet another standards body for something so useful and elegant as REST... I'm glad Roy voiced his opinion... REST is just an interpretation of how to use HTTP in an effective way to do more than just send HTML documents across the wire. That's what it's good at and it should stay that way.
OTOH, who am I, not having touched an IDE for three months ;-).
+1 :-)
Thank you Boris, IMHO, even Roy would benefit reflecting on your conclusion. REST or even REST-* is not and cannot be made equivalent to WS-* (and vice versa, of course).
Very true. On that same token, the usage characteristics of RESTful services is very different from WS-* services and REST-* may not really be suitable for the characteristics that we expect to see in the "web".
There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.
@Boris, I see your point, but I believe we should come at it from the other way. I would instead try to see if we can incorporate the goals of REST-* to the already created WS-* stack so that the whole WS-* stack can gracefully degrade to a RESTful stack given the architectural criteria.
Can we finally agree that the word "service" is as, if not more important, then "Web"
What does this even mean? important for what and for whom?
What are we trying to do?
Servicize or Webify our applications? Are we trying to decouple existing stovepipes or just use Web as communication protocol?
It seems strange that this was announced without reference to the reams of traffic that the original proposal stirred up, especially Roy's comments on the subject.
In summary, it's a horrible idea, suggested by those who actually don't really grasp what REST is all about, and think that as long as you stick everything across an HTTP interface, then it's all good. But this really takes stupidity into whole new leagues; for whilst there are some who thing a GETSful architecture is in fact a RESTful one, this promises to bring the clarity and succinctness of WS-* to an otherwise sane architectural style.
Not for nothing has this proposal been suggested as DIRT-*, since it's basically a way of avoiding SOAP.
Alex, if you look then you should find that those involved in this do "grasp what REST is all about" and Bill's approach is not to try to duplicate WS-* with REST (whether or not using HTTP). As he keeps saying, and some seem all too willing to ignore, this should be a wide community effort. So if you "grasp what REST is all about" and care enough for the wider REST audience (not just those who clearly do "grasp what REST is all about" but those who are still struggling with concepts and Q&A) to ensure that it doesn't "bring the clarify and succinctness of WS-* to an otherwise sane architectural style" then get involved. Last time I looked it was free to join and participate. I'm sure your (and others) constructive input would be greatly appreciated.
Hi John. Bill's made a few changes since the initial release of the site and blogged about them:
reststar.wordpress.com/2009/09/18/were-listenin...
and
reststar.wordpress.com/2009/09/23/we-screwed-up...
I think your point is addressed with the IETF reference.
The similarity between REST-* (called rest star?) and WS-* (known as W S deathstar) make me wonder if Darth Vader is behind this crap too.
REST is fine the way it is, please don't f#@! with it.
I'm going to be fixing the language around this. What I mean by this is that to fit under the 80/20 rule, we want media types of the core specs to be very simple. Edge cases or extension protocols should be defined in new media types and link relationships.
Believe it or not I appreciated Roy's (and other's) bluntness. I just hope these rants are more of "Get your act together!" rather than just turning your back on us. If you've read the rest-star blog You'll see we recognized our initial screw ups and that we are working to improve things on all levels: technical, website, direction, message.
The point is, this was an announcement of a launch of an effort not of a final product. We're not perfect. We will make mistakes. We don't want to do this alone.
@Dilip@Boris, I see your point, but I believe we should come at it from the other way. I would instead try to see if we can incorporate the goals of REST-* to the already created WS-* stack so that the whole WS-* stack can gracefully degrade to a RESTful stack given the architectural criteria.
What I think can be gathered from WS-* specs and open source and commercial middleware is requirements and use cases.
Thanks Mark. I think this makes good sense. I also like the open source project as it allows us individuals the opportunity to participate.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
20 comments
Watch Thread Reply