Enter The JBoss Matrix Where JBossians blog

I have to admit that I was one of those people who sat through the entire 5 hours of the Oracle/Sun presentations the other day (it seemed longer!) In a way it's sad to see Sun finally set over the horizon, but in another way it has been inevitable for a while and the whole process of the acquisition really couldn't have been drawn out much longer. So there we are: gone is Sun and in its place is Snorcle (or is that Oracun?) But where does this leave the industry as a whole? Well Sun had quite a portfolio of hardware and software, so unlike the BEA or PeopleSoft acquisitions this has potential wider ramifications. But if you listened to the presentations then it's almost as if Sun hasn't really gone away but Oracle is just injecting a lot more cash (and people) into the business.

Well not quite. As many had predicted, the Sun middleware stack (Glassfish and family) has pretty much been banished back to the Reference Implementation plane, because it really wouldn't do to have two competing solutions. Furthermore, in a Geronimo-like approach, it seems that Glassfish will be less capable than Web Logic (read: crippled) because the "departmental" solutions to which it will be directed don't need them (read: bait-and-switch). There were no strong statements about the future of the JCP ("... making the Java community process a more participatory process to people from a variety of different organizations." is too hand-wavy for my liking.) And I think when the various presenters referred to Oracle's "open" platforms they really meant "standards based", since when we talk about "open" in JBoss it tends to me so much more than that.

So at first glance it seems as though this announcement leaves the Java landscape relatively unchanged, if not a little stronger (if you're a Sun customer). But the reality is a lot different, particularly if we look at open source middleware. Before the deal closed there were 4 main EE application server vendors, Red Hat/JBoss, IBM, Oracle and Sun. IBM uses Geronimo in a bait-and-switch arrangement, with their mainstay solution closed source. Oracle, with WebLogic, was obviously closed source as well, leaving the open source space to Red Hat and Sun. JBossAS has remained the number 1 application server for many years, acting as a strong alternative to the closed source equivalents and although Glassfish was obviously a competitor in the community to JBossAS, it rarely was to EAP. But with Glassfish returning to Reference Implementation status, and remaining free of what we consider basic capabilities such as clustering, Oracle is saying that open source is not a core part of their middleware business (it'll be interesting to see how MySQL evolves). The Snorcle future is closed, with all that entails.

It would seem therefore that as far as Snorcle is concerned, those communities can continue to develop whatever they want, but if they need 24x7 support on enterprise-grade software then they're going to have to be prepared to migrate their applications to another codebase. Fortunately that's not been something we've entertained. If you develop on community projects and want to get guaranteed SLAs then the move from project to platform (e.g., JBossAS to EAP) is based on using the same code: everything we do is open source (there's that "open" word again) and based on what our communities help us design and develop in an open way. Quite a contrast to where things now seem to stand with Snorcle. So if you're part of their open source community (users and developers) why not consider coming across to Red Hat? The home of open source!

As the lightning rod salesman said in Something Wicked This Way Comes, "there's a storm coming" and this time it's StormGrind. And like the carnival that was ushered in by the dark clouds in Ray Bradbury's book, StormGrind offers a lot of different things to different people: it's an umbrella project (similar to the approach we took with Overlord, for instance), including BoxGrinder, CirrAS and Cantiere. This marks another important step for us in the Cloud, as we move to (re)define PaaS and SaaS for open source and Red Hat. Congratulations to everyone involved in this effort!

In the movie 2010, Dave Bowman (astronaut, sometime giant baby floating in space and Hal nemesis) tells us that very soon "something wonderful" will happen. Well it happened earlier this week when the final votes for EE6 and all of its constituent component specifications, such as JSR 299 and 303, were counted. As you can see, with the exception of one negative vote, Web Beans, lead by our very own Gavin King, passed with flying colours! Emmanuel Bernard, leading Bean Validation for us, had similar success. Congratulations to them both!

