I find if people look at SOA as a producer-focused view, i.e. "I have
these capabilities to offer in the granularity that is convenient for
me & aligned to my business", then certainly it's very different from
REST.
Some alternatively view SOA as a twin-track analysis (a balance between
producer and consumer interests), which an approach that some analysts
like CBDI promote. This approaches values synergy and serendipity
across producers & consumers over alignment. There, I think REST
offers many interesting lessons on the extent that one can
"consumer-orient" one's services: the impact of global naming,
interface generality, etc.
As for the POX/HTTP v. REST confusion, I tend to look at the tools as
the culprit. There aren't really good agent-programming environments
that concretely highlight WHY, for example, I may want to have a URI
for everything interesting instead of just embedding an arbitrary
context-specific identifier in my XML document.
Cheers
Stu
--- Todd Biske <[EMAIL PROTECTED]> wrote:
> 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."
>
=== message truncated ===
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
