Moving on ... to the Cloud

As wrapped up yesterday, I have left BEA now Oracle after 6+ great years there.
I am joining VMware to help adoption of VMware Platform-as-a-Service product line - especially across EMEA.
I'll be part of the SpringSource division, acquired by VMware back August 2009 for 400+M$.

This is a fantastic time to join the team - and I am glad that I can build upon ALL what I have been working on those past years - both technical and sales side - as well as learn and drive a massive amount of new things.
Here is the way I see it:

VMware is at the forefront of fundamental yet evolutionary shifts in the way we build, run and manage enterprise applications and deal with computing resources and services.

I'll hopefully be able to write more on that journey in the next few posts.

Moving on

Those last 6 years that I have been working at BEA now Oracle have been fantastic. I did had a great run there, in various positions both engineering and sales side.

It's time to recap a bit.

I have been a bit of:
- technical-crazy enough to discuss open source AOP gory details with then JBoss CTO on ServerSide, and to also compile a JRockit JVM on my own for our AOP-in-the-JVM prototype derived from our AspectWerkz work (2004-2006),
- lucky enough to evangelize emerging trends such as AOP, POJO and lightweight containers across the world back when Java(TM) was still a Sun trademark,
- unlucky yet professional enough to work with fantastic people who ended up being successful faster than me onto there I21/SpringSource/VMware journey
- and business-crazy enough to end up in the category of software sales, in fact getting our largest customers to adopt our products - from WLS to emerging SIP and SipServlet, real time Java, CEP containers, up to bare metal Java running straight onto hypervisors such as VMware (a number of those RIP or rescheduled as part of BEA now Oracle - as you can figure out) and last but not least data grids.

Along that path I made sure to revitalized my open source hat by giving time and knowledge to bootstrap a niche open source project to a sustainable pure-play open core CEP Java leader aka Esper & EsperTech. A fantastic geek+BizDev mix with great talented individuals all the way along. If you wonder, Esper / EsperTech is playing the open-core business model in a fairly interesting way.

I am now onto something next - and I already feel home like always been there - more on that next one soon.

Esper - what and why in Complex Event Processing

I have been generating this definition out of the word cloud image generated from Esper documentation:

An engine to query streams of events using select statements over time windows and pattern expressions.
(by streams of events you need to think continuous queries vs traditional store and later query analytics)

Esper is actually much more capable - especially in the just released Esper 3.2, that for example brings support for a subset of nascent not finalized ANSI SQL standard match_recognize.
The Esper 3.2 documentation has a nice summary on how match_recognize compares to Esper well established select from patttern[ ... ] and followed-by EPL language features.

It is also great to see EsperTech on the Forrester Wave Complex Event Processing Platforms, Q3 2009: "Forrester evaluated nine complex event processing (CEP) platforms using 114 criteria (...). EsperTech, the only open source option, is also a Strong Performer."

Esper, OSGi and Complex Event Processing

There is an interesting article that discusses the pros and cons of integrating OSGi with Esper to achieve modularity and dynamicity beyond what Esper already provides.

The article goes over comparing 3 scenarios and comes with sample code (and complete source, with Maven and Eclipse artifacts)

1. Exposing Esper runtime and administrative interfaces as OSGi services
2. Layering Esper interfaces as OSGi services through some service provider abstraction
3. Using Esper and the OSGi EventAdmin service specification
   

This third approach although a bit more complex for readers without OSGi background is the recommended one by the author - Valery Abu-Eid.

It is nice to see such exploration going on. I know we already have users running Esper in OSGi environment, although the vast majority is still running on bare JSE JVM or on JEE / servlet container stacks.

Readers familiar with the matter will also notice that WebLogic Event Server (now Oracle CEP) - is also leveraging OSGi. A main difference is that Esper does not mandate OSGi at all while the BEA/Oracle product does mandate end users to author OSGi modules - with pros and cons.

If you have experimented with similar stacks I'd be pleased to hear about your experience.
There is also good material available from the DynamicJava.org site to get started with OSGi based runtimes - including their own OSGi stack.

Read more about Esper and OSGi experiments at DynamicJava.org

CEP engine or CEP platform? Or both?

There has been recurrent debate and opposition between the value proposition of a CEP engine and a CEP platform.

The archetype of a CEP engine would be something like Esper. You can fully embed it in an existing runtime (Java or .NET/C# for NEsper), ranging from standalone JVMs with bare metal thread pools to JEE application servers or SOA stacks.
The archetype of a CEP platform would be something more like Streambase, or the Oracle CEP server or well you name it - where the product is a server - no choice - sometime even worse with a whole bunch of dependencies (for example a relational database and/or a mandatory JEE application server - see IBM Business Events for example).

I am firm believer that there are numerous technical advantages of getting started with Complex Event Processing using a CEP engine.
Check out the Esper examples (one integrates with JMS f.e. TibcoEMS, another with JBoss, etc) or the growing list of ISVs embedding Esper into their own solutions - from asset tracking, network security and trade platforms of all kinds.
More control and flexibility and more reuse of your existing investments.
This also fits well if IT, speed and flexibility is a competitive advantage - which for example was echoed in a recent WallStreet & Technology article:

Wall Street Opens Doors to Open Source Technologies
"Esper is already built. Instead of being a standalone server product that runs as a separate product, it's a library that you link in with your own proprietary stuff. That way you don't have to worry about another additional process." (an industry source who is involved in the development of trading systems at a major investment bank)

Needless to say, things are not black or white. I am also a firm believer that there are numerous long-run advantages of scaling up your CEP use through a CEP platform approach. Enforce shared practice for monitoring, high availability, deployment unit management and consistency across projects.
Interestingly, Esper tackles this through its (commercial) Enterprise Edition - with bells and whistles around management, tooling and high availability.
More enterprise *ilities and more wisdom long run - likely.