But of course it's EE6 that rolls them all up and it has taken some time for us to get to this stage. It passed with a vast majority of positive votes. There are still some concerns around licensing, which lead to the negative and abstaining votes. But overall this is a major contribution to the whole JEE landscape. We know from the success of Seam and other open source projects we're leading that the community has been shouting for this for a long time. There was a call to allow slimming of deployments to target applications that didn't need the whole EE stack. Yes you could do this for a long time in a non-standard way, but EE6 now standardizes this, which is a far more difficult and yet far more important step. In many ways this is at the heart of our Open Choice effort that we announced earlier this year.

If you look at EE6 compared to EE5 you'll see a fundamental change: the addition of JSR 299. I've mentioned before how this is important to everything we're doing in JBoss in the future, but I recommend you read what Gavin has to say on the subject, since this has been close to his heart for many years! Expect to see a lot more from us on this subject over the coming months and years. This really is a paradigm shift for EE6.

One final word: it's interesting to notice that SpringSource did not cast any votes on EE6 or related specifications. Is it because they didn't believe the work was good enough (you can abstain and leave a comment to that effect if you want), or maybe they realise that with EE6 we've now got an open standard for simplifying the Java Platform? Of course it could be for some other completely unrelated reason(s). Maybe time will tell.

Now that we are coming close to the final release of EE6, which includes some great technologies we've been leading, it's time for us to consider where we want to go in the future on a number of fronts. But the one I'll look at in this entry is probably one of the most important (it's certainly one of the ones most developers will encounter.) What component model should you be using when developing EE applications in general and specifically when looking at JBoss projects and associated platforms? The interesting thing about frameworks, or probably more specifically about frameworks and Java, is that if you ask 10 developers which one they prefer you'll probably get 11 different answers. So obviously you could try to please all of the people all of the time and probably fail miserably, ending up not being able to please any of the people any of the time, or you could take a pragmatic approach and concentrate on a few of the more popular candidates out there that the majority of people are comfortable with, or even better yet, prefer.

Over the last few years we've spent a lot of time and effort on developing a component model ourselves: Seam. Now Seam began life with some very specific goals in mind, but over the years through community users as well as involvement in the JSR 299 standardization process, it has grown in power and popularity. For instance, Seam is now used regularly in our SOA Platform and pulls in more features from other projects such as jBPM and Drools. In parallel we've seen an increasing number of people ask what is the component model that they should be targeting for applications running across different projects and platforms? In the pure EE space there are a number of answers. In SOA there are just as many. What's really needed is something that can unify these various approaches and provide a single solution. Of course there may be times when developers want to or need to stray outside this, but those should be the exception and not the rule.

So this is where Seam comes in: for the majority of users it shouldn't matter whether you are developing on EE or SOA, for example, if the component model is sufficiently powerful and flexible. As I said before, power and flexibility are at the core of Seam, thanks to the excellent work of Gavin, Pete and the team. Therefore, that future for all of our projects and platform is Seam. The team are already working closely with those projects and platforms, such as ESB and SOA-P, to ensure that new versions of Seam take into account their unique requirements. Importantly though, some of those projects had already decided that Seam was right for them even without any modifications to it, so it's likely you will see closer and quicker integration than some thought possible.

But what will this mean for developers, particularly those who don't want to use Seam? Well as I said at the start, we are not abandoning other popular frameworks and will continue to support them as we do today. In fact the Seam team are doing a lot to work more closely with those alternatives, particularly through standardization. But for the majority of our community and customers this will mean they won't have to worry about learning a new component model when they move between platforms. It will also mean that projects can target Seam as the standard for their community, making the work of assembling our platforms from individual projects that much easier and more efficient when the same component model is used throughout. Reusing components will become a reality not for one or two projects, but for them all. And not just now, but well into the future!

Although it wasn't until my keynote at this year's JBoss World that we officially announced the Andiamo Project, it had been going for a while before then. But just what is Andiamo? Well in some ways it's the culmination of a few years of hard soul-searching about precisely what we need to add to the number one open source application server in order to keep it in that position and move it forward. In other ways it's a fairly logical evolution of the direction we've been heading in, albeit slowly until now.

