This is a reaction to a) customer demand; and b) the realization that not all the cool stuff is created by JBoss. What we’re also doing is reacting to market demand. Java EE, while hugely successful is not the only game in town any more.

We want to ensure that our customers get to choose whatever frameworks, languages, development models they want without causing major disruption for the operations people who have to manage the applications for the other 90% of the application lifecyle (ie. outside development). We also want to remove the risk of deploying new developer oriented tech. by providing a stable, consistent operational footprint (JBoss) to run the resulting apps.

Note – I normally don’t use Job Trends data in isolation to make serious decisions, but it’s convenient and lazy way to find what keywords are trending.

So yes, this is a reactive move; we’re reacting to customer demand and market pressure – we’re really not reacting to anything that Spring Source is doing. I’ll post another blog explaining what we’re including in our Web Framework Kit and why; but Spring Framework is included for much the same reason as struts – they’re mature technologies and both are very widely deployed :

It’s no secret that a big chunk of our business comes from our much larger but less nimble competitors and we have to ensure that migration is a simple and low risk proposition.

As the chart shows (if you have any faith in the data) – Spring Framework usage is fairly evenly distributed across the Java container landscape. By making JBoss a better place to run Spring (among other things) – I believe that we can change this landscape dramatically.

This really isn’t about Spring Source – in fact we don’t even compete with Spring Source. Our sights are set much higher.

Mainly for my own purposes – the images I use for the header are in this Fickr Set. The Spring image is a close up of a Japanese Maple in our front garden waking up after Winter.

See also Autumn and Winter (I never got around to Summer last year – this year maybe).

• Support for JBoss ESB, specifically the ability to create projects, deploy, debug and manage configurations.
• Improvements to the jPDL Graphical Process Designer
• A new Portlet wizard for creating JSR-186/268 Portlets
• A JSF and Seam portlet wizard
• For Hibernate / JPA – an annotation generator and better integration with DTP (Data Tools Project)
• Support for both Seam 2.0 and Seam 2.1
• A new visual page navigation editor and page navigation birds-eye-view.

For more details see Max’s JBoss Tools project announcement, and the docs.

The second thing we’re announcing is a change to our developer subscription and the introduction of JBoss Developer Studio – Portfolio Edition (or JBDS-PE). This new suite reflects the fact that JBDS has grown from being just a Seam / Java EE focussed tool set to now cover the whole JBoss portfolio – specifically that means the addition of some pretty sophisticated tooling for SOA and Portal development.

JBDS-PE gives you access to JBDS and all the JBoss run-times you need to develop against, access to Red Hat Network for updates   – all for $99 / year.

The next opportunity to hang with JBossians will be at EclipseCon ’09 (Santa Clara, CA – March 23rd – 26th), Max has a list of all the JBoss sessions and the JBoss Tools Meetup. There’s a 10% discount on admission if you’re a friend of JBoss.

Here’s a nice blog post on benchmarking of JBoss Remoting and JBoss Serialization which claims that it’s almost 9 times faster than Java RMI + Java Serialization. Also more on the JBoss Remoting Performance Benchmarking page.

Thomas has started a series on OSGi – the first installment provides a well written and easy to read Technology Overview – bookmark for future installments that cover how to leverage OSGi in JBoss.

A response to my recent post on JBoss AS 5 downloads by Matt Van Bergen of Citytech.

And that, so I’ve been told, was a guiding principal behind the re-architecture of JBoss AS 5.0.0 which was released last week. We don’t know what kinds of applications and services people will be deploying in five years time; we don’t know what frameworks, languages or programming models they’ll be using but we do know that they’ll need to access some ‘core services’ such as data-access, transactions, caching, clustering, messaging, deployment, management, monitoring, etc. And we know we need a modular and flexible core to bind those services together in ways that make sense for the languages and programming paradigms and deployment topologies of the future.

We also know that a single monolithic developer platform for all applications and all customer workloads is not going to be sufficient. At the same time inflicting multiple platforms on the operations organizations who are responsible for the 90% of the application lifecycle that isn’t development is also unreasonable. The operations people see the platform very differently from developers – they don’t want to a new operational footprint everytime a new framework or language comes along – they want stability and consistency.

If this all sounds like vacuous marketing drivel – let’s take a real-life lucid example. Bob McWhirter has been integrating Rails and JBoss using the power of the AS 5 architecture. He’s written some custom deployers, created some shims and a little glue code to integrate existing services and the results are pretty interesting. A powerful Rails environment – without too many compromises for the Ruby developer yet at the same time something that the operations people will be happy with too – ie. a standard JBoss run-time that behaves just like the other JBoss deployments whether they’re Java EE / Seam based or Spring or POJOs. And check out the “web” configuration – another example of what’s not only possible but actually pretty straightforward to acheive with the Microcontainer and modularized services in AS 5.

I think the next couple of years will demonstrate that AS 5.0 has been a wise investment as other vendors will struggle to retool and stretch their run-times to meet customer demands for increased choice and flexibility.

Bob McWhirter has been playing around with Ruby and JBoss – here’s his first progress report. The start of something cool I’m sure.

JAX-RS (aka JSR 311) is approved – now we just need a TCK. Bill has just released beta 8 of RestEasy and also posted some REST inspired articles on DZone (Intro. to REST, Putting Java to REST). Bill also provides some sage and hard-earned advice for Rod Johnson – I agree, and said this a while back – monetizing OSS is about more carrot and less stick.

Over on the JBoss Portal blog – there’s some nice horizontal scalability testing results. Portal is getting a real shot in the arm – we have a new Product Manager (thanks IBM) and a new project lead and the team seems pretty fired up. We even made Gartner’s MQ for horizontal portals – not bad given the young age of the project.

It’s great to see the innovators rallying around such a good cause – but look at the dates !

“provide an up-to-date server model that gives enterprises the features they want.”
- Rod Johnson, Spring Source CEO – April, 2008 [link]

“GlassFish v3 has a modular, lightweight, extensible architecture”
Sun Employee, glassfish.net – June, 2008 [link]

“JBoss’ modular architecture means customers can also choose the features they want, instead of installing a full J2EE application server on devices with limited processing and memory capability.”

Marc Fleury, JBoss CEO, December, 2002 [link]

In a way – it’s sad that a perfectly decent product launch is over-shadowed by their choice of license – we (the OpenSource community) still clearly have work to do.

I haven’t decided whether their choice to dual license is smart or dumb and I also wonder if it was done with BEAOralces blessing – presumably they we’re a good partner at one point. Clearly SpringSource think they’re in a dominant enough position to make such a change – I guess their consumers will decide.