One point that Anne made which still doesn't get a lot of press is
the difference between Resource Oriented Architecture and Service
Oriented Architecture. In a companion article, it was called out
that REST is about the nouns, where SOA is about the verbs. This is
part that I think needs some honest debate. Is a resource oriented
view of the world going to be better than a service oriented view?
Many people keep associating REST with SOA, but I think that's an
inaccurate portrayal. The people I've spoken with have been doing
POX over HTTP, which is not REST, and I'd argue that there are some
very big differences.
-tb
On May 30, 2007, at 1:34 PM, ash galal wrote:
This is a very good article, but the problem with REST in the
machine-to-machine interactions. Till now, I did not see anything
about such interactions in any REST articles, seminars, or books.
REST is very good concept for B2C but I couldn't find any
justifications for B2B.
If someone have such justifications or examples about B2B in REST,
please publish it here.
Thank you
Ashraf Galal
Gervas Douglas <[EMAIL PROTECTED]> wrote:
I have a vague feeling that the subject of REST has arisen before in
this Group.....
<<If you are an architect or developer working on service-oriented
architecture (SOA) projects, you probably are not doing
representational state transfer (REST) now, but within the next five
years you probably will be.
That is how Burton Group Inc. analysts answered their own rhetorical
question – REST: Is it the next big thing? – with a resounding yes at
a Web conference on Tuesday. Repeating the mantra "The Web is REST.
REST is the Web," Anne Thomas Manes, vice president and research
director at Burton, said the only thing new about REST is that it is
starting to catch on with SOA tool vendors and the open source
community as well as architects and developers.
"REST is not new because REST is in fact the Web," she said. "The Web
has been around for 15 years, but very few people have used it for
service-oriented systems. Mostly REST is being used for visual
applications, browser-based applications."
That is about to change. Looking to the future, Manes listed time
frames Burton predicts for REST adoption now and in the next three,
five and 10 years.
"Today, it is only innovators that are really working with REST," she
said. "In three years, we should see the early adopters start to play
with REST. It will probably be five years before it is adopted by the
early majority. We anticipate that the late majority will probably not
pick up REST for at least another 10 years."
What will drive REST adoption eventually is that it brings structure
in the form of "constraints" to the sometimes chaotic world of Web
services, which includes those pesky rogue services, according to
Burton. This will provide a level of maturity for SOA development.
Peter Lacey, senior consultant at Burton, played devil's advocate on
the Web conference, arguing the current state of Web services
standards are inadequate and hamper SOA development, which needs the
constraints REST development will bring. Manes did not agree that the
state of Web services standards is hopeless, but she did advocate the
transition to REST for SOA.
So what does this mean to IT departments in general, and enterprise
architects and developers in particular? Manes said where they end up
on the adoption curve depends on the skills of the architects and
developers and their willingness to think outside the box of
object-oriented programming.
She explained that the basic concept of REST, which starts with
sending out GET commands sent via HTTP to URIs to retrieve data is
simple enough. But she noted that even long-time REST advocates admit
having trouble thinking of applications in terms of REST.
Borrowing a verb from Robert A. Heinlein's fictional Martian language
in the 1961 novel "Stranger in a Strange Land," she said, "The basic
concepts are easy, but truly groking REST takes time."
To illustrate the difference between an object-oriented approach and
REST, she used the example of writing a program to turn a building's
lights on and off, keeping in mind that in REST the power is in
sending a command to a URI.
"A REST application to turn on and off the lights in your building
will require you to design a URI for every light bulb and then you
send it on/off messages," she explained. "It's not like I have a
single service that manages all my light bulbs. It's a very different
approach to designing a system. And it's going to be really hard for
developers to get their hands around it."
Frameworks and tools for designing and building such REST applications
are coming from major vendors, especially IBM and Microsoft, which are
making major investments in the technology, she said. It is also
coming from the open source community. The new version 2.0 of Ruby on
Rails "will make it easier to do REST Web services," Manes said. A
major vendor commitment was confirmed this past week by Gerry Cuomo,
IBM Fellow and WebSphere CTO, who said in an interview at IBM's Impact
2007 conference in Orlando, that Big Blue also sees REST as the next
big thing.
However, the problem for early adopters is that most of the tools
developers will use for future REST development are still on the
drawing boards, and current tooling is not ready for REST, Manes said.
"Web services toolkits that say they do REST don't always [do it as
advertised]," she said. "They do POX (plain old XML)."
But architects and developers will not have long to wait before REST
is "baked into frameworks," she said. "You're going to see some very
interesting frameworks come down the line in the not too distant
future," she predicted.
In the next three years, an IT organization's willingness to be
patient with early versions of REST tools and to make the mind-leap
from object-oriented programming will determine where they land on the
adoption curve, Manes said.
"The first thing you have to figure out is whether or not you're ready
for REST," she told her audience. "What's your developer skill set?
Are they going to be comfortable working with XML? Are they going to
be comfortable working with raw HTTP? Are they comfortable working
with open source projects, experimental frameworks or incubation
projects? Are they open to letting go of their object-oriented
mindset? Are they willing to relinquish the productivity frameworks
that are inherent in the current vendor tooling and start working in a
more raw framework environment?"
Any architect or IT manager answering yes to all of the above is a
REST innovator in Manes book.
"If you're ready for REST I suggest you jump on board right away and
get ahead of the curve," she said. "You'll have to train your
developers in REST principles. You'll probably want to adopt one of
the new frameworks or help build one yourself to help your developers
implement RESTful applications. You definitely need to provide
guidance to your people. What you want to do is work to the point
where REST becomes the default for all your distributed applications."
Those who are not ready to take the leap into REST need not be too
concerned, she said, stressing that the advent of REST as the
programming model for SOA is a matter of "when, not if.".
"If you're not ready for REST, if your organization is not ready to
jump into the innovator stage that's okay," she reassured her
audience. "You're not going to get hurt. It's perfectly reasonable to
wait two to three years for the frameworks to mature to the point
where they are actually going to help you with this process. For the
time being, you probably should continue to use SOAP and WS-* to build
your distributed services."
The frameworks and tools are coming she reiterated and the REST
adoption curve is rising.>>
You can read this at:
http://searchwebservices.techtarget.com/originalContent/
0,289142,sid26_gci1256796,00.html?
track=NL-110&ad=590742&asrc=EM_NLN_1507744&uid=5532089
Gervas
