Hot on the heels of my previous entry praising the JBossAS team, the team go and do it again! This time they've achieved EE6 web profile compliance and have tagged the code! Of course an official release may not appear until the new year, but this is great news. I don't want to spoil the surprise too much, so expect to see a lot more said about this release from the team once it comes out in January! Once again congratulations go to the entire team (core developers, docs, managers, QA etc.), who pulled together to make this a reality. And on Christmas Eve no less! It's almost certain to be a merry Christmas and a very happy new year!!

It's been nearly two years since Sacha left and "passed the baton" to me. As instructed, I think/hope that I didn't "screw it up", as he requested ;-) It has been a very eventful 18 months or so and I continue to be indebted to Sacha for selecting me as his successor. Over this time we've seen some of our competitors get acquired, the release of Java EE6 (which we pioneered with CDI and Bean Validation), the start of a new JBoss developer conference series, some acquisitions, countless project releases, new standards efforts, adoption of newer languages, and new projects being created, and many new product releases. In short, it has been a very busy year and a half!

My thanks go out to everyone involved in what I have mentioned above. It would take an entire blog entry to mention them all and even then I'd probably miss out some, so I won't even try. Each of our projects and platforms has a thriving and growing community of contributors. Whether those contributors cut code, provide docs, log issues, comments, use cases, or whatever, whether they are Red Hat employees or work for some other company, they (you) are all part of the greater JBoss community and critical to our (your) success. And over this last 18 months I've been in the privileged position to monitor all of these efforts in one way or another, and sometimes help where I can. I've seen the communities grow and the core developers thrive on the challenges that their communities offer. In a word, it has been fun!

I've also watched out competitors increase their FUD against us (queue Richard Burton's voice and the ominous music from Jeff Wayne's War of the Worlds!) Our market share has increased over this period. Our communities have increased over this period. But probably the most telling thing that shows how much of a threat we are to others in the enterprise Java middleware space is the amount of FUD that has also increased in this period. As I said in a separate blog, "I suppose [FUD is] easier to do than actually provide significant technical differentiation"! Yes FUD is annoying, but if you take the time to step back and think about it, it's actually quite flattering that you (we) have gotten to the point where companies large and small have to resort to it in order to try to retain their market share! JBoss and open source is a major player in middleware, whether you are looking at traditional deployments or new arenas such as Cloud.

