On 11/24/06, Mark Baker <[EMAIL PROTECTED]> wrote: > Not at all!! Resource oriented means little more than data oriented. > Give me an example of something that you don't think maps well onto > REST and I'll see what I can do. Don't get me wrong, there *are* > scenarios which don't map well. Just not the ones you're suggesting, > AFAICT.
Mark There are hundreds of legacy systems that were designed using the simple message-in, message-out model. These have formed the basis of proto-SOAs for many years. When I was at IBM I talked to hundreds of customers who had existing CICS, RPC, C, C++, Fortran, and MQSeries based systems that had this model. By layering XML interfaces, standard protocols like HTTP, and metadata such as XML Schema and WSDL in front of these, they can be converted into universally accessible services. Converting them to REST - using the real REST definitions - is no simple task. For a simple example, why don't you take something like RosettaNet (http://www.rosettanet.org/), which is a widely adoped B2B protocol (used heavily in the electronics component industry), and map that into a REST model for us. RosettaNet is just one of many protocols and approaches that were "service" oriented before it became a buzzword. Paul > > > I think its time to call the Rest-ians on their distinctions. There > > are plenty of RESTians taking a hard line on what is "REST" and what > > isn't, > > Because REST is *very* tightly defined. *cough* 8-) > > > and at the same time willing to say that REST is the only good > > solution for an SOA. > > Whoa, nobody's saying that AFAIK. What we're trying to say at least, > is that REST is a great place to start if your system is data oriented > (large messages). > > More than anything though, we're trying to promote principled design; > adopting architectural constraints which provide you the architectural > properties you need for the context in which you'll be deploying your > systems. By that measure, Web services are *not* principally > designed; they're far too tightly coupled to be useful for integration > at scale, or to evolve cleanly over time (which is, technically, a > form of integration at scale). > > > Well, if you analyze most "services" and SOA they > > aren't based on state transitions of resources. Trying to have your > > cake and eat it? > > Sorry, I can't grok "based on state transitions of resources". > > Mark. > > > > Yahoo! Groups Links > > > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
