Mark Little

The JBossAS team rock!

Posted by Mark Little Dec 16, 2010

Over the years we've put in a lot of time and effort to make JBossAS the best application server out there. With JBossAS 5 we refocussed around a new microcontainer architecture that gave us a lot more flexibility in terms of deployments and configuration. Building on AS 5, we saw performance improvements through AS 6 and now into AS 7. For those of us within JBoss and the active developer communities, this progression has been fairly low-key. However, now that we are through the first official community release of AS 7 and more people are starting to kick the tyres on it, the feedback we're getting is very positive and most folks seem quite pleasantly surprised!

 

Take the latest article for instance, which looks at startup times for various types of Java EE container. If you skip to the bit where the author comments specifically on JBossAS you'll see that between AS5 and AS7 we've seen orders of magnitude improvements in the start-up time. However, this is not due to the use of OSGi (which we do support), but to the work of Jason and the team on improvements to the microcontainer architecture and implementation. If you want more details then be sure to check out the Asylum Podcast that was recorded recently.

 

Of course start-up times are only part of the equation. You'll hear more of the benefits of the micro-services architecture on the podcast. But the various teams, such as HornetQ, JBossTS, EJ3, JCA and others, have all been looking at how to improve the run-time aspects of the container. We aren't quite ready yet to publish official figures, but I can tell you that by the time EAP 6 comes out, JBossAS 7 will rock! It will be the best platform on which to develop and deploy your enterprise applications, whether they run in the Cloud or run locally. So if you haven't taken a look at it yet, I recommend that you do so and provide us with your feedback. Or write articles extolling the virtues of the new performance improvements that you will find :-)

 

And I'll take this opportunity to congratulate Jason and his team, along with the other project leads and their teams, for putting in a great effort! We are really seeing the benefits and they'll keep coming over the next few months!

Mark Little

Nearly two years on ...

Posted by Mark Little Dec 12, 2010

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!!

Over the years both Red Hat and JBoss have a history of making good strategy acquisitions including, but not limited to, the Arjuna Transaction Service, Metamatrix and, of course, JBoss itself. Well I'm pleased to be able to announce that today we've done it again, this time in the Cloud space with the acquisition of Makara! Makara, if you don't already know, have been doing some great work with JBoss technology in the Cloud for a while now and has a great presence at JBossWorld and Summit earlier this year. To put what they do currently in a nutshell it's provisioning of JBossAS into public and private Clouds, with monitoring and management to enable auto-scaling.

 

Now obviously there's some overlap with projects we've been doing in JBoss and Red Hat, such as SteamCannon and CloudEngine, as well as obvious areas of synergy like DeltaCloud. Plus Makara's technology isn't open source. So that's why the engineering teams across the board have been talking about how best to drive the integration forward and ensure that the considerations of our communities are taken into account. Over the past 10 years I've been "acquired" many times as well as being involved in acquisitions. I've also helped open source a number of previously closed source technologies. To do this right will require time and doing is right is very important for us. So please don't expect to see code appearing immediately, but you will see the Makara team appearing in the forums, IRC and elsewhere to answer any questions that our JBoss.org developers and community may have.

 

So with that, I'll just say a big welcome to the Makara team! It's going to be a great adventure over the next weeks, months and years.

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.

Mark Little

JBossAS A Service

Posted by Mark Little Nov 1, 2010

I started writing this entry a few months back, but what with JavaOne, JUDCon, various customer engagements and a slight smattering of vacation, it's taken me longer than I expected. However, there has been one advantage to the delay: a lot of the reasons I mentioned previously that have taken me away from writing this piece have also helped to re-enforce the fact that we're on the right track.

 

