1. Can you please introduce yourself and tell us about what you've been up to these days?
Hi everyone. I'm Jerry Coumo, Chief Technology Officer at WebSphere and at least for the last six months I've been deeply involved in ProjectZero. I've spent the last ten years of my life working in WebSphere. I think it has been a pretty 10 amazing years for applications serving. I think when you combine Agile development with classic application serving I think we're going to gain a whole new levelof productivity for everyone, from enterprises to folks working on their own. I'm pretty exciting about bridging those worlds and I think there are some real key concepts and breakthroughs that are in ProjectZero that I'd love to talk about.
In a single word: AGILITY. Our goal is to bring Agile development to the creation of web-oriented applications. There are 3 areas that we're looking to innovate around. Innovation around the creation of web oriented applications, assembling and cobbling together new applications from existing RESTful services and feeds and content that you've just liberated from the web or the enterprise and the third is in executing these applications.
Let me tell a bit about each of those because each is pretty cool. Around creation, I think there are two primary concepts. The first is the concept of dynamic scripting. How does one become Agile? They're not necessarily writing in an OO structure environment, they are scripting.
We realized that in ProjectZero, so we're introducing 2 scripting languages.
A quick word on Java before I go too deeply into scripting. Java served us really well as a community, certainly within IBM and most certainly within WebSphere. Java has a lot of good life in her, perhaps another good ten years. We've given Java our promotion. Java is the system programming language now. Java is how you would implement some of the subtleties of ProjectZero, but your first experience and we hope the source of a lot of your agility is dynamic scripting.
So we offer two dynamic scripting options within ProjectZero. One is for the people who have a very strong affinity to Java - Groovy is that scripting language. On my blog I joke about Groovy being the Java nicotine patch. You put your Groovy patch on and as you start we can kind of wean you into dynamic scripting. So if you have the urge to go off and break out into a Java class or call upon a method that you've written before in Java, you can do that. But we'll allow you to wean into a very compact dynamic syntax that Groovy brings you akin to the Rubies and the Pythons of the world.
Next, based on sher popularity and content, PHP. We feel that with Project Zero you will be Agile and you will be able to express the code you want thru these dynamic scripting languages with Groovy, with PHP backed underneath by a common Java platform.
So Dynamic Scripting is one...The other aspect is this: Project Zero is built around SOA architecture where that architecture is a RESTful architecture. We've constrained and simplified around this notion of REST. In Project Zero you basically have HTTP. When you express a service in Zero you typically express it in a RESTful form or in some derivation of REST. We can express it as an RSS feed, or an ATOM feed; but the web is the primary platform that we build with Zero and REST is the style of service interaction that we built around Project Zero.
Around that, taking on some of the popular frameworks of the time and day we've built a set of conventions around that. Convention has taken over configuration so that if you want to express services you don't necessarily have to code them. There's a set of standards and if you follow them in Project Zero building services can happen magically under the covers. Combining dynamic scripting with REST, now you're really cooking! Those are two really important ingredients.
Assemble is the next part. One of the beauties of SOA in loosely coupled systems is that you can create a set of new applications from these newly exposed services. With Project Zero we certainly leverage that. As I mentioned our service model is built around a web oriented model so it's built around REST, around feeds, So now what I'm going to do is either programmatically through scripts, PHP or Groovy, or through a set of visual editors that we have, allow you to create new applications around the web-based web-oriented services that you've just created or exposed. Or maybe reusing from other sources like from web at large or your enterprise. That's the basic notion around assembling. Now we're augmenting that with a set if interesting capabilities.
If you've used other technologies on the web that allow you to construct visually dynamic web applications, we're going along some of those visual things. There are Pipes kind of interfaces. Some of our assembly visual tools aren't that different but what we're differentiating is trying to build in, in a very simple way some of the basic notions around flow. Whether we're constructing and assembler data-flows: where I can take two feeds, I can aggregate the feeds, I can sort the feeds., So I am building an application, by constructing a new assembly by creating data flows, but also embedding activities along the way, so activity flows. So merge a feed, send an email, send an SMS message - I can start mixing and matches these services together through visual editing or I can do it through fully programatticg ways. I can program with a Groovy or PHP script that will fetch a feed, merge it, aggregate it, etc. This notion of being able to quickly assemble new applications from those previously created services is very powerful and yet another contribution to the agile notion around Project Zero.
The third area is around execution. As I mentioned Java a lot of good life left in her. What we're doing around ProjectZero is focusing on Java in the context of executing dynamic scripting languages, specifically Groovy and PHP. There are a lot of interesting things we can do around our run-time, to optimize the execution of these dynamic scripting languages. I'm really excited working in the field, especially around Websphere application server for a number of years on the possibilities that now arise from executing scripts.
What's a script? A script is something that has a very precise start and endpoint. It executes and then it is done. A lot of the classic applications that run on application servers are built to run forever. What's the problem with things that run forever? We're not perfect, so there are slight imperfections in these things and over time they start to fester: memory leaks, hungthreads, etc. which tend to make some of the longer runningapplications harder to manage.
Project zero applications and the execution environment tend to have a run-and-done property. It starts, it finishes and we kill it, so a new script starts and runs and we kill it. Even if the application isn't perfectly written, sins can be overlooked. If there's a memory leak it won't be as dramatic in the result at least, or the impact on the system. I call it HeisenBugs, I like to say that the Zero runtime environment is HeisenBug resistant because some of these sins that we typically see among running servers we could work around, for example through the run and done model around scripts. There are a lot of interesting benefits that we can get.
The other part about execution environment is the fact that Zero is a web-oriented platform. We know how to scale web-applications, we've been doing it for quite sometime now around Websphere. The web naturally scales; REST is a wonderful protocol for scaling. I mentioned the sentence metaphor before you have urls that are nounds, actions and verbs around content. It's easy to build caching rules around this, they are very precise. There are many caching technologies out there, some of which we're actually building around Zero to help you build performing and scalable applications. Partitioning, workload management, high availability, we know how around a web oriented context, how to do that. We built this into Project Zero runtime. Project Zero will run on a vanilla JVM but we're also putting enhancements around and specifically in our IBM virtual machine, to excel at running these agile scripful applications.
When I talk about the typical Zero style RESTful app, I usually use the sentence metaphor. When you think about an application around Zero, think about an English sentence. You have a noun, a verb and an adjective. I can create sentences like this. My noun could be "photo", the verb is "view or fetch" the photo, "get the photo" and the adjective is the type of photo, a JPEG photo. The sentence is this: "Fetch the jpeg photo". In Zero I can express that. The noun is the RESTful entity. How do you express a RESTful entity? A URL: /something/photo. The verb is "get" so in REST terms we have exactly four primary actions: get, post, put, delete. So, "get photo". What's the data type? It can be jpeg. Thinking about building that service is as simple as thinking about a sentence. Quickly being able to express sentences, express services and exposing content through that mechanism is very powerful and get you the time to value.
Where is the data coming from? Where is the content you're scripting coming from? One of the things I see, especially around enterprise scenarios, is that there's data out there. When you want to start building apps around that data, for e.g. I have a commerce system; I'm not suggesting that you build a commerce system in Zero but one of the things you can build with Zero is a set of apps. We call them situational apps. These are apps that maybe you didn't plan for them at the beginning of the year, they just came up. Maybe in the past you would have build these apps with Lotus Notes and some of the environments around our Lotus collaboration products or Microsoft Visual basic or things of that nature. There are typical primary enterprise apps our there that are generating the data, now you want new views into that data, you want to mix the data in new ways. There may be multiple sources of data, some enterprise data, some data out on the internet, you want to bring those together to give new perspectives. You want to do this quickly.
I'm not necessarily stating that you use a limit to the type of applications but I'm saying it's most useful when you try and get something done quickly and the data is out there.
IBM and especially we in software group are behind SOA. SOA is an architectural style that we feel is proven, cost-effective, all of those characteristics. We've been very clear and articulate about the fact that SOA is an architectural style and there is no de-facto implementation of SOA. We've been advocates and driving through our products the instantiation of SOA through WS*, a set of industry standards. WS* provides a suite of capabilities that are industrial strength mission critical. That side of SOA is very appropriate for the standard types of things we do in our portfolio. The question is this: "Is it a one size fits all? Is that the only instantiation of SOA? Absolutely no!
What excited me about REST - and you can think if it in terms of the 80-20 rule - there's a set of activities that may not need the rigour that WS* provides. What excites me about REST is that we think that it can provide the entry level into SOA.
The nice part about REST is that it's like the air that we breathe. It's all built around the web and the web is all around us. That translates into all sorts of interesting things: skills, infrastructure- these things are just there. To be able to talk about a SOA model against the things you already have is very compelling. We can get you doing SOA very quickly and as you graduate you will start to need some of the things aroundWS* for sure, but this gives you a starting point. Now how we interpret the 80-20 rule, is this 20% of the things that 80% of the people are doing?
A wide variety of mission critical things can be expressed through REST. That's what excites us and that's the connection between SOA. REST too is an architectural style built around the notion of loose-coupling. If you look at how an Ajax application through JavaScript invokes services through HTTP over the internet; that's a great example of a loosely-coupled built system so I'm very excited when I talk about Ajax based architectures as an example of SOA. These things whether you're an enterprise person or not, you can get your head around that and you can start to understand the subtleties of SOA through REST.
This makes me a little nervous because the beauty of REST is that it does what it does very well. It's been doing it for years. We talk about it in more structured terms, I brought up before the sentence metaphor of how to think about the primary service aspects of REST. The thing that I would hate to see is us overcomplicate REST, because its beauty is in its simplicity. Having a clear delineation between the styles of SOA and RESTful SOA, Enterprise SOA, I think is important.
The things that we're trying to accomplish around Enterprise SOA are by nature very complicated. For example trying to integrate systems that are written around different architectures, that are supporting synchronous and asynchronous protocols. That's a reality of life and something has to deal with that. I think the way WS* and some of the standards around address that in a very efficient way; but those are complicated problems. I would hate to see the simplicity problems around REST be stretched to the point where they too are trying to solve some of these complicated problems, because REST will no longer be the thing we are all attracted to.
Separating church and state is a great way because we have WS* and the pure web and REST. But as soon as we try to start formalizing REST like "What is the WSDL for REST? There is none." Let's the try to keep the sentence structure, let's try to keep it because we have WSDL and it is good for what is does. When we need rigour, we have those capabilities. I've seen customers using the two very well. When they start off defining services through WSDL and then expose entry services though those entry points, and also through REST. I think there's certainly room for both. I'm happy that the two exist. I don't want one to become the other.
6. Are you backing away from WS*?
Absolutely not, if I gave that impression, it is certainly not what I intended. What it actually is, is the fact that REST is a form for RESTful SOA. The other thing I'm saying is that REST isn't special in a sense that is the birth right for Project Zero. I think Project Zero specializes in REST, but when we look across the portfolio we have in IBM software group, in WebSphere, REST will just be a integral part in those products. For example with our process server or our ESB, there will be REST on-ramps, that will expose activities and capabilities of those products: management capabilities, monitoring of those products through REST interfaces. Again, it's like the air,it's all around us and we'll be incorporating that into our products. Are we backing away from WS*? NO. Are we fully embracing the web through those products? Yes. As I eluded before, they are not mutually exclusive.
7. Do you see cloud computing as an important emerging trend and how?
I absolutely see this as an emerging trend and as I said before with Project Zero, I thinkthat having an Agile capability in your portfolio that allows you to capitalize on that.
The wonderful part of what's happening around the web and cloud computing is being able to expose content in a very pervasive, scalable and uniform way. We are encouraging enterprises to expose their content whether it's behind the firewall or in front of their firewall in that fashion too, because now that is liberating the data. Once the data is liberated you can actually build interesting applications around it. Whether is flickr, amazon, google or some large enterprise exposing their traditional corporate data internally, now the opportunity is out there to make connections between the data that are either obvious or not so obvious.
The wonder of this, is by liberating the data, by putting the data in people's hands, by unleashing that data, perhaps we'll learn things that we didn't know before. I think this is really exciting and we've seen this time and time again.
We have a very fixed perception of how this will work. We have a view on our data. By liberating the data and creating an agile environment by which you can create new classes of applications maybe we get new perspectives on that data. I think the notion of clouds and pervasive APIs exposed through the web will unleash new opportunities, new perspectives, and new business opportunities for all; I think that is what really makes this exciting.
8. How will IBM be incorporating REST into it's product strategy?
We're at a point now where REST in the web is like the air. We want to be pervasive across our products. What we see is a drumbeat of releases across our product line. I will talk to the WebSphere product line specifically of introducing REST capabilities as just an inherent part of our produts.
Take one of our classic pieces: WebSphere MQ, our award-winning messaging product. We have capabilities in the latest release of MQ to expose MQ capabilities through REST. For the first time now you don't need the MQ client to drive work into MQ. If you want to post a message on a queue all you need is a web environment whether it is a Javascript app that can POST up through REST, a message or a PHP, a Zero app. You can now interact with MQ through REST. If you want to inspect the contents of your queue the same thing; there's a REST interface for that.
It's like the air: everyone has a browser, everyone has an environment, a javascript based environment. Now you can start interacting directly with our middleware through REST, through a SOA interface that it's just there, it's pervasive.
We can step through the portfolio:, Websphere application server, we have something called Web 2.0 feature pack coming up that's going to bring on capabilities around REST, Atom, Ajax comet, for being able to do dynamic updates back from a server to an Ajax client and allowing you to meld that interface, the RESTful style on top of a JEE application. I can continue going through our portfolio everything from WebSphere ESB to our Datapower appliance, adding capabilities around those technologies to support RESTful on-ramps: eg: so I want to put a message on the ESB whether is a Websphere Java-based ESB, or our appliance-based ESB, again having RESTful interfaces to be able to do that.
There are not going to be special offerings, this is just going to be a way of doing business, part of our core technology around the WebSphere brand.
I get this question quite often. The way I like to think about is... for years we've done incubators in IBM and we will for a very long time. Traditionally we do our incubators behind the firewall. We have this period of innovation; then we unveil the innovation maybe on select few customers. Sometimes we get surprised; maybe it wasn't so innovative, or at least innovative only in our own minds. We want to focus in innovation that matters. I refer to it as bringing some Darwinism into software development, so survival of the fittest idea. We want to our ideas out, to communities of interested users whether that's customers, IBM customers or not. It doesn't matter as long as they are interested in our topic. Get that info out there, get that feedback loop very tight so that we can innovate on things that aren't just intellectually interesting to us but things that matter to people who potentially might be willing to buy the software.
With the approach that we're taking with Project Zero also Rational; our Rational division has a project called Jazz in a similar verin. The idea is this "let's incubate in the visible side of the wall; let's get that out in the open. I likenthis to some of the restaurants that are popping out these days you walk into the restaurant and you see the chef cooking right near you in the middle of the restaurant. To me that's kind of like Project Zero. We're not behind closed doors, we're actually in the open cooking our food right in front of you so you can see.
In Project Zero you can see the source, you can see the folks and talk to the folks via forums and blogs who are building the source. You can track our milestone. ,You can influence you can participate in polls, you can send comments, you can download and try the code.
I haven't said anything about licensing because I would like church and state to be separate here. Being able to be out in front and visible to me that'd somewhat a development style. IT's our process for developing this particular idea of code. We want to do that openly. Separating that for free I think is what we're trying to do.
Is Project Zero free? What are the licensing aspects of it? It's not unconditionally free. It's free to try. free to use at some level, but as some point we're in the business to sell software. We're trying to get people's feedback early, get it in people's hands. Perhaps these are traditional or not so traditional customers, we appreciate the feedback.
We then have to deal with the next question: What is the licenseing? For small scale operations people developing, people kicking the tires, certainly being very liberal on that license - we will be. Then running the code in production, those licenses will involve conversations with some of our sales team.
The main objective in how we're doing Project Zero visibility, open, not behind the firewall but in front of it. Darwinism at work, getting our ideas out there, building a community of people.
We typically have many followers for our products and brands and we don't want to surprise them at them only at the end, we want to move that out in the front. Hopefully shorten our time to get innovative solutions out to our customers, and we think this is an interesting combination between the wonderful worlds of open source and commercial software development. Is it black or white? I think this is an interesting shade of grey that we want to experiment with. So far the experiment is working really well, so far we've had about 50,000 unique visitors and about 135,000 downloads.
10. Any final words about REST and Project Zero?
As I said this is a really exciting time for all of us within IBM and WebSphere. Project Zero is really touching upon some really interesting and new concepts both of how we build products (with Project Zero they're all on the visible side of the firewall) to oru first forayinto scripting the web through the use of dynamic scripting languages like Groovy, building around a RESTful architecture and really building it right into the core of the system and having interesting technologies around assembling applications through mash-ups and actually executing an execution environment around dynamic scripting languages.
The stars are kind of aligning really well, this feels right. It fits nicely into where we are going into Websphere in general, it fits nicely into how the industry is evolving around web orientation as an on-ramp into Service Oriented Architecture. The stars are aligning for the industry and for IBM. Exciting times, check out projectzero.org, and thanks for all your support!