Put succinctly, Andiamo is an effort to improve the out-of-the-box experience of JBossAS by making it easier to configure and manage, more performant than ever before, and all-round easier to use. With the release of AS 5 and EAP 5 we've covered pretty much all of the core capabilities that our community and customers are calling out for, so now they want us to concentrate efforts elsewhere. Yes, we'll continue to add new cool stuff, such as the forthcoming Seam 3 or Blacktie, but most of our efforts over the next year or two will be going on Andiamo, EE6 and That Which Comes Next.

It's worth noting that although we'll be concentrating on JBossAS and EAP initially, everything we do within Andiamo should be applicable to other projects and platforms. So I'd expect to see benefits to projects such as jBPM, Drools and platforms such as Portal and SOA-P.

At the moment most of our discussions around Andiamo have been internal, figuring out the basics and how best to start executing on the aims. However, over the next few weeks and months we'll be reaching out much more to the community and as always we value your feedback. So watch this space and we'll make new announcements about how to get involved. And so it seems appropriate to conclude this entry with: Andiamo!

We announced the availability of EAP 5.0 at JBoss World in Chicago a few weeks back. This was a limited release so we could ensure that all customer feedback had been taken into account and that there weren't any last minute gotcha's waiting to be found. Well it's with great satisfaction that I can now announce we've moved from that phase to general availability of EAP 5.0! Congratulations to everyone who has been involved with this, from engineers, the QE team, the docs people, product and program management, support etc. If I didn't mention your group by name it's simply because there are so many people out there who have contributed to this release. So if you've been considering moving to the latest and greatest open source application server with full enterprise support, now would be the right opportunity. And just in time for Christmas too!

We formally announced REST-* at JBoss World. Yes, the name is tongue in cheek, but maybe just too subtle for some because it seems that there are those people out there who think this is another Evil Empire attempt to standardize things that don't need standardizing. So hopefully this will put that concern to rest (no pun intended!)

Despite what may be read in the media, REST-* isn't something driven by vendors for vendors and it's certainly not intended to become that. It's intended to be driven in a fully collaborative, community open source manner. Bill Burke is leading it for us and anyone who knows him will understand that he's the best guy to ensure that mission statement is retained!

Furthermore, it's not about defining new protocols (remember that hint at subtlety I mentioned above?) Yes, there are a couple of things that we reference that we've been doing in this area, but one of the main points about this whole effort is to document guidelines and best practices for doing things in a RESTful manner (both with and without HTTP). That might include security, management, etc. We're not going into this with the intention to define a new protocol stack as happened in WS-* (there goes that subtlety again!) Far from it! If the only thing we end up being is an aggregator for links to "standard" ways of accomplishing this or that then that's a successful outcome too.

And let's not forget why this was started: because our community wanted it. They kept running up against the same questions and lack of clear answers from various sources such as books, experts in this space and other resources. In some cases they'd get many different answers. Does that mean the answers don't exist? No. But if people who really understand REST can't agree on something then what hope is there for those who just want to go and use it? That's what REST-* is about: bringing together communities to try to come up with clear guidelines so that there's a place for everyone to go when they need those answers.

So why not get involved? That's the best way in which you (vendors, analysts, individuals etc.) could influence this effort. As with any open source effort, this needs to be driven by the community. It needs to be a truly collaborative effort and it's not going to be managed like a vendor driven standards effort. This is much more intended to be driven like JBoss or Apache communities.

If you didn't already know, JBoss World 2009 is almost upon us. Whether you're new to JBoss, one of our existing customers, or just interested in knowing more about open source middleware, this is definitely the event for you. As usual we've got a great line up of presentations from our core developers such as Bill Burke (speaking on REST), Tim Fox (giving us an overview of Java Messaging) and Bob McWhirter (Mr TorqueBox), through to external presentations from the likes of RedPill, Layer 7 and Adobe. I'm giving a session myself around SOA Governance. We've also got some important announcements and keynotes, such as from Geico.

This is the first time that JBoss World has been co-located with Red Hat Summit. That's going to offer some interesting dynamics as you'll get to see the whole picture from a company perspective. You'll hear about things such as Cloud, virtualization, management etc. not just as they impact JBoss, but as they apply throughout everything we do. So if you've never attended JBoss World in the past this is a unique starting point. If you've come before then I believe you'll enjoy the changes this brings.

