Adobe and JBoss people have been collaborating on a range of things for years. One of my best friends at Adobe, Duane Nickull, is an evangelist, musician and ardent JBoss fan, always sending me the latest bit of information, blog post or question around what they're doing over there using our stuff. It's got the point that I may create a specific Adobe page on our wiki so we can keep track of them all. Anyway, Duane's latest and greatest is an episode of his TV show, Duane's World, where he talks about Adobe Livecycle and some JBoss tutorials. Definitely worth checking out and adding to your feeds for future episodes! Thanks Duane!
When JBoss World started back in mid-2000's it was definitely a conference by developers and for developers. My first ever exposure to JBW was in Barcelona and it was definitely a unique event back then. I'd been used to academic conferences/workshops or those that were heavily marketing driven, so JBW was a breath of fresh air. The next few JBoss Worlds were similarly heavily developer driven and I know the core developers really appreciated the opportunity to get to meet their community of contributors and users. However, as we have grown, and with the Red Hat acquisition back in 2006, the emphasis around JBW has shifted to embrace a wider audience, including users, partners and those people who may be dipping their toes into the open source waters. That progression is a fairly natural thing: JBoss reached critical mass adoption towards the end of the first decade of the 21st Century and our user base grew immeasurably.
However, as JBoss World changed we didn't want to lose touch with our developer-centric roots. For open source that aspect is critically important. So we've been thinking about what to do in order to allow us to continue with the new focus around JBoss World and yet try to get back to the old focus of the original JBoss World. For the answer we looked at what our colleagues in the RHEL/Fedora world have done and FUDCon came to mind. If you've ever been to FUDCon you'll know that it really is completely different to Red Hat Summit: it's by developers and for developers, which is precisely what we wanted to do. So was born JUDCon: the JBoss User and Developer Conference, which is what I'm announcing officially today.
JUDCon will be held twice a year initially, once in the US and once in Europe. If it's a success we'll look to expand the number of the events as well as their physical range. But for now 2 a year should be sufficient while we find our feet. For the very first JUDCon we'll be positioning it just before JBoss World, but that's just a happy coincidence. We'll be posting more on the agenda for JUDCon soon, but the format will be familiar (though not the same) as FUDCon. So if you've got presentations that you'd like to give in front of a large community of your JBoss peers, get ready to submit them. Or if you just want to come and hear about the latest and greatest projects we've got going (and very much in depth presentations at that), start looking to book your travel.
There'll be an official JUDCon page on JBoss.org soon where you'll be able to see the agenda, sign up to give sessions, sign up for sessions etc., so keep watching that site. As with FUDCon, attendance at JUDCon will be free, but guaranteed places will be on a first come first served basis. Plus this is our very first JUDCon so we'll be asking for feedback from attendees so that we can improve future events. So if you're looking for very technical sessions on JBoss projects, this is definitely the event to target. Of course with JBoss World being held straight after you can always go to both and get the complete product/project picture!
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!
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.
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!
You've probably all seen or heard of Transformers ("Transformers ... robots in disguise.") The gist is that these robot are flexible enough to be reconfigured into a variety of different forms depending upon the need at hand. Pretty important if you need to battle enemies from the stars and then make your way silently through the streets disguised as a Bugatti Veyron. But what, you ask, has this to do with JBoss? Well we've been working on our own adaptable infrastructure for a few years; not so we can fight Decepticons, but so that we can offer a way for the same software components to be used in a variety of different environments without requiring major rewrites, different implementations, recompilations or several months of on-site consultants. We also want to support a range of different frameworks or component models, such as SCA, Ruby and OSGi.
So how have we been able to accomplish this? With the JBoss Microcontainer. It's been in development for several years as well as being an evolution from the original JMX Micro-kernel. The basic concept is pretty simple: you can define your core services/components and their interdependencies no matter what their flavour (e.g., POJOs, MBeans) dynamically and potentially on-the-fly. What was a full-featured JEE Application Server one minute could be a scaled down embedded ESB the next. What was a basic Web server yesterday could seamlessly acquire transactions and security tomorrow.
The aim here is clear though: to allow existing investments in components that have proven their maturity over the years to be used in both lightweight and heavyweight environments. Other approaches to solving this problem typically revolve around completely different technology stacks, requiring different expertise, learning curves, support contracts etc. And that kind of solution does not evolve with your changing requirements (at least not without going back to the vendor to arrange delivery of the new product, learning it, training etc.)
But what about other deployment models, such as OSGi and Spring? Although JBoss is popular there are people who need to use these alternative frameworks/component models. In the past they meant embracing that entire framework for everything in the assumption that the choice you make today is the right choice for tomorrow. Unfortunately frameworks come and go, as well as requirements changing. So an investment in something today is not necessarily the right approach for the future. But in that case what do you do when you're left with an OSGi bundle and you don't want to stay with OSGi, for example? Well fortunately the JBoss Microcontainer offers a possible solution there too. supporting a flexible state machine model of components we can support native component model deployments as well as foreign component models on the same codebase and track dependencies across those component models.
The architecture of the Microcontainer has evolved over the past few years, so even if you looked at it a while ago it's worth looking again. For example, we've added increased flexibility to the deployment model such that we now support an AOP-like manipulation of a metadata pipeline down to the final component deployer. There's also a Virtual File System for deployments, which is a major improvement over the past. Finally it's now possible to declare that any implementors of an interface should be "injected/un-injected" via specified methods, which allows for containers to specify plugin interfaces and easily have plugin implementors associated with the container as the plugins are instantiated. These examples and others just go to prove how much thought and effort has gone into this new architecture in order for us to be able to deliver on the promise of flexibility and adaptability for user requirements now and in the future. We spent a lot of time doing this so that we could do it right once and for all time: the future is bright for JBoss and its users, because we know now that we don't have to worry about re-architecting again in a years time when another deployment environment comes along, or some subtle differences in needs force a rethink of "fat" versus "thin" deployments or "rich" versus "poor". You can safely deploy to the new Microcontainer in the knowledge that it's future-proofing you.
As an industry one thing that we often fail to remember is that standards come and go, but core requirements remain. If you look at the evolution of distributed systems over the past 4 decades, for example, you'll see the transition through DCE, CORBA, JEE, Web Services etc. These all define their own component model(s), APIs, development methodologies etc. Yet at the heart of them all critical services such as transactions, messaging, security etc. remain the same. The only thing that changes is the way in which they are wrapped into the infrastructure. Well that's something we've tried to embrace with the new Microcontainer: leveraging our tried and tested components and providing a way to use them in environments/standards past, present and future.