Smooks improvements and futures

If you're a JBossESB user then you've probably used Smooks, which is our default transformation engine. Unlike other ESBs that may only give you XSLT based transformations (perhaps as an afterthought to their architecture), Smooks provides much more than this, and transformation has been at the heart of our architecture since the start. Anyway, Mr Smooks (aka Tom) has been describing the future for Smooks and within our ESB. Definitely worth a read. It's nice to see that others are getting in on the act. What's that they say about imitation and flattery ;-)?

Cloud Computing and the ESB

Whether you call it Cloud Computing, Grid, utility computing, ubiquitous computing, or just large scale distributed systems, computing devices are everywhere. These days I have a mobile phone that is more powerful (processor and memory) than the laptop I had 10 years ago. I suspect my fridge is more powerful than my old BBC Model B computer! Having spent a lot of time working in large-scale distributed systems, the basic requirements are pretty similar: develop objects/services, publish, locate and use. Doing this in a transport agnostic manner is very important as well: how many services running on a mobile phone support JMS? But as a service developer do I really need to tie my service to a specific transport? That breaks reusability: the service logic (excluding transport) should be useable in a variety of different deployments, assuming its dependencies on 3rd party bindings are present (e.g., no good deploying a service on a mobile phone if it needs a local Oracle instance to execute!)

What you need to support cloud computing (for want of a better term) is an infrastructure that allows you to develop your services without having to worry about where they will be deployed. Furthermore, if you can compose services from other services and (re-)deploy them dynamically as your requirements change, that would be a benefit. Many service deployments need to change over time, if for no other reason than machines may fail or performance improvements mean that you want to move a service from one machine to another. Or you may need to deploy more (or less) service instances over time to improve availability. Interestingly some of this overlaps with governance.

You also need to be able to cope with dynamic routing (service locations change and you want to route inflight messages or messages sent to the old address, to the new location). Transformations of data are pretty important too: sending Gigabytes of data to my services that has been deployed on the mobile phone might get a bit costly, but maybe my infrastructure can prune that information while it is inflight and only send a synopsis (or some portion of it that is sufficient for the service do do meaningful work).

Ultimately the service deployments and how they are related to the devices that are available to the infrastructure should be handled automatically by the infrastructure, with the capability to override this or provide hints as to more appropriate deployment choices (e.g., "please don't deploy this service on a mobile phone!") The infrastructure then becomes responsible for managing those services, guaranteeing specific SLAs (so it may mean migrating a service from one device to another, for example, to maintain a level of performance or availability), pulling in more devices or distributing more instances of the service across multiple devices, again to maintain policies and SLAs.

Overall the infrastructure and the way it supports development of services assists in the realisation of loosely coupled, non-brittle applications. By this point you may see where I'm going with this. In my opinion a good infrastructure for cloud computing is also a good infrastructure for SOA, i.e., an SOI. In our case, that would be JBossESB as it continues to evolve and improve. Stay tuned!