When SearchWebServices last talked to Jerry Cuomo, CTO for IBM WebSphere, in May he talked about the emergence
of REST and Web-based SOA. Since then he has become a champion for Project Zero, an incubator for a REST-based framework for Web SOA that is now in beta and moving toward an as yet unnamed product release in 2008. While it is not an open source project, IBM is making it transparent for customers and developers, so they can watch Big Blue design and build new Web tools. In his blog on the Project Zero site, which provides a window into the project, Cuomo explains that the environment includes a scripting runtime for Groovy and PHP with application programming interfaces optimized for producing REST-style services, integration mash-ups and rich Web interfaces. In this interview he discusses what he's been blogging about and how the Project Zero approach may change the way developers and architects view at service-oriented architecture (SOA).What exactly is Project Zero?
One of the things we feel we need in our portfolio is a technology that's optimized for time, optimized for agility. Whereas our other platforms, and I think the enterprise software industry at large, [are] optimized for enduring value. You build the assets very carefully because you want them to last and live forever. But there's a place for the agile application where living forever might be nice but if I don't have this done by Tuesday it doesn't matter. I need to optimize for time. So Project Zero is a site where we're developing an agile platform called the Zero platform. What is the platform?
It's a platform built exclusively using Web SOA architecture. And we're bringing scripting into the picture in a big way as the primary means for building dynamic Web applications. How do you see this platform changing or extending SOA?
I talk about RESTful SOA on my blog. It is the notion of the Web as the platform. If you look at a lot of the companies that are poster children around Web 2.0, you'll notice a certain API that has become very popular utilizing technologies like REST and feed technologies like RSS, and Ajax for building interactive clients. When you look at these technologies and how they come together, they are a perfect personification of SOA. At IBM we've been very careful to say SOA is not about a particular technology. It is an architectural style, and there are many ways to render that style. Enterprise SOA in the form of WS* is a stringent way to represent that and it has a place in the world. And it's a good place. But it is not the only style of SOA. Web SOA is another style that has emerged. It's a style that we feel has properties that can help an enterprise extend its reach to a new class of users. Extend it how?
The ultimate part of SOA is looking at how we can expose our key business assets as services in a reusable, re-mixable way, so that you can build and compose new applications from existing services. When you look at the mashup craze on the Web, bringing that to the enterprise is a very compelling partnership between Web SOA and enterprise SOA. Again, that's extending the reach of SOA to the Web using a Web- oriented architecture. Are you working with more than just REST?
We love Java at IBM and I think between IBM, Sun, BEA and Oracle we've got a large industry of folks in love with Java. And there's a rigor around Java in developing applications that served us very well and will continue to serve us very well for at least another 10 years. But in Project Zero and the Zero platform, we've promoted Java to the system programming language. So kind of like today in Java, C is the system programming language. If you really want to write something that's down and dirty, you may chose to do it in C and then use the Java way to wrap C functions. Well, in Zero, the OO Java world gets promoted to the system level, and on top is scripting languages. Which scripting languages?
We support two, PHP and Groovy. Groovy is a standout because Groovy appeals to Java programmers. On my blog I've called Groovy the Nicotine patch for Java programmers. What I mean is that if you understand Java and you want to get into agile scripting, if you use the Groovy "patch" it will make you feel more comfortable moving from an OO Java world into an agile scripting world. That's because it uses a lot of the Java underpinnings but it's a smooth transition. It's built on a Java VM, so if you want to get down and do some system programming in Java, you can do that, too. So we think it's a nice smooth migration into this agile world. We include PHP because there are so many assets out there that have been written in PHP, agile assets. So all this comes together to create Web SOA?
I see an environment like Zero in cooperation with an enterprise SOA being a very powerful combination as a way to extend your enterprise platform out into areas that are probably hard for it to reach today. How would that work?
If I wanted to transform a set of my enterprise services expose them as feeds, I could do that very quickly with Zero. I can create a Zero app to sit in front of my enterprise app that transforms a set of enterprise services into a set of nimble Web services. So this is the Web SOA part?
Yes. It's exposing them to REST, REST being this architectural style where, as I pointed out in a recent blog, the service is defined almost like a sentence in English. You have a noun, a verb, and an adjective. The noun is the URL. We all know how to use URLs. We use them every day in our favorite Web browser. The verb is one of the HTTP actions. There's exactly four of them. GET, POST, PUT and DELETE. So it's a combination of URLs, a verb, and then the adjective is the data type we expect. It's describing the noun. So if the noun is an employee, the adjective is how I want the employee data returned. As XML, or as JSON? That's the notion of exposing services as RESTful services. How does that work in the real world?
We've actually worked with a couple customers on this and the pattern is they are defining their services as enterprise services. One customer had a collection of enterprise services and they wanted to create a toolkit for business partners to use to quickly access these services and built business partner applications that use these enterprise services. There was moderate uptake from the business partners. Then they went out with us and we built a set of complimentary business services. We didn't change the enterprise services. They were still there and part of the toolkit.
For example, what we did was the enterprise services may have had 10 parameters for every service call. We simplified their APIs and maybe only had five of them. And of course, URL accessible they were much more fluid to interact with. So automatically they saw a 50 percent uptake in using the enterprise services. Because these things were made more assessable in a Web form using REST, many more people were now using their services. The cool part is you're getting people to use the services because you've lowered the barrier to entry to you enterprise services.
Then people start to use the services in ways you never anticipated and you get a whole new set of apps being written against your services. Hopefully those apps will drive new business. So we think that's an awesome combination of Web SOA and enterprise SOA. So that's how you explain Web SOA, which may be new to some people?
I think Gartner talked about it as Web-oriented architecture, WOA, or you can call it SOA on the Web. With Zero it's about agility where you're using this Web SOA or WOA platform to gain agility. Then we're augmenting it with things like scripting, an assembly environment, and we also have a runtime that Zero runs within. It's a Java-based runtime, which I've been calling the New Reality Runtime. It's optimized to run scripts and to run RESTful applications. It's very simple, small footprint. It allows you to start small and build big.