Finally, as ever JBoss World isn't just about the presentations: it's about the chance to meet the developers, the users and the entire community. This is a great opportunity for our vibrant community to come together and pat one another on the back for doing such a great job over the years. What began in the early 2000's as an effort to redefine middleware and open source has grown into the unstoppable engine of change it is today precisely because of everyone who will be at JBoss World. Congratulations!

JBoss World is rapidly approaching. This year promises to be a very interesting conference co-located with Red Hat Summit. I encourage you to register and attend!

I will be presenting some of the latest on our SOA and business process automation strategy in my session - Competitive Advantage with Open Source Business Process Automation - at 10:50AM, Thursday, September 3.

Abstract

Today's economic challenges and government regulatory turbulence force companies to rapidly respond to change in order to survive. The enterprises that can quickly respond to a changing customer set, demand, and environment will prosper.

Problem - traditional enterprise and web application architecture does not enable the responsiveness that is required today. Solution - Enter business process automation with JBoss Enterprise SOA Platform integration, business rules, and business event-driven architecture.

In this presentation Pierre Fricke, director of product line management at Red Hat, explores how far open source JBoss Enterprise SOA Platform, JBoss Enterprise BRMS and JBoss jBPM have come, and how they help enterprises prosper in difficult and turbulent times.

Additional notes

Beyond the abstract above, you will learn some other things about the economy, history, real estate manias and busts, how businesses can improve in this environment using business process automation, what the "Wizard of OZ" was really about, and even where the icon for the haunted house in the American psyche came from (just in time for the Halloween parties)! :-).

Please join us and have fun!

Today we're announcing RiftSaw, our return to the WS-BPEL space. Ever since I helped write the initial WS-T work and BPEL4WS, I've believed that BPEL is an important part of WS-* and subsequently SOA. Is it perfect? Of course not. In fact since it's initial release I think some of what we did in the OASIS technical committee made it less useable and less interoperable. But the same could be leveled at a lot of other standards efforts then and now.

A few years back we had our own BPEL engine, based on jBPM. Because we needed to focus on making jBPM the best embedded workflow engine around, we decided to not pursue this as a product, though it's still part of our community offerings. Meanwhile we released our own ESB and then SOA Platform, both of which use jBPM for workflow/task-flow, but both of which have a need for BPEL as well. However, it made no sense whatsoever for us to try to do this alone, for exactly the same reasons as were behind our decision to adopt Apache CXF. So where did that leave us? Apache ODE, with its long history going back to PXE from FiveSight was the best open source candidate, allowing us to participate in a thriving community as peers. (The added bonus was that I'd worked with the FiveSight guys back in my Arjuna days.)

We've been working on integrating ODE with our projects and platforms for a little while. This announcement is really to make it official. This is a really important step for us as the combination of Riftsaw, jBPM and Drools will help us to create a world-class offering in this space. I have high expectations for the months and years ahead, both for RiftSaw as a community project and for how we'll extend it and use it within our platforms. If you're interested in SOA, workflow, or just plain BPEL, now is the time to get involved!

Note we're doing a couple of webinars on RiftSaw. They should be available for those who couldn't attend in a few days.

Over the past few years we have made a conscious choice to separate community projects from commercial platforms. Why is this the case? What differentiates between our community and commercial software? Probably the most obvious difference is that we sell support (24x7) on commercial platforms whereas projects are given a best-effort support through public forums. But really there are benefits and trade-offs associated with either option.

Project

With this option the projects are always at the cutting edge. They release frequently (usually every 8 to 10 weeks) and they drive a lot of our innovation. We have many community contributors, in the form of code donations, use cases, feature requests etc. Technical direction is set by a combination of the project lead and the community. Interfaces and capabilities may change frequently as the developers and users of the project learn and shape their requirements based on experiences gained. As mentioned above, the support given to project code is best effort, with help from the community and Red Hat employees where possible. But you should not rely on it being available all of the time. However, this is definitely the place to be if you want to be on the bleeding edge and influence next generation technology and direction.

Platform

The projects try hard to ensure that where there are cross-project dependencies they work well together. However, because they release frequently, this is not always possible. Furthermore, the amount of testing across different operating systems, databases (and their drivers) and VMs that the projects can/should do is limited. As well as the 24x7 support they offer, this is where the platforms come in to their own. A platform is a point-cut of specific projects and is typically many months behind those projects when it is released. The reason for this is the amount of testing and qualification that goes into driving a project to become part of a platform. This can often be between 3 and 9 months of effort. As well as giving this significant testing regime, platforms also provide a very strict evolution path: interfaces and capabilities cannot simply change from one release to another, and not everything that is within a project may be within a platform, e.g., something that was beta quality when the project was accepted within the platform effort will typically be removed by the platform process. If long term stability and support are what you are after then this is the place to be.

• New interceptor model
• GZIP encoding support
• Guice 1.0 support. Thanks Mike!
• XOP and multipart/related support. Thanks Attila!
• Internal dispatching and forwarding support. Thanks Solomon!
• Jackson JSON provider support.
• Asynchronous Job Service
• Client and Server side caching capabilities
• Decorator framework for JAXB
• XMl header and stylesheet support for JAXB
• Greatly improved multipart support thanks to Attila.

For more information follow the links at RESTEasy's Project Page.

For as long as I can recall I've always liked good tools and been infuriated with those that get in the way of me being "creative" or working "efficiently". (Subjective terms, I know.) Whether it was the MetaComCo C/Pascal compiler tools for my Atari those many years back (great customization capabilities) or plain emacs (yes, it's a tool!) I've admired those groups who can make good tools. Over the years I've met many tooling groups from HP, Bluestone, BEA, Microsoft and of course JBoss/Red Hat. Some of the more successful groups have been staffed by a combination of good engineers but also people who have good HCI skills (including psychology backgrounds). But they've all usually had the same comments to make about how tooling is seen by developers: under appreciated and an afterthought. That's a shame because as far as I'm concerned a good tooling experience can bring a better ROI than adding some super cool feature here or there.

I think the key to good tooling is having the involvement of the developers on the product for which tooling is being developed as early as possible. Where I've seen this work well is when there's actually a tooling person sitting in that team full time, learning about the requirements and acting as a conduit to impart that knowledge to the rest of the tooling team. To do it otherwise can often take longer (inefficient?) and may result in something that isn't quite what is required. Despite the fact that they're all engineers, there is often an impedance mismatch between tooling engineers and project engineers; almost a language barrier. But for good tooling to work well, the conversations need to be bi-directional. This is another reason why the approach of having a tooling person sitting in the project works well, as it provides immediacy of responses.

Max, our tooling lead, is keen to say that good tools shouldn't be used to cover up poor underlying projects. He's right! I've seen that happen a lot across the industry, where the tools look fantastic but there's very little under the covers, or what is there is horribly baroque and hard to understand. Designing for tooling from the outset should be considered in the same way as designing for robustness or performance or security. It's not something that is easy to retro-fit.

Good tools (and yes, I count JBDS in that list) also grow with you. Too often I've seen tools that are either way too complex to use for beginners or are so basic as to encourage you to grow out of them pretty quickly and look for something else. (There's a reason I've been using shell and emacs for 20 years.) And of course in this world of ever changing runtimes, you really want a tool suite (or IDE in this case) that can work with more than one at a time: I hate having to fire up different IDEs for different versions of the same product, especially when there may only be a few months age difference between the runtime versions.

Fortunately we have some great people here who are passionate about tooling and understand its importance in making the whole product experience work well. That doesn't mean we've got to that nirvana just yet, but we are on the right path. We need to work more closely with the projects and vice versa in order to push this mantra of thinking about tooling through all phases of the project lifecycle and not just after the fact. The improvements we've made over the past couple of years are pretty significant and there's much more to come. I'm excited and maybe this will finally encourage me to move away from emacs ;-)

BTW, thanks to Max for the title of this entry!