So in the last 18 months I've definitely had "fun". But I suppose if there's one downside of Sacha (and Marc's) legacy, it's that I have less time to spend on actual coding. Or at least that's what I was worried about when I had to weigh up the pros and cons of taking over. Although it turns out that I don't have as much time for cutting code as I once had, I still manage to do it. (Which reminds me, I hope that my transaction addition to TorqueBox makes it into the trunk eventually ;-)! I think it's important to keep coding, particularly in an environment such as JBoss which is heavily engineering driven. Plus it helps keep my grounded as well as sane :-)

Back in March 2009 when Sacha asked me to take over, I recall thinking that this could be either the best move I could make for JBoss or the worst. It wasn't an easy decision to make. But now, almost two years on from that date I think I made the right choice and have to thank him and the wider JBoss community for a wonderful journey! If the past is any indication of the future then bring it on!!

Rich Sharples gives a pretty good overview of our product lifecycle in response to some FUD from Snorcale. As a slight aside, I love it when certain Closed Source companies preach to us and the communities about open source: the words "grandmother" and "sucking eggs" spring immediately to mind! Anyhow, FUD is something that we've seen rather a lot of in recent times; I suppose it's easier to do than actually provide significant technical differentiation, and it's nice for us to keep disproving it!

As I said, Rich's post is a good overview. But some of the things that are implicit in it need a bit more explicit discussions. For a start, the open source communities are extremely important to us and we try not to do anything that would affect them adversely. Everything that we do during the productisation process in terms of bug fixes, feature improvements etc. goes back into the community releases. We are not a closed source company that periodically dumps our code into a public repository.

The communities, whether they are comprised of people who contribute code, let us know about bugs, or give us use cases and requirements, are critical to the success of our projects and hence our products. Of course we recognise that not everyone will want to purchase a support agreement from us and will be confident enough to self-support. Those individuals and companies are still important to us; they're still a mark of success, both for us and for the community at large! If you listened to some of the FUD you'd think that we walk all over the communities once we get what we want, i.e., the code. Nothing could be further from the truth; just take a look at JUDCon for example. Of course you can't please all of the people all of the time, but to think that an open source company such as Red Hat would do anything to mess with its communities is crazy. I think it shows that companies such as Snorcale are having to resort to the Chewbacca Defence in order to try to confuse everyone and distract them from their own issues around open source.

Another thing that is implicit in Rich's description, is what we like to term "baking in the community": this is where the community (including our employees) works to ensure that each release of a project (and hence a subsequent product) is fit for purpose. Our communities feed requirements into each project release via forums, JIRA, emails etc. The development teams, which may well include community developers as well as our employees, then work on any associated new capabilities, or bug fixes, and turn those into new project releases. The communities then take those releases and kick the tyres, providing feedback on what's good and what's bad, what works and what doesn't. As a result, it may be many months, or several project releases, before the project teams and their communities are happy with a particular feature. This is baking in the community, and only something that's been suitably baked makes it into a product.

All of the above should help to illustrate some of the trade-offs that are inherent in our approach. The communities are always getting the cutting-edge features and capabilities, some of which may well have been added by our developers on behalf of customers, as well as all bug fixes that we may find during productization. The community releases move forward relatively quickly compared to the products, because we spend a lot of time in the productization process, which might include removing some things from the project releases that aren't quite ready yet, e.g., they haven't had enough bake-time. Those who purchase support for our products (platforms) get a slower moving beast, that offers guaranteed stability over a much longer period of time; it may be months or years before they gain access to the feature set that's available in a project.

So in conclusion, we believe the model we use is able to walk that line between project needs and platform needs. It's something that we have been working on for a few years, but which we do evaluate based on feedback from all of our community members, including product customers. It has allowed us to grow our offerings substantially over the past 4 years and retain our leadership position. So let's see how the next 4 years plays out.

JavaOne is over for another year and it was a mixed bag. It was the first JavaOne where Oracle was in charge and for one reason or another they decided to co-locate it with OpenWorld. I can't believe it was for monetary reasons, given how much they must have paid for the Black Eyed Peas, Lance Armstrong etc. I suspect it was more to do with stamping their authority on the Java landscape and distancing from the old Sun days. So this was the first JavaOne that wasn't held at the Moscone: that honour went to OpenWorld attendees. (I went to Moscone on several occasions, for old times sake, and it seemed as busy as JavaOne in the past.)

But JavaOne was split across several hotels, with many different meeting rooms used for the presentations and vendor pavilion. As a result, it was difficult to get a good feeling for how many people were at JavaOne this year: gone was the feeling of size that you got in the past when moving between Moscone North and South, replaced with only knowing how many people were in the session you'd just attended. The atmosphere was also different. Yes, there was some of the old JavaOne buzz, but it really just felt like yet another conference on Java, not the premier event it had been in years gone by.

Now don't get me wrong: the sessions I attended were great; probably better than many I'd seen in previous years. So even if JavaOne is relegated to "just another Java conference", it was still a good conference! However, I think that many of the people attending, both presenters and audience, were still expecting the old JavaOne and gave it their best efforts to help achieve a semblance of those days. All of the sessions I attended and gave were packed, which is different from previous years (though perhaps I just chose better this time). But the overall atmosphere was heavy with Oracle pixie dust, doing it's best to ensure we all understood that Java Is Under New Management.

As for JBoss, well we had many sessions and BOFs this year. Hopefully a good sign of things to come, assuming JavaOne continues next year. Our booth at the vendor pavilion was always packed, and unlike other booths, not with our own people! We ran a very successful succession of booth presentations, where core developers (and I still include myself there!) talked about a range of topics. The feedback from everyone who listened in was positive and I've never seen our booth or teams manning them as busy as this year.

And of course it wouldn't be JavaOne without a JBoss party. Now we may not have been able to afford Will.I.Am et al, but that didn't mean we couldn't have fun! The team selected The Slide, an old Speakeasy, with a real slide used to access the lower floor (yes, I and several others used it just to be sure it was working ;-). Our party was packed with people from across the industry divide, and from what I heard, to the detriment of several other parties that were going on at the same time. Yes, I think that despite JavaOne not being quite the same, the JBoss party was on a par with some of the best we've had in the past!

For several years we've been working with other industry experts on the WS-CDL specification as well as utilizing an implementation of the principles it represents. One way of thinking about what this work brings is that it turns the art of developing reliable and correct distributed systems into a science. As discussed a couple of years ago back on InfoQ, it can be likened to the industrialisation of IT. One of the principle co-authors of the CDL specification has written quite a bit about the benefits (often significant) of testable architecture to a range of clients he's been working for over the years. (There's even a pretty nice short video presentation.)

Originally this work was being done under the Overlord project, but about a year ago we decided that it made more sense to separate this out into a separate project, Savara. The aims remain the same, but the scope is no longer just SOA governance. Testable architecture (and WS-CDL) has a lot to say about workflow systems (choreographies, after all), and BPMN 2. In fact, I remain surprised and disappointed in equal measure that the other major players in SOA and BPM continue to push tools and methodologies that remain closer to black art than 21st Century science. However, this hasn't prevented a lot of people and companies being interested in what we're doing collaboratively. And the next major milestone has just been reached with the announcement of the first release of Savara! If you aren't monitoring this effort then you should be.

I mentioned at the end of last year that we're putting a lot of emphasis on improving our usability, out-of-the-box experience, performance, management etc. within a new project called Andiamo. Well I'm pleased to announce that we now have an official project space on JBoss.org. If you're at all interested in helping make our projects and platforms even better, then please get involved! Thanks go to Andy Miller for leading this!

It seems to some people that JBoss and Red Hat are late to the Cloud and missing investment. I don't think anything could be further from the truth. I'm going to try to set the record straight here and if you want more details then you should come to JUDCon (free to attend) or JBossWorld, where you'll hear a lot more about Cloud. I'm also going to be slightly lazy here and copy some texts that I've already written on my personal blog around this very subject.

Before going any further I think it's very important to put Cloud into context. As I said back in February, and presented at the Middleware 2020 event, Cloud is not the death of middleware or some grand new approach to distributed systems that breaks the mold. It's a pretty natural evolution if you look at what's been happening with hardware over the last 40 years as well as software, with the likes of SOA, and offshore movements by companies to save costs. But middleware, and more importantly enterprise middleware, will continue to play a critical role here. Now is not the time to throw away investments in software and people by jumping on the latest case of Emperor's New Clothes syndrome:

"Implementations such as Google App Engine are interesting toys at the moment, offering the ability to deploy relatively simple applications that may be based on cut-down APIs with which people are familiar in a non-Cloud environment. But I'm fairly sure that if you consider what consistutes middleware for the vast majority of applications, the offerings today are inadequate. Now maybe the aim is for people who require services such as security, transactions, etc. to reimplement them in such a way that they can be deployed on-demand to the types of Cloud infrastructures around today. If that is the case then it does seem to solve the problem (bare minimum capabilities available initially) but I take issue with that approach too: as an industry we simply cannot afford to revisit the (almost) NIH syndromes that have scarred the evolution of middleware and software engineering in general over the past 4 decades. For instance, when Java came on the scene there was a rush to reimplement security, messaging, transactions etc. in this new, cool language. The industry and its users spent many years revisiting concepts, capabilities, services etc. that existed elsewhere and often had done so reliably and efficiently for decades, just so we could add the "Java" badge to them. OK, some things really did need reimplementing and rethinking (recall what I said about evolution), but certainly not as much as was reworked. This is just one example though: if you look back at DCE, CORBA, COM/DCOM, .NET etc. you'll see it has happened before in a very Battlestar Galactica-like situation."

Now this doesn't mean the exact same middleware platforms we have today will be used in 5 years time. If you look at today's platforms and compare them with their counterparts from 5 years ago there are many changes. Things evolve, not just life, and Cloud is certainly a factor in the evolution over the next few years. But the fundamental requirements placed on middleware in the Cloud will be the same as placed on any kind of distributed system. Yes, there may be architectural changes to better accommodate the large scale nature that Cloud offers, improvements in security (critical if you're going to offload your data and not just stateless computations) and fault tolerance, but underlying them all will be mature implementations from a range of vendors. And JBoss has spent the last few years rearchitecting our application server, for instance, to help us address many of these things. The JBossAS 5 architecture, with the Microcontainer, allows us to have a real services based platform, with minimalist profiles and shared servers, which is precisely what you need in both public and private Clouds.

"What I'm particularly after is a services architecture that CORBA espoused but which many people overlooked or didn't realise was possible, particularly if they spoke with the large CORBA vendors at the time: an architecture where the services could be from heterogeneous vendors as well as being based on different implementation languages. This is something that will be critical for the cloud, as vendors and providers come and go, and applications need to choose the right service implementation dynamically. The monolithic approach won't work here, particularly if those services may need to reside on completely different cloud infrastructures (cf CORBA ORB). I'm hoping we don't need to spend a few years trying to shoehorn monoliths in to this only to have that Eureka moment!"

You should expect a lot more of this from us as we move through JBossAS 6 and into JBossAS 7. We may not be as vocal as some, but we've been tracking these evolutionary changes for a lot longer than most. But of course there are almost daily announcements from others about Cloud-this or Cloud-that. Lots of nice words, but still leaving a lot unstated, and perhaps deliberately so.

"But there are still a number of uncertainties around where this new wave is heading. One of them is exactly what does this mean for applications? On the one hand there are those who believe applications and their supporting infrastructure (middleware) must be rewritten from scratch. Then there are others who believe existing applications must be supported. I've said before that I believe as an industry we need to be leveraging what we've been developing for the past few decades. Of course some things need to change and evolve, but if you look at what most people who are using or considering using Cloud expect, it's to be able to take their existing investments and Cloudify them.

This shouldn't come as a surprise. If you look at what happened with the CORBA-to-J2EE transition, or the original reason for the development of Web Services, or even how a lot of the Web works, they're all examples of reusing existing investments to one degree or another. Of course over the years the new (e.g., J2EE) morphed away from the old, presenting other ways in which to develop applications to take advantage of the new and different capabilities those platforms offered. And that will happen with Cloud too, as it evolves over the next few years. But initially, if we're to believe that there are economic benefits to using the Cloud, then they have to support existing applications (of which there are countless), frameworks (of which there are many) and skill sets of the individuals who architect them, implement them and manage them (countless again). It's outsourcing after all."

The Cloud will be driven by workloads. And if you look at Java specifically, the majority of those workloads run on a Java EE application server of one form or another. That could be a closed source commercial offering, a support-subscription one from ourselves, or even just the free community version(s). Why is this so? Because of what I said earlier: enterprise applications require enterprise middleware. Yes some people try to start of simple with a Web server here and a messaging component there, then throw in a database, transactions and a smattering of security for good measure. And before you know it you're running an application server in all but name, with the headaches of addressing cross-component interoperability that these ad hoc solutions tend to throw in your direction at all times of the day and night.

Now one of the things I hear a lot about the latest range of Cloud hype is "simplicity". But what exactly does this mean? Well in the immortal words of Inigo Montoya: "You keep using that word. I do not think it means what you think it means." If you dig deep into these announcements I don't think it's simplicity for existing workloads. Neither is it simplicity for management. It may be simplicity for POCs though.

"if you want to move to this type of cloud then you'd better be expecting to re-code some or all of your application. Oh joy. Here we go again! Even the tag line of "... write once, deploy anywhere" is a lot of smoke-and-mirrors. "Deploy to any one of four vendor specific Clouds, but don't forget about the lock-in potential there" would be more appropriate."

If you're after simplicity for development then things don't come much simpler than Seam. And regardless of what some may believe outside of the JBoss community, Seam is central to almost everything we are doing, whether or not Cloud related. And guess what? Seam and Weld, the CDI reference implementation, help you avoid the vendor lock-in because they're based on standards. Yes, standards! Those things that many of us take for granted and which some vendors carefully avoid, stymie or simply ignore for expediency. And yes the word standard has a well defined meaning, it's really not open to arbitrary interpretation!

"Maybe it's simply due to where we are inthe hype curve, because I can't believe that developers and users are going to throw away the maturity of thought and process that have been built up over the past few decades concerning standards (interoperability, portability etc.) Or have the wool pulled over their eyes. Of course we need to experiment and do research, but let's not ignore the fact that there are real standards out there that either are applicable today or could be evolved to applicability by a concerted effort by many collaborating vendors and communities. You don't want to deploy your applications into a Cloud only to find that you can't get them back or can't integrate them with a partner or customer who may have chosen a different Cloud offering. That's not a Cloud, that's a prison."

So back to what started this discussion. Are we late to Cloud? Are we ignoring key projects like Seam, when it comes to Cloud? Are we ignoring standards? Is Enterprise Java missing from the Cloud? The answer to all of these questions is a resounding NO. You only have to look at efforts like BoxGrinder, TorqueBox, CirrAS, CoolingTower, Infinispan, the Data Services Platform, HornetQ and many many more to understand why that is the case. Our investments in these areas has increased significantly over the years. What's probably missing is our ability to vocalize these efforts more and evangelize them. But hey, if you're actually working on kick-ass products you tend to find it hard to talk about them as often as you'd like!

I mentioned earlier this month that we were going to be starting JUDCon (an event "by developers and for developers"). Well we've managed to pull everything together and the community pages for JUDCon just went live today!

Take a look at the two tracks we have defined so far (a third, which the community can help to fashion, is TBD so start submitting preferences). We've got people like Jason Greene (JBossAS lead), Pete Muir (Seam and Weld) and Bill Burke (RESTeasy) talking on the Application Server Track, and Bob McWhirter (JBoss Cloud and TorqueBox), Manik Surtani (Infinispan) and Thomas Heute (Portal) talking on the Cloud/Portal track. These presentations will be interactive and technical, so if you come you should expect to be educated and entertained in equal measure. We've also got two Hackfests that will run after the sessions and go through to the early hours of the following morning. (More details on them in the coming weeks.)

If you're a developer or someone who wants to know how the things you use work and are considering attending JBoss World or Red Hat Summit, then you should definitely consider coming a day early and attending JUDCon. If you want to present at the event then submit those ideas and once voting begins make sure to vote for your session(s). And lastly, don't forget to register for the event!