[Web Services]Critics Say Web Services Need a REST

转载自: http://dsonline.computer.org/0412/d/oz001a.htm Critics Say Web Services Need a REST Greg Goth Just as Web Services’ allure appears to have reached critical mass with developers and enterprise customers, a passionate debate about the efficiency of the technologies underlying the much-ballyhooed distributive infrastructure has rekindled. A vocal group of developers critical of the orthodox Web Services stack is touting the use of a technology called REST, or Representational State Transfer Web Services. REST eschews the orthodox SOAP Web Services stack for a more streamlined (and familiar) XML-over-HTTP approach for exposing software functionality. While researchers had explored ad hoc REST implementations in the 1990s, the comprehensive theoretical underpinning for REST first appeared in 2000 in a doctoral dissertation written by Roy Fielding, chief scientist for Day Software and a cofounder of the Apache Software Foundation. Developers involved in the early days of writing Web Services specifications debated REST’s principles, which posited(提出) that using the World Wide Web’s protocols for a distributed environment would be far more elegant than trying to devise a new complex stack based on predecessors such as Corba and COM. However, REST proponents say decoupling Web Services from the Web negates the Internet’s inherent scalability and has forced developers to approach distributive integration problems from the standpoint of a tightly coupled SOAP-RPC (Remote Procedure Call) architecture. Such an approach directly opposes the loose coupling that Web Services are supposed to provide. However, with IBM and Microsoft leading the push to Web Services, REST advocates also admit they’re fighting powerful forces. Eureka for some, not for all Ottawa, Canada-based developer Mark Baker is widely considered to be the REST community’s most vocal advocate, considered by some to be too unyielding in his views. Baker says he accepts the role in hopes that the discussion on REST and SOAP will continue to evolve. “I sort of got into the Web in 1998, coming from a CORBA background,” Baker, who supervised part of a large CORBA-based project at Nortel, says. “So it was in 1998 I realized what the Web was, how superior it was to CORBA for integration, and how stupid I was; if I had just used the Web, how much easier it would have been. Now I’m just applying that knowledge, that experience I got from that Eureka moment. “I just argue my point from a fundamental point of view. I do hope and expect that some of the leading Web Services architects clue in to, make that connection, how the CORBA-style architecture is related to the Internet and Web style. Once one or two key leaders in that space make the connection, I think that’ll spark, and they’ll be able to convince some of their friends who stopped listening to me a long time ago.” Others have advanced Baker’s Eureka observation into a slightly more codified explanation of REST. In two papers written for XML.com, Hao He, an architect at the Thomson Corp. in Australia, briefly explains the divergence between the two approaches and some of REST’s technological underpinnings. He argues that the pioneering SOAP-RPC Web Services approach actually breaks one of the two constraints imposed by a service-oriented architecture: that messages other than attached binary data must be in XML. “SOAP RPC ‘tunnels’ new application-specific RPC interfaces though an underlying generic interface,” He writes. “Effectively, it prescribes both system behaviors and application semantics. Because system behaviors are very difficult to prescribe in a distributed environment, applications created with SOAP RPC are not interoperable by nature. Many real-life implementations have confirmed this.” REST implementations, however, use only four HTTP-based semantics: HTTP GET is used to obtain a resource’s representation. Consumers use it to retrieve a representation from a URI (uniform resource identifier). Services provided through this interface must not incur any obligation from consumers. HTTP DELETE is used to remove a resource’s representations. HTTP POST is used to update or create a resource’s representations. HTTP PUT is used to create a resource’s representations. He says that adherents to the traditional Web Services stack have unfairly criticized the constraints mandated by the HTTP semantics. “The Web architecture has been traditionally criticized as being too simple, only useful for simple tasks,” He says. “Not so long ago, HTML was labeled as ‘babyish’ by many experts. Yet, the Web architecture is arguably the most successful architecture the human being has ever come up with—technically, economically, and sociologically. People get excited when their applications become Web-enabled. What is interesting here is that the Web almost has a life of its own and it is quite resilient, even without vendor support.” Mike Champion, a senior technologist at Software AG, maintains that the REST advocates, playfully called RESTifarians, are indeed oversimplifying the task. Champion was cochair of the World Wide Web Consortium’s Web Services Architecture Group during much of the debate. “There’s almost a philosophical level to all of this,” Champion says. “[T]he relational database purists … are saying, ‘All the things Oracle and Microsoft and IBM are doing to pollute relational databases with all this object stuff and this XML stuff, it’s just terrible, they’re violating the theoretical underpinnings of relational theory and they’re making a big mess of it,’ and about 99 percent of the consumers of this are saying, ‘Hmm, I can either do this Oracle hack and get it to work with a couple lines of SQL and have it work well and good enough for me, or I can do it the pure relational way and spend man-years trying to optimize it.’ “The RESTifarians are in a similar sort of situation. They have this theory of the universe that you can do everything with this limited set of operations which closely correspond to the forms of HTTP, and at some logical level they’re right. For simple problems—just a matter of doing it in two or three defensible steps rather than one ugly mess—they have a good point, but when you get to HL7-compliant medical records, think of the operations that have to be done to update a medical record. You’re not talking about going from a couple clean operations versus one kind of ad hoc one. You’re talking about orders of magnitude more complex.” Champion says one of the most common examples of a successful REST implementation also implicitly gives credence to the argument that one size does not fit all, whether SOAP or REST. “Amazon.com has two APIs they expose to let applications or partners accept their services,” he says. “One is the mainstream SOAP/WSDL type thing; the other is just submit an HTTP request and get an XML document back that describes what you’re looking for. And apparently 80 percent of these go for the straightforward Web one. People keep discovering the 80-20 rule. The whole stack of stuff that Microsoft and IBM are driving is essentially for industrial-strength use cases where you’re exchanging confidential information where security’s important, reliability’s important, you’re going from a Unix client over here to a mainframe on the other side of the world over a couple intervening protocols, and simple XML over HTTP isn’t going to cut it.” Baker says Champion may have a point, but that the orthodox stack is so far removed from the Web architecture it will need to change or wither. “I think the 80-20 solution is quite reasonable, and REST maybe isn’t suitable for that 20 percent. But in those cases, I would say the current stack is such an extreme departure from the Web stack. It didn’t need to be that extreme to accommodate that 20 percent.” However, another Web Services pioneer, Iona Technologies chief technology officer Eric Newcomer, contends that the pure REST approach ignores one of Web Services’ overriding drivers: that large enterprises needed to find a way to ensure interoperability by mapping to existing execution environments instead of ripping them out in favor of XML/HTTP. To continue Newcomer’s argument, then, what might look extreme is, in reality, quite prudent. A message, not a method, to the madness Jim Webber, a lecturer at the University of Newcastle in the UK, is currently working on the convergence of Web Services and Grid technologies at the University of Sydney, Australia. He says Newcomer is tantalizingly close to answering one of the debate’s enduring questions. “I kind of, almost, agree with what Eric’s saying,” Webber says. “I think what he’s grasping for there and just missing is [that] we need to concentrate on the form of documents and the exchange of documents, and what the Web Services community seems to be hell bent on doing—whether they realize it or not—is … creating SOAP APIs. That sort of model inherently leads you into rebuilding RPC or object-based systems, with object or method call as your primary abstraction. “And that kind of undermines the whole value of Web Services, which aren’t meant to be tightly coupled systems in that respect. I think Eric’s trying to steer us toward a much more loosely coupled [approach:] ‘Let’s focus on the business documents which organizations need to send each other, and then each organization can figure out how that maps onto its back-end system.’ … In the Web Services specs as you read them, you implicitly kind of think, ‘Yeah, if I invoke this method on this object, it does, or should do, this for me.’—which is completely the wrong semantic.” Instead, Webber says vendors of Web Services products and toolkits need to think not of objects but of messages in order for the orthodox stack to achieve the sought-after loosely coupled paradigm. He says the REST advocates have to be given much credit for raising their observations about a bloated SOAP approach, but that orthodox Web Services disciplines have moved forward sufficiently to render REST a subset of the larger Web Services landscape. “I think people are starting to [recognize] that messages are important in Web Services, and that’s quite different from, say, four years ago, when people were very interface-centric; they were trying to perceive Web Services in terms of what they knew, which was Corba or the Component Object Model. So at first we started to build Web Services the same way. Over time, I think the nagging the RESTifarians launched into kind of kept us on our toes a bit, and people started to think maybe we need to reappraise this. “From a personal view, I started to think in terms of not binding from a client to a service but binding to the messages, because you don’t need to bind any further away than the messages. As long as the right messages are percolating up your stack, and you’re sending the right messages down your stack, why do you need to try to imply what’s going on in the outside world?” “Jim’s proposing sort of an alternate architectural style,” Baker says. “I see the style he’s promoting as having enough of the right architectural constraints to really lower the cost of integration. The other stack, I don’t see that happening right now.” Hao He concurs in his view that the orthodox WS stack is still too complex. “Ironically, a lot of the effort of the Web Services stack is to try to abstract away from the Web, despite the name ‘Web service,’ He says. “Unfortunately, any unnecessary abstraction comes with unnecessary costs and someone has to pay for it. To do what the Web already does well, a lot of ‘wheels’ have to be reinvented. “On the other hand, there are two strong forces behind the Web Services stack.   The first is the tremendous marketing power vendors possess. The second is that the developer community has been ‘brainwashed’ with OO (object-oriented programming) for years. With a strong OO background, the Web Services stack sounds intuitive to many. After all, ‘Web service’ was created as a marketing term. “The Web Services stack can, however, quietly become more REST compliant. For example, SOAP can be just a harmless overhead if it is used in a RESTful way. By this approach, the Web Services stack can indeed prevail—and we always like the ‘second-best’ technology anyway.” Shaky middle ground The future of REST and Web Services may hinge on how widely accepted the latest version of SOAP becomes. SOAP 1.2 is far more REST-friendly than previous versions of the protocol, including a Web Method Feature that describes SOAP-HTTP binding constraints. Champion recalls the discussion surrounding the new SOAP specification brought the conflicting views into sharp contrast. “Roy Fielding was at the time on the W3C technical architecture working group, this would be in early 2002,” Champion says, “so the SOAP spec was at a certain level of maturity. Fielding, when he gets inspired, can really let fly—and he let fly not so much at the spec as at the hype surrounding it.” The result, Champion says, was a delayed release of the new spec, but one that could finally give the marketplace the ability to sort out Web Services’ future. “SOAP 1.2 is out there and the market can decide, and I expect if you’re using HTTP and XML you can decide if the SOAP stuff offers any value. When these actual standards get implemented, and with the release of new tools, people will have the ability to do it both ways, and it’ll be like the relational database people. There will always be a hard core that will say the reason everything that’s gone wrong has gone wrong is because ‘you didn’t listen to us 10 years ago.’” Jason Bloomberg, senior analyst with ZapThink, a consulting firm specializing in XML, Web Services, and SOA implementations, says he doesn’t think business decision makers really care one way or the other what form wins out. “Business people almost entirely do not care,” he says. “The whole REST thing is separate from the business of IT. This is a business issue and there are businesses out there with IT problems of a whole range of types. The REST movement is not really focused on solving business problems; they are more focused on coming up with an elegant approach to exposing software functionality, regardless of whether or not it meets any business need.” But Hao He says business customers could ultimately force vendors to become more RESTful if it means a healthier bottom line. “They do care about the cost—the cost to develop their applications and the cost to maintain them,” He says. “Someone has to pay the cost of unnecessary complexity, and that someone is most likely to be the clients.” Now all somebody has to do is define unnecessary complexity

阅读全文(3511) | 回复(0) | 编辑 | 精华

验证码:  (不区分大小写,请仔细填写,输错需重写评论内容!)


«April 2021»
blog名称:World Wide Web Watch
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.307 second(s), page refreshed 144565417 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》