| QUESTION & ANSWER |
REST needs tools for SOA, XFire creator says |
 |
By Rich Seeley, News Writer
05 Sep 2007 | SearchWebServices.com |
|
|
Representational State Transfer (REST) is the next big trend in service-oriented architecture (SOA) development, says Dan Diephouse, the creator of XFire, who recently joined MuleSource Inc. as software architect. He rejects the criticism that REST may have trouble scaling in enterprise applications, but he argues that tools are needed to make it easier for developers to create RESTful Web services. Asked in this interview what his priorities would be as he starts his new job at MuleSource, the provider of open source infrastructure and integration software, working on REST tooling topped his list. He also wants to help developers better understand REST and find ways to reduce the overall complexity of SOA development.What issues are you seeing in SOA development that you will be working on at MuleSource?
Dan Diephouse: A lot of people are struggling to deal with the complexity of SOA. There are a lot of people who don't understand it. So I think a lot of the work is going to be simplifying things, helping people understand how to build distributed systems which are fault-tolerant and highly-available, while at the same time trying to increase their ROI and decrease their IT costs. I don't know if that involves a lot of new technologies per se, but it is something I want to help people do right now.
Are there other trends you are seeing?
Diephouse: One of the other trends I'm seeing now is a move to REST and RESTful systems. Going back to my first point, a lot of people are struggling with complexity in WSDL or SOAP or WS-Security and all those related specs. I think REST as an architectural style simplifies things to some degree. So I think we're going to see more people putting RESTful systems into production as opposed to SOAP and WSDL and there's going to be a need for tools around that.
Along with REST, I'm starting to see more adoption of the Atom publishing protocol, which is a protocol around the Atom syndication format to publish and edit resources. I'm actually seeing people starting to put that into production around general business applications. So instead of just regular media publishing use cases, which was the primary use case for which APP was developed, we're starting to see people using Atom to do things like create and edit employee records. I think you'll be seeing us focus in on these areas at MuleSource.
One criticism of REST concerns whether or not it will scale. Do you think it could scale up to an enterprise application?
Diephouse: Architecturally, one of the big advantages of REST is that it does scale better than the typical SOAP-based system. If you implement a RESTful application correctly, it's defined in such a way that there's this uniform interface. On this uniform interface, you always have this GET operation. REST defines it so GET does not change the serverside state. So any sort of resource that we GET can be cached by an HTTP proxy, which can increase scalability tremendously. HTTP has lots of concepts to help you scale out your application, like ETags, which allow your client to send a request and say: "If nothing's happened at this time, I don't need to get any data." Whereas if you're doing a SOAP version of that, you're still creating a whole XML message. We still have to process that and that's going to take up valuable server resources. ETags and caching can be handled a little more transparently.
What new tools are needed for REST?
Diephouse: The tools issue is one of the things I think is holding back REST at this moment. There's a lot of work going into the area of how to turn a business application into a RESTful service. One example of this is the annotations in Java, which the JSR-311 standard people are working on. In Apache CFX, we did our own annotations to turn your Web service into a RESTful service. There's also work in Apache Abdera to build an Atom publishing protocol annotation. So we're seeing a lot of work in the area to help simplify development. Right now, people are basically building their own frameworks internally taking advantage of the Java servlet API. While that can work, it's a little more maintenance and takes a little more upfront work. It scares people away I think. Like it or not, it's really easy to take your business code and turn it into a Web service with SOAP and WSDL. It's not really possible to do that right now with REST. So I think we'll see a lot of development in that area in the coming year.
So, there'll be development of tools to make REST easier?
Diephouse: Yes.
What is it about REST that makes it difficult without those tools?
Diephouse: A lot of people think REST is sending XML over HTTP without a SOAP envelope, but there are things like how do I take advantage of proxies for caching? How do I use ETags? How do I secure my data? A lot of people are still trying to figure this out and while the knowledge is out there, it doesn't seem to be common knowledge at this point yet.
So is it a combination of needing tooling and some education?
Diephouse: Definitely. Education and simplification of building RESTful services are the big things we need to work on right now.
|
|
|
|
