Besides the management console, we have three other ongoing projects in Ode. One adds HTTP binding and REST support to the engine, so you can use Ode to interact with and develop services conforming to the Web architecture. You could build a JavaScript front-end to interact with the process, or have the process tap into services that don't pay the WS-* tax. In certain cases, these resources can be mapped directly to process variables [1]. So that's two, the third ons is still a sandbox project for a task manager, you'll hear more about it in the future.
It's a good idea if we have a common base for all of that, so we don't reinvent the wheel too many times. But a common base that doesn't require any particular language, platform or framework. The wider net you cast the more fishes you catch, or something like that. REST works prettly well for that, so that's the one I want to talk about. REST comes from looking at the Web and the principles that make it scale extremley well. Most people think of scalability in terms of serving billions of requests, but scalability here applies to other factors as well. To serving vast amounts of data, to using tools from the simplest of scripts to the largest of frameworks, to going from plain text to rich content, and the way in which all that variety of services can connect together form the largest distributed system in the world: the Web. That all comes from decoupling clients and servers, by placing constraints on how these are implemented and used, which gives you the ability to scale across all these dimensions. REST is more about constraints than it is about HTTP. When you add PUT and DELETE to a service, when you serve plain XML and JSON, what you're doing is taking advantage of features built into the HTTP protocol. But you can do that and still develop a tight-coupled RPC service that can only be used with framework Foo on platform Bar. There's nothing RESTful about it, not until you decouple the client and server. Unfortunately, there are no silver bullets and no frameworks that come with a "RESTify This" button you can just push to get all the magic happen for you. What frameworks can offer are tools that help you follow the REST principles by taking care of the details, making it easy to work with resources, methods, content negotiation, etc. Those are all features that can help you get the job done. The downside is, most modern frameworks (and no exception I'm aware of), when you let them be in control, have the tendency to do the opposite and couple the client and service. So you have to watch out for the framework, use it, but don't let it be in control [2]. The best way to start is to start small, but always keep an eye on the target. You don't have to do JSON in the first release, just XML may be good enough, but watch out that your data model can map nicely to either one, because XML magically mapped to JSON has neither the benefit of being XML nor the benefit of being JSON. You don't have to do any PUT or DELETE, maybe your first service is just a lot of queries, but watch out that you're not building something that can never accommodate for that. A good idea is to look at REST as an interface and see if you can tear out and replace the implementation without breaking all your clients: are the resources you're using well thought out, or could they only be implemented by FooBar? There's a lot of fascination with XHR, which can be put to good use to enhance a service. But there are also ways to use XHR to hide the service from the world. Can I bookmark this page and return to it later? Can I IM this link to someone else so they can look at it? Can I subscribe to changes from my feed reader or pull this into my calendar? Can I have a widget that shows this content on my desktop? The temptation to build desktop-like applications that are closed off the Web is there, but best ignored. If you want the benefits of REST, always think how to keep clients decoupled from servers, and which principles - not tools - will get you there. Assaf [1] http://ode.apache.org/external-variables.html [2] The exact same problem happens with ORM. When used wisely, ORM tools help you follow the principles of the relational model, while taking care of all the trivialities of mapping tables to objects and associations. But if you let the ORM take over and don't mind what it does, you end up with the worst of both worlds: bad object store with bad relational model.