So where to begin? Well I've written quite a few things over the past few months about Cloud and PaaS, whether that's about multi-tenancy, public/private Clouds, JeAS, PaaS, Platforms of Services, Cloud as the death of middleware (it's not!), or our own JBoss efforts in the Cloud. Underlying many of them (particularly those that talk about middleware) is the idea that the Platform for Cloud applications requires many (all?) of the capabilities that we use today in our non-Cloud deployments: just migrating into the Cloud doesn't mean your concerns about security or reliability that made you choose one solution over another for your data centre are invalid; if anything they become even more important! So whether you want to take existing applications into the Cloud (more likely) or develop new ones from scratch, you need the platform you code against and ultimately deploy into, to support those key features, such as security, transactions, messaging etc.

 

But of course Cloud means that you don't want to pay for these aspects, or the platform, and have it sitting around idle for 90% of the time. You only want to pay for it when you use it. This is the pay-as-you-use aspect we're always hearing about: it's a service (hence PaaS). And for those users who are interested in open source, standards based solutions, this is precisely where JBoss middleware comes into play. Today we have many customers who use our enterprise platforms successfully, including EAP, Portal and SOA-P. I wouldn't want to hazard a guess as to how many of them will want to move to the Cloud, but of those who do, and future Cloud-specific customers, they'll naturally expect a service-like arrangement for our platforms. This is precisely what we're doing with the Cloud Foundations effort that I mentioned a few months back.

 

In terms of PaaS, we're working on turning our existing platforms in an "as a service" offering. This includes tooling (e.g., JBDS) as well as monitoring/management aspects. So pretty soon you'll be able to develop your Seam-based application, or your EJB3 pet store, locally and then deploy them "out" to a Cloud running the right version of the JBoss platform you want, which will spin up your application when it's needed. So you'll only pay for what you need (e.g., EAP) when you need it. It'll be JBoss As A Service, or, because it's a cooler play on words, JBossAS A Service!

Mark Little

JavaOne 2010 ... not quite

Posted by Mark Little Sep 26, 2010

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!

I've mentioned before how much work we've been doing in JBoss around the Cloud, both from an implementation perspective in our projects as well as thinking about where we need to go. Well today Red Hat is making more announcements around Cloud. This is much more than just PaaS though: we're announcing a strategy and technologies around the entire Cloud stack, called Cloud Foundations. As with everything we do though, standards and openness are critical, so this isn't yet another vendor lock-in strategy; we're working with a range of other vendors in Apache through Deltacloud, the DMTF and OASIS with Cloud-Identity. And I think it's pretty cool to think that Dreamworks will be using these technologies in the future (and my 8 year old son does too!)

 

To paraphrase the Rolling Stones, if you're thinking about Cloud now or in the future then "On my cloud baby"!  And maybe Mick should be singing "Hey you, get on to my Cloud"

Mark Little

Testable Architectures

Posted by Mark Little Aug 19, 2010

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.

The  nominations for the eighth annual JCP Program Awards are now open!

 

http://wiki.jcp.org/boards/index.php?b=1103

 

http://wiki.jcp.org/boards/index.php?b=1103The awards will be presented at the JCP program annual awards during JavaOne.  There is an open board for nominations on jcp.org and community members may submit nominations online now.  If you would like, you can also submit nominations via email to pmo@jcp.org until 31 July. 

 

The EC will vote on the nominations in early August, and the results will be announced/presented during the conference in September. 

 

We are requesting nominations for the following categories (full descriptions of the categories are listed on the nomination page):

 

  • JCP member of the year
  • JCP participant of the year
  • Outstanding Java SE/EE Spec Lead
  • Outstanding Java ME Spec Lead
  • Most Innovative Java SE/EE JSR
  • Most Innovative Java ME JSR
Mark Little

Andiamo

Posted by Mark Little Jul 2, 2010

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!

Mark Little

JBossWorld 2010 (recap)

Posted by Mark Little Jul 1, 2010

Last week's JBossWorld was only the second one to be held coincident with Red Hat Summit. It was also the first time we ran JUDCon and the outcome of that was very good. But back to JBossWorld: the attendance was way up on last year and the feeling around the place was definitely electric. All of the sessions I attended were packed, with some of them standing room only. And it was also great to see a mix of Red Hat Summit and JBossWorld attendees in the same sessions, breaking down those artificial barriers.

 

I gave my usual State of the Union talk at the start (though messed it up a bit by forgetting what time I started and thinking I was about to overrun I rushed a few slides!) As someone pointed out later, there really is way too much to cover in one hour as well. Then the technical sessions kicked off, covering all of our platforms and showing how much innovation we're doing to keep JBoss at the forefront of middleware and open source leaders. Anyone at the conference couldn't fail to notice the impact of Cloud and several of the JBoss sessions picked on this topic in some detail, giving an outline of where we are heading.

 

Of course it wouldn't be a JBossWorld without a party and a pub crawl. This time there were several of the former, but only one pub crawl. It as interesting to be on stage at 8:30am the following morning and notice that there were a lot of people either not there in the audience or wishing they weren't there! But hey, that's one of the reasons people enjoy these events and keep coming back!

 

Overall I think this was probably the best JBossWorld since 2006 and Vegas. We seemed to have the right mix of technical and business tracks, as well as ample opportunity for people to mix and debate the presentations. I also think that JUDCon helped too by giving people who wouldn't necessarily think of attending JBossWorld the opportunity to do so. Hopefully we'll see more of them back next year too!

Mark Little

JBoss and the Cloud

Posted by Mark Little Jun 17, 2010

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!

Whether you call it workflow, task flow, process flow, process management, BPM, or something else entirely, workflow systems have been extremely important to enterprise systems over the past decade or so. With the advent of SOA and larger scale deployments, the combination of SOA and workflow (typically BPM, given the business drivers behind SOA) became inevitable and sensible. These days it doesn't matter where you look: if there's a SOA platform around then there'll be some way of orchestrating the services involved and the way in which they are invoked.

 

Looking at this from a very JBoss specific perspective, we decided at the outset of the JBossESB project that some form of process flow technology was critical to the adoption of SOA, and the obvious candidate for us was jBPM. The maturity of the project, the enthusiasm of the community and the engineers, in particular Tom Baeyens, the project lead. From there jBPM 3 made its way into our SOA Platform and the rest, as they say, is history. Over the past couple of years we've revised the SOA Platform a few times, with the latest 5.0 release only a month or so ago, building on the integration with our various projects including jBPM, JBossESB and Drools.

 

Over that time the feedback, both from customers and community users, has been overwhelmingly positive. The integration of SOA with BPM was pretty much spot on, giving those users who didn't want to worry about Web Services or BPEL an alternative. Plus over that time the Drools team have been pushing the boundaries between traditional rules engines and process flow in their community, with equally positive results. With the work we started elsewhere around Process Governance and another foray into the WS-BPEL space with Riftsaw, the impact of workflow-based technologies on everything we were doing within JBoss was reaching a critical mass and a more global, less project specific rethink, was in order.

 

Probably one of the first public announcements to emerge from our rethink was the initial release of jBPM 4. The jBPM team had taken on board much of the feedback they'd obtained from the jBPM community as well as the JBossESB and SOA-P communities. Tom's vision of the PVM had been building for several years (before integration of jBPM 3 with JBossESB) and finally saw daylight with jBPM 4. Many of the improvements we see in jBPM 4 versus jBPM 3 are a direct result of the feedback I mentioned and baking them in the community is critical to ensure that the team have them right. After all, that is the open source way. Whether or not a version of jBPM 4 was ever officially supported in a product by Red Hat is immaterial to that aspect: we need to ensure that something as radically different in architecture and implementation from the previous major revision is right for the community and our platforms, and the best way of doing that is putting code out there for people to use and on which to give feedback. And that feedback has been great. Thank you to all who have contributed and continue to do so.

 

But of course things don't always run according to plan and 6 years after joining, Tom decided to leave for pastures new. That left us with a new jBPM lead, Alejandro, who has been a skilled engineer working on the project for many years. It also coincided with the release of SOA-P 5.0 and a need to continue the workflow rethink that had been going on for quite a while. Naturally the departure of any project lead may cause worries in the community and with customers, but where jBPM is concerned they are unfounded: jBPM has been core to all of our BPM and SOA efforts for years and that will remain the case, whoever is the project lead.

 

Now of course the issue of technical direction comes up whenever any significant engineering talent moves away from a company. However, we continue to have workflow-related rockstars in our engineering teams and communities, and as an open source company we never close our doors to anyone who leaves if they want to continue to contribute to any of our projects. In the meantime, work on unifying the core workflow capabilities we have around jBPM goes on and I have the utmost confidence that our customers and communities will benefit from this effort. As always, we're soliciting feedback from anyone on what they want to see, what they don't want to see, where things can be improved etc. There's a great deal of work in jBPM 4 and DroolsFlow that will feed into this story and what comes out from the project and into the community over the next few months will be iterated over many times as we move from alpha releases through to the final community version.

 

However, it seems that there remain concerns around jBPM 4. Will it be productized? Will it be supported (really the same as the first question)? Will we put any engineering effort into it? It is fair to say that there was expectation that jBPM 4 would appear in a version of the SOA Platform as a replacement for jBPM 3. With the changes to the jBPM project team and the next steps in unifying our efforts in this area across projects, it is not going to happen. But that does not mean we are dropping engineering effort around jBPM 4: far from it! While we work on plans for jBPM 5 we need to continue to work on community features in jBPM 4 that will eventually make their way into jBPM 5, so you will see more jBPM 4 releases! Once again, this is one of the key benefits for choosing open source, where we (JBoss and community) get immediate access to feedback, both positive and negative. We're working together on this and that means the technical direction can be influenced by community, even if some in the community cannot contribute code directly. Send your feedback in and continue to download releases of jBPM 4 as they will be the testbed for many of the features that will be in jBPM 5.

 

But what if you've been relying on jBPM 4 becoming productized? Unfortunately plans change and whilst jBPM 4 may not see productization under that name, a lot of it will under the banner of jBPM 5. Fortunately a smoother transition between previous versions of jBPM and jBPM 5 will be a key consideration for the next supported release. We think we know what is needed in that regard, but once again it's important that we hear from the community. What do you want to see to help migrate yourself from jBPM 3, say, to jBPM 5?

 

In summary, jBPM is alive and kicking, as well as going from strength to strength. Some of the people involved in the effort may have changed, but the criticality of it to JBoss remains the same. We will continue to invest in this area and although the next supported release may have a slightly different version number to what was expected originally, the end goal remains the same: the best open source embedded Java workflow/BPM solution in the industry. If you're in the jBPM community or considering joining then now is the right time to get involved (again). Give the team your feedback and support, so that they can deliver on what we all want and need! And as a friend of mine would say if he were still in my position: Onward!

Mark Little

JUDCon Boston is now Live!

Posted by Mark Little Mar 15, 2010

 

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!

 

We've been doing a lot around Cloud lately, both as a middleware team and throughout the company. I believe that we have the best teams and software to deliver on the vision of Cloud (as well as actually defining that vision, which is still very much in a state of flux). However, the definition of Cloud today is likely to look very different to the definition of Cloud in a few years time, so we need to continually be looking ahead and researching those new frontiers. So it's with a lot of pleasure that I can announce we've teamed up with the University of Newcastle upon Tyne, a centre of Cloud excellence as well as fault tolerant distributed computing. Over the years I've worked at the University as well as with them through a number of companies, including Bluestone and Hewlett Packard. They are second to none in their fields of expertise and I'm certain that the combination of Red Hat/JBoss with Newcastle University will yield fantastic results!

 

Footnote: I'd like to thank everyone involved in making this happen, too many to mention them all but including Brian Stevens, Carl Trieloff, Professor Paul Watson, Professor Santosh Shrivastava and Barry Hodgson.

Filter Blog

By date:
By tag: