| QUESTION & ANSWER |
Mule architect sees REST with Atom rising, UDDI fading |
 |
By Michael Meehan, Editor-in-Chief, and Rich Seeley, News Writer
12 May 2008 | SearchSOA.com |
|
|
While SOAP and WSDL caught on, UDDI, the third leg of the Web services stool, has never enjoyed much popularity even as governance became more important to SOA. Dan Diephouse, the creator of XFire and software architect at MuleSource Inc., discusses these trends in the second part of a conversation from last week's Java One conference in San Francisco. There are times when Web services make sense, but he sees limited uptake on UDDI. Right now, he is putting the finishing touches on Mule Galaxy, the REST-based open source registry/repository that employs the Atom Publishing Protocol.
Read Part 1
You created XFire, the Web services stack, and yet with Galaxy you are going beyond Web services, so if somebody asked you what can I get out of a Web services stack these days, how would you answer?
Dan Diephouse: There are a lot of good use cases for Web services. If you have a very message-oriented application and you need something that is protocol independent, you're going to do messaging over JMS and then integrate with .NET. WSDL and SOAP provide a great mechanism to do that. It works out of the box. So if you're doing that kind of application then I would look to Web services.
In terms of REST, what kind of tools are developers going to need to do enterprise applications with REST?
Diephouse: We've developed our RESTpack for Jersey, which is a JAX-RS [JSR 311] implementation as well as for Restlet, which is a REST framework, and [Apache] Abdera, which uses Atom Publishing Protocol. I think users are going to need these tools. They each provide a different approach. Jersey provides this lightweight annotation-based approach, which makes it very easy for people to get started. Restlet is more of a lower level framework, but it provides a lot of extensibility points. I also advocate Atom Publishing Protocol wherever possible because it's a RESTful protocol. It's sort of out-of-the-box. You can re-use it without having to worry about developing your own pieces. So I think we've got a lot of the structure there now, and the next step is more about education. What cases do I want to use REST? What cases do I want to use SOAP? Now, I've got a REST service how do I tie that into my backend messaging system?
So in what cases do you want to use REST?
Diephouse: It's a case where you have a message-oriented application, whether it's a subscription or topic type thing and if you can use just HTTP, yeah, that's the RESTful sweet spot. If I can use HTTP and I don't need to do more subscription or more message related things then I think REST is the right solution.
Have you innovated the use of Atom? Was it originally viewed as something that could be used in a registry/repository the way you're using it?
Diephouse: There have been a lot of people who said we can use Atom for more than just blogs. So there have definitely been people whose shoulders we stand on. Because I've been involved in the Abdera project, which was an Atom Publishing Protocol implementation, I got to know some of these folks and learn a little bit about what they are doing and how to apply it. I know there's one other company that uses the Atom Publishing Protocol for registry, but it's a unique feature and a selling point for a lot of people.
Is the simplicity of Atom what attracted you to using it?
Diephouse: Yeah, it's a simple solution, not only for us but for our users. It's very easy for them to understand and there are already a lot of tools out there for them to integrate with. So I can use a feed reader and I can subscribe to any new services inside a registry. I can see what's going on inside my organization. That's a powerful thing. Whereas, if you look at UDDI, what tools are out there that are open source for people to use? They are very limited. And the ones that are out there are buggy. Even if you do have tools, it's so overly complex for what people are trying to do, it's kind of a spec developed in a black box. We'd like to make things a little more friendly for developers.
So you've gone ahead and moved beyond UDDI?
Diephouse: Yeah. There are definitely some people who use it. but the applications of it are pretty limited. That's why I'm not focused on it at this point.
Your ESB performs a lot of the functions that we used to see on an app server, what is the difference now between and app server and an ESB? Are ESBs replacing a lot of what we used to get with an app server?
Diephouse: We definitely see a lot of people who are ditching the app server completely because a lot of things that they need like transactions or transaction management are built into the Mule ESB. App servers are more focused on the applications. While Mule is more integration glue tying services together, bringing things over on JMS and transforming it. So they can be complementary to some extent. But there is definitely some overlap and we see people shying away. Why have an app server if you don't need one?
What can we look forward to from MuleSource the rest of this year?
Diephouse: I can't comment on what we've got coming up, but you guys have covered that we've released Mule 2.0. We released our RESTpack. We released our IDE. So we have a holistic story going on now. In open source there isn't anything out there like that. We've got an IDE, we've got an integration platform, we've got a governance tool. We've got it all together and I think the story is pretty interesting.
|
|
|
|
