Sunday, April 27, 2008

To Spring or not to Spring

Just got back from a few days in the Netherlands and Belgium, where I gave technical sessions at a few knowledge events organized by our partners in the region.
One of the events was held by our Dutch affiliate, Tricode, which did a great job in setting it up and attracting quite a few developers and architects to it. We even have a GigaSpaces Dutch web site now which Tricode guys have set up for us - so thanks guys.

One of the questions I got after the session was something in the following spirit:
"Sure, Spring is great and OpenSpaces integrates very nicely with it which is great. But what if I don't like all this XML in my project, or just (imagine that) don't use Spring but still want to use OpenSpaces APIs which are clean and nice"?

Of course, you can always "imitate" Spring and call the OpenSpaces Spring factory beans from your own code, but that's not very clean and will require you to dig through the OpenSpaces code to understand how things work.
Thankfully, you have another option - OpenSpaces configuration API, aka OpenSpaces configurers. It's fairly new (6.0.2 onwards) and therefore is still relatively unknown to many of our users.

Some (pretty recent) History

Up until version 6.0, the preferred API to use GigaSpaces was JavaSpaces with proprietary extensions. In 6.0 we introduced OpenSpaces, which greatly simplified things and made the user experience much more positive by abstracting away lot of the API problems and inconsistencies.
From day 1, OpenSpaces has been all about Spring: It uses Spring for configuration and utilizes a lot of goodies that Spring provides such as transaction management framework, namespace based configuration, etc.
But since OpenSpaces' goal is become the preferred Java API for the product, the fact that you can only use it through Spring was a bit limiting to some of our customers and prospects.
In addition, the trend towards code based configuration (first with Guice and now also with Spring Java Config) also made us realize that we need a way to use OpenSpaces interfaces without wiring them through XML.

Configurers Demystified
So here are a number of snippets to show you how this is done. Let's first show the Spring equivalent creating a space instance and then wiring your listener on top of it using a polling container:
<os-core:space id="space" url="/./space" />

<
os-core:giga-space id="gigaSpace" space="space"/>

<
bean id="simpleListener" class="SimpleListener" />

<
os-events:polling-container id="eventContainer" giga-space="gigaSpace">

<os-core:template>
<bean class="org.openspaces.example.data.common.Data">
<property name="processed" value="false"/>
</bean>
</os-core:template>

<os-events:listener>
<os-events:annotation-adapter>
<os-events:delegate ref="simpleListener"/>
</os-events:annotation-adapter>
</os-events:listener>
</
os-events:polling-container>

The above XML snippet creates a space and registers to get notified on all objects of type Data whose processed field equals false. Here's how this is done in java code, via configurers:
//creating a space
IJSpace space = new UrlSpaceConfigurer("/./space").space();
//wrapping it with a GigaSpace
GigaSpace gigaSpace = new GigaSpaceConfigurer(space).gigaSpace();
//creating polling container
Data template = new Data();
template.setProcessed(
false);
SimplePollingEventListenerContainer pollingEventListenerContainer =
new SimplePollingContainerConfigurer(gigaSpace)
.template(template)
.eventListenerAnnotation(
new SimpleListener())
.pollingContainer();

That's it. as you can see, it's even simpler than the XML equivalent.
A few interesting things about this:
  • All our configurers use method chaining, which makes them very intuitive to use. It's about as close as you can get to domain specific languages in pure Java :)
  • There are configurers for all of the OpenSpaces constructs, specifically: Space, GigaSpace, Event containers, Remoting Proxies and Scripting Proxies.
Where is this documented?
Every OpenSpaces docs page includes XML snippets that show the configuration.
Every such XML snippet is displayed in a tabbed pane, which typically has 3 tabs:
  • Namespace - which stands for the default configuration using Spring's namespaces support.
  • Plain XML - which shows how to configure the component via pure spring, without GigaSpaces specific namespaces
  • Code - which shows how to configure the component using configurers
Here's a screen shot to illustrate this:

Sunday, April 6, 2008

Impressions from MuleCon 2008

Just returned from San Francisco, where I gave a session about Mule and GigaSpaces integration at MuleCon. Although I'm still recuperating from the loooooong trip (about 18 hours each way) and the time differences (10 hours if really want to know), I think it was worth while attending the conference.
I think the MuleSource guys did a great job, and the conference was quite packed.
About 200 developers and architects from around the world attended and it was interesting to see the profile of Mule users and what people are doing with it.
Many of them use Mule mainly as an integration and messaging platform - i.e. bridging between applications, but some are also using it as a hosting platform for single applications. This enables better decoupling between application components and makes for a more flexible application which is not bound to any specific middleware product. In GigaSpaces we refer to this as intra-application SOA.
I think we managed to generate nice interest with regards to the GigaSpaces-Mule integration package, which essentially lets you scale out your Mule application in a very clean and non-intrusive way.
There are 3 key value adds that GigaSpaces can provide to Mule users:
  1. High availability: making your Mule application highly available and fault tolerant, and maintaining in-memory and SEDA queues on top of the Space instead of just in memory. This allows your application to enjoy in memory performance and still maintain resilliency and HA. It means that after failover, your application can start working from the exact point that the failure took place and not loose any in pending in-memory messages.
  2. Scalable transport: Use GigaSpaces messaging capabilities to obtain high throughput, low latency and extreme scalability for your messaging layer.
  3. SLA driven grid based deployment: Use GigaSpaces service grid and SLA driven containers to enable declarative SLA, self healing and dynamic deployment capabilities for Mule applications.
Personally, the most useful part for me was the technical sessions by Mule developers and architects in which they showed the new features in Mule and other products they're working on like Galaxy, HQ and OSGi support. I especially found useful the sessions by Travis Carlson, Daniel Feist and Dan Diephouse - nice job on Galaxy and 2.0 guys :)
There are a few similarities between our own grid infrastructure (specifically what we refer to as the Grid Service Manager or GSM for short) and the planned capabilities for Galaxy in the next Mule releases (hot deployment and netboot to name two). We intend to cooperate with MuleSource to make sure our offerings are as aligned as possible in that regards, although this is still a very early stage to be able to tell how this will evolve.
Another interesting session was the enterprise infrastructure panel, in which various aspects of open source as a model for enterprise infrastructure were discussed.
The commercial open source model still has to be proven as a sustainable business model (and not as just a successful exit strategy) but there are certainly some convincing arguments raised in the session in favor of this approach.
For one, it is clear that at the end of the day, an organization seeking support and indemnification will invest money in the software (be it open or closed source) - I'm sure MuleSource guys would agree with me on that. But according to the panel, what makes open source more appealing in that regards is that the need is pushed from the bottom by developers and architects that just download the code and use it. So when approaching procurement to get budget for this, the fact that the open source libraries are already there and are used in the code makes a much better incentive for them vogons at procurement to approve the budget.

That's it for now. If you want to get more details about our integration with Mule just drop me a line here and I'll get back to you with more details.