1 4 5 6 7 8 Previous Next

Mark Little's Blog

157 posts

Unless you're still recovering from Christmas, you can't fail to have noticed that we're doing quite a bit of work with languages other than Java. Those include Ruby, via TorqueBox, Clojure with Immutant, C/C++ in Blacktie, Scala in Infinispan, Ceylon and my own person favourite Erlang (ok, that's still more a pet project for me than anything else). But does this mean that we're turning our backs on Java? No, of course it doesn't! If anything it shows our continued commitment to Java and the JVM because all of these approaches to polyglot leverage our Java projects and platforms. I've said on a number of occasions that the future of middleware isn't to reinvent core services and capabilities (check out my Future of Middleware presentation, for instance). There's also a lot more that we have done so far and will be doing in the future that should show we're as committed to Java today as we've ever been:



The links are to some things I've said over the past 12 months, but the entire JBoss team has been saying and presenting on similar topics. So I'll leave it as an exercise to the reader to find those references.


In conclusion, for all those people who believe that we're ignoring Java, I have to say that nothing could be further from our minds.

Mark Little

Middleware 2011 and FOME

Posted by Mark Little Dec 14, 2011

I'm just back from the Future of Middleware (FOME) workshop at Middleware 2011, where I was presenting a paper I co-authored on "Another Look at the Middleware for Dependable Distributed Computing". As you can probably guess from the agenda, it was a very wide ranging workshop covering pretty much all aspects of middleware that you could imagine, from enterprise through to sensor networks. Overall I thought it was great to see so many challenges still remaining in the middleware area and also that there was a lot of commonality in the way the authors, both academic and industrial, were proposing solutions: it's a good time to be in middleware research and development.


Screen shot 2011-12-14 at 21.16.28.png


So it wasn't uncommon to hear terms like "the internet of things", "ubiquitous computing" and "dynamically reconfigurable middleware". As with many of these events, it wasn't just the presentations that were interesting or worth the trip, it was also meeting the attendees and sharing experiences and thoughts. There was a good mixture of academic and industrial attendees and it was good to catch up with a few friends/colleagues that I haven't seen for a while, such as Rachid Guerraoui and Steve Vinoski (OK, I saw Steve a few weeks back at QCon San Fancisco!)


Unfortunately due to the time of year and the amount of work that we've got going on throughout the company I wasn't able to spend as much time at the conference as I'd have liked. So I didn't see the wider conference, only the FOME workshop. Plus, I didn't get a chance to see Lisbon, which is a great city that I've visited many times over the past couple of decades. The people are great, vibrant and friendly. And usually the weather is pretty good, though this time it rained, despite what the marketing image might suggest


Screen shot 2011-12-14 at 21.17.51.png

All of the papers are (or will be) available for free for a very limited time from Springer, so thanks to them for doing this. I encourage you all to go and download them because there's some really good material in there. The various presentations will be available eventually too, but I'm not sure where they will be placed (probably the FOME web pages.) Until they're available, I'll leave you with a couple of the slides from my presentation to whet your appetite!


Screen shot 2011-12-14 at 21.22.24.pngScreen shot 2011-12-14 at 21.22.36.png

I'm a big softy at heart: whenever I see baby photos, or videos of them laughing I go all warm and fuzzy Seeing something come to life is wonderful. So you can guess how I felt when all of the work we'd been putting in to things behind the scenes finally flourished and Apache DeltaSpike was born! This is an important announcement for a number of reasons: first, it's multi-community based, with collaboration with many other CDI projects in the open source space (there are a couple of notable absentees, but hopefully they'll come along later); second, counting the time when we first thought about doing something around CDI in a vendor-neutral environment, it's been over a year in the planning. This is only the first step though, and we'll be announcing other related activities and thoughts around DeltaSpike, Seam etc. in the coming weeks and months. And we'll be asking for the community to help guide where we go with CDI at least, so if you're at all interested now is the time to put those thinking caps on.


As I said, this has been a collaborative effort both inside and outside of JBoss. My thanks go out to everyone who has helped to get us here and to all those people who will surely make this a success. Not only is this a good step for Seam and CDI, but hopefully it illustrates how EE6 can be a much more open effort if there's a willingness to engage in constructive dialog. So from my team and in no specific order, I want to end by thanking Pete Muir, Shane Byzak, Lincoln Baxter, Jason Porter, Dan Allen and many others. My apologies in advance if I missed your name out! And thanks to Jim Jaglieski who helped shepherd things.

It's official now: Ceylon is close to it's first beta and the team have launched the site at Devoxx. Of course we heard about Ceylon earlier this year but the curtain really came up last week. For a project that really only took off just after I took over from Sacha, Gavin and the team have done a great job. And in great JBoss tradition, I'm not just talking about the specification or implementation, but also about the thriving community that's built up in only a few short months! It's is yet another project that I wish I had more time to commit to it, so have only been able to help on the specification intermittently and only then much earlier this year, but as they say, every little helps (no pun intended!)


I'm really excited by Ceylon and what it might mean for other things we're doing in Cloud and JBossEverywhere. So expect to hear more about this effort in the coming months, because just like Java, it's going to continue to evolve. And can we please stop these "my language is better than your language" arguments? There's room in this evolving polyglot world for a few more, even if just to allow people to stretch their mental legs and see what works and what doesn't. Everyone is entitled to their opinions and reasoned arguments are always allowed; but flamewars, especially if they're subjectively based, don't help anyone.



Mark Little

QCon San Francisco

Posted by Mark Little Nov 20, 2011

Just back from QCon where I was speaking about JBossEverywhere again and with help from Kevin, also trying to reproduce the original demo. Unfortunately due to issues with the new plug computers and network limitations in the room, we weren't able to show things happening live. Fortunately I brought along the video of the JBoss World demo and showed that. The feedback we received from the audience indicated that this was something that caught their imagination yet again, as well as showing us as a centre of innovation. All good stuff and it made my fourth trip to the States in as many weeks well worthwhile.

Mark Little

Cloud for developers

Posted by Mark Little Nov 16, 2011

So you've decided to develop for the cloud and your next decision is the language. Well I've already mentioned why Java is probably the best choice for you, especially if you want reliability, security and other enterprise capabilities. But as developers we all know that whilst these things are important, it's how you pull them together into an application that makes an incredible difference. It doesn't matter if you've got the best framework around if it takes a rocket scientist to be able to understand it or develop anything with it. This is where tooling comes in. And once again Java helps you here, because over the past decade no single language has seen the kind of explosion in developer-oriented tooling. Now I use the word "tooling" to cover a wide range of things. Whether it's IDEs such as Eclipse or IntelliJ, utilities to facilitate building your code e.g., ant, maven or Ivy, automatic code coverage tools like EMMA, or testing tools like junit or the DTF, you'll find them and much more in the Java ecosystem. You can say what you like about the language and it's future, but anything that eventually comes to replace it either has to leverage these things too or replace them, which is going to be quite a Herculean task.


Anyway, back to the cloud. These tools grew up because there was a need for them and naturally developing in the cloud doesn't necessarily remove that need. Yes we hear a lot about how cloud can simplify the life of a developer, but if you are a Java developer and it doesn't integrate with your favourite tools then your life is probably not simplified at all! We announced OpenShift back in May and then integration with AS7 several months ago. But despite the fact that at that time we did a lot of ancillary work around this to make it really simple to develop your applications, and we've done further work adding things like Arquillian, there were some important pieces missing. For a start it was originally very command-line driven, which is fine if like me you grew up using Unix and still use emacs, but is perhaps a slight burden for others.


So in the interim along with making a series of other improvements to the OpenShift runtime, the team have been working to simplify the life of a developer. The ultimate aim is to blur and then remove the distinction between cloud and non-cloud development, or at least as much as makes sense because at times you really do need to understand the differences. And when I say "the team" it's important to realise that once again, as with the AS7 effort, this has been work conducted by people across several distinct teams, including the OpenShift developers and JBoss engineers. I don't want to spoil the surprise too much because if you come to the webinar you will learn so much more from the engineers who have been involved with this effort, but what we are announcing in a few days time is a complete develop-to-test-to-deploy (d2t2d?) approach, including one of the most popular testing implementations and IDEs. And it's also worth noting that despite the fact I've concentrated on Java in this posting, you'll see that it actually goes well beyond a single language!


In conclusion, you'll find that not only was OpenShift the first Enterprise PaaS with EE6 support, simplifying development for the cloud and helping to shape where others had to follow, but now we are continuing that effort. And the emphasis is on "continuing": there is much much more to come from the teams in the coming months. I wish I could hint at some of them, but that wouldn't be fair to tease you or our competition So all I will say is watch this space and if there are things you'd like us to concentrate on then let us know through the usual avenues! Oh and enjoy the webinar!


Update: ok, so I wrote this entry on a flight and it took me a little longer to publish than I expected. In the meantime we announced some of this, so the surprise is already out there You should still come to the webinar though! Tries these links out in the meanwhile:


Jenkins + OpenShift How-To Blog:



Jenkins + OpenShift How-To Video:



JBoss Tools + OpenShift How-To Blog:



JBoss Tools + OpenShift How-To Video:


I'm just back from HPTS 2011, where I was chairing the session on Consistency Revisited and going to present on data inside and outside the enterprise in a large scale environment. I've been to this workshop many times in the past and it's always a great event to attend, not just if you're in the transactions space. Over the years it's had a great track record of predicting what's coming up across the industry, whether it's SSDs, Java transactions(!), or eventually consistent data stores. The papers/presentations will soon be on the website (as soon as I receive them from the attendees), but here are a few pictures to give you a sense of the event.


Here we have James Hamilton (ex Microsoft, ex DB2 guru) talking about the costs of developing and managing a data centre on the scale of Amazon. As someone else pointed out, it can't be many computing workshops/conferences that you attend and learn about electrical noise attenuation or transformers.


In the next picture you can see everyone listening to Charles Lamb (ex Sleepycat) talking about Oracle's entry into the NoSQL space. There's a lot of overlap with what we're doing around Infinispan, so it was good to listen to some of the technical details.


It's worth pointing out that the event is always held at Asilomar conference grounds, which has remained largely unchanged for decades. For many years there was no wifi and only dial-up modem, which helped you to remain focussed on the presentations. Then about 6 years ago wifi was introduced, but only in the main reception hall. This meant many of us would be there at about 5am in the morning catching up on email before heading to the workshops. However, this year they introduced wifi to the rooms which on the one hand is good but on the other is bad as it reduces the need to mingle.



On the Monday evening there's a tradition of having a 2 hour or so series of poster sessions, where those who present have 10 minutes to cover their favourite topic. Most of the time these go well, but as the evening progresses and the more contentious talks come on, it's not uncommon for the audience to get more and more "troublesome" But always in the best possible way! Here we see Pat Helland (ex Microsoft, ex Amazon) presenting on why we shouldn't believe a word he says on transactions! It's a long story, but Pat has swung from being a pro-ACID/2PC guru, away from it and not back. His talks are always entertaining and this one was no exception.


On the Tuesday evening there was a panel session on Scale Up vs Scale Out. There was only one slide for the entire 2 hours, but the time flew. The panelists covered the range of topics that this subject often raises.


Asilomar is a great venue for a great workshop (probably the best workshop I've ever been to). It's always good to go to the workshop and the weather is usually pretty good too. So until I get the presentations uploaded, I'll leave you with one last image of the event.


Mark Little

JavaOne 2011

Posted by Mark Little Oct 12, 2011

We're back from JavaOne and it was great! I could use various other superlatives to describe the event from a JBoss perspective but sometimes a picture really does paint at least a thousand words! First let's take a look at some shots of our booth in the pavilion.



It was packed almost continually and particularly when we were giving the booth presentations, such as this one from Manik Surtani on Infinispan!



A couple of our projects were also Dukes Choice Award winners! In these pictures you can just make out Andrew Rubinger, Aslak Knutsen and Dan Allen receiving the awards for Arquillian and Netty. Congratulations to the teams and their communities!





I won't include any of the photos I took of various JBoss people out and about or partying, since I don't want them reciprocating Of course the major sad news during the event was the death of Steve Jobs. Not only was there a moment's silence at the JavaOne party where Sting dedicated Fields of Gold, but the keynote on the next day also held a moment's silence.



We had a lot of talks at JavaOne and AS7 was the subject of many of them. It was really great to see the amount of interest from the attendees on what the team have been doing for the past 2 years. Here's a representative shot of Andrew's session afterwards, where it seemed like the entire audience came up to ask more questions!



Unfortunately I don't have any pictures of my "guest slot" at the keynote on Tuesday, but it and our sessions should be available online soon. And watch out for other posts from the rest of the team on their JavaOne experiences!

Mark Little

Java EE as a PaaS

Posted by Mark Little Sep 29, 2011

Sometimes if you don't have anything useful/constructive to say it's better to say nothing. Case in point: I came across this posting today. It's the usual kind of statements from the vendors who don't really have an enterprise solution to offer their users so they try to deflect the argument to something else. In this case it's the typical "lightweight = agile" statement, carefully ignoring the realities that sometimes "lightweight = adhoc = maintenance nightmare = more expensive to maintain = not suffient for enterprise deployments". Look, I could rant about this until the proverbial cows come home but I've said so much about this before and at some point I need to stop banging my head against a brick wall! So rather than repeat, I'll just point at some relevant postings:



So take a look at these. I've tried to be very objective in many of them, because I really do believe that there's far too much smoke-and-mirrors and outright deception being pushed by some vendors.

Many years ago before JBoss and Sun became BFFs, we ran a mini JBossWorld-like event at the same time and at roughly the same location as JavaOne. This went on for a couple of years and saw some pretty impressive audiences for that period in JBoss history. Well since then we've obviously gone on to bigger and better things, what with JBossWorld, JUDCon and other events. Of course one of those "other events" is JavaOne, where we've been present every year since about 2004/2005. Well this year is no different in that we're attending (we'll have our booth there as usual, with many of us giving talks throughout the days), but it is different in that we are there in strength! Take a look because we're giving at least 20 sessions at JavaOne this year. If this keeps up, maybe they should rename it as JBossOne!


If you're going to be at JavaOne then call by the booth and let us know what you think of our projects and products. If you can, why not go to some of our sessions too as it's a great opportunity to hear about things we've been working on as well as are working on currently?


Update: there may be a few surprise appearances by JBoss people at JavaOne that aren't publicised just yet

I've discussed several times in the past why you need something like a Java EE application server, such as AS7, as the basis for your PaaS. Emphasis on "something like", because if you've got a CORBA implementation or an old DCE deployment lying around, those will do too at a pinch, though I have to say that AS7 is a better option. But precisely why is this the case?


Let's look at the fundamental core capabilities that I keep mentioning, because they will drive home the reasons:


  • transactions; unless you're working with only one datasource then at some point you'll need transactions. These have the nice property of guaranteeing isolation and failure atomicity for work conducted within their scope. Using them with multiple databases and messaging services, for instance, will ensure that your updates occur and the message is delivered or nothing happen, even in the presence of machine crashes or concurrent users. And these days, in a  multi-core world with increasing parallelism, transactions in the form of Software Transactional Memory, are becoming a first class programming construct. As an industry, transaction systems such as JBossTS (aka Arjuna Transaction Service), CICS or Tuxedo, have been around for decades and quietly running the backbones of mission critical environments.
  • replication; now although transactions are great for guaranteeing consistency and correctness in the presence of failures, they can't provide forward progress - a machine crash will be tolerated by a transaction, but if the transaction is retried and the crash remains or happens again, then the application will not move on. If you replicate the machine or just some of the services on it, using an appropriate replica consistency protocol, then you can tolerate a finite number of failures. The types of failures to can tolerate can range from timing, through value and to Byzantine. As with transactions, replication protocols have been employed in standards based and bespoke distributed systems for many years, including air traffic control, finance and healthcare. JGroups is one of the foremost group communications frameworks and can be used as the basis of various replication protocols.
  • security; making sure that your competitors can't read or write your data is pretty important, especially when it's in a shared environment. Making sure your users don't see data they're not entitled to is also a necessity. So security and authentication go hand in hand. In fact security is often one of the first things that any enterprise platform will incorporate, because otherwise it really doesn't matter if you can tolerate machine crashes if that just gives others longer to hack in to your data and processes! The industry has worked on many protocols, such as XACML, TLS and Bell-LaPadula, so there are solid foundations with existing platforms.
  • messaging; it goes without saying that in a distributed system you need some way for participants to communicate. That could be through approaches like RPC or asynchronous message passing. And you might also want to incorporate other techniques like retained results and timeout/retries to make your life easier in the world of lost responses and out of order delivery. Fortunately because distributed systems live or die on their messaging implementations (reliability, performance, ability to cope with large payloads etc.) it's an area where maturity is a necessity. It doesn't matter if you were using CORBA or one of the bespoke distributed systems that predated even DCE, these things typically worked well. In Java EE, which builds on these, JMS is the standard and really good implementations such as our HornetQ project, exist and are well integrated into the platform.
  • persistence; applications that don't need state are of very limited use! Whether your state is bank account details or the latest sky map details, it's got to be stored somewhere. In the past, relational databases (RDBMS) such as MySQL or Oracle, have been the data repository of choice, although other obvious candidates cam be used, such as the file system and replicated in-memory storage (after all, durability is probabilistic no matter what implementation medium you choose). These days we're seeing more discussions around what are being termed NoSQL (used to mean No SQL, but now tends to stand for Not Only SQL as people recognise it's not an either or problem). Whereas RDBMS are good generalist solutions, there are problem areas where they are suboptimal, e.g., where the number of participants is large or they are physically remote. In these situations, theories such as CAP come in to play and you have to make tradeoffs. There really is no such thing as a free beer! But NoSQL is still a relatively early field and not every use case needs to move away from RDBMS, or can tolerate the data inconsistencies that often occur in NoSQL, particularly when you realise that some implementations don't support transactions. (Hey, eventual consistency could very well be immediately too late for your application!) The work that the Infinispan and Hibernate teams are doing in this space is very important and well worth a look.
  • standards; hopefully this one is fairly obvious? Vendor lock-in really doesn't help anyone except the vendor. Short term advantages, especially in the area of cost, can easily come back and bite you in the derrière! And where PaaS is concerned let's not forget that being able to move out of the cloud is just as important as moving in to it!


EE6 is a good standard that brings these and more together into a well defined stack. And AS7 is the best implementation of that standard that puts to death the old myths and FUD that Java EE is bloated and unusable. I could write a multi-page technical paper about all of the above and maybe I will. However, until then I believe I've outlined the reasons why I think that existing enterprise middleware stacks like AS7 (and specifically AS7!) are a very appropriate platform on which to build PaaS and AS7+OpenShift is a great way to put your toe into the water as well as jump in completely. And this is (and will be) irrespective of the application development language.

You can't fail to have noticed that we released the world's first enterprise Java PaaS recently, when we put AS7 into OpenShift. Of course we certainly weren't the first to support Java and now we've just seen another entrant come into that space. However, it's good to see that we are still alone in offering a meaningful Java PaaS!


Let's look at what I mean by this. For a start I have a big problem with some of the statements made in association with the newest Java PaaS, which are no better than FUD, and you should know that I hate FUD. Apparently J2EE derailed Java (huh?!) Apparently there's an impedance mismatch with the way developers approach applications in the Java world (referencing a really old Sun document from 10 years ago as if it's an industry wide approach is really scraping the bottom of the barrel.) Is that desperation I smell? Then there's pointing to a recent analyst blog that is hardly objective in itself; this really doesn't help make the case either. I've already pulled that report apart, so I won't repeat that again except to point out that it is hardly a convincing result to use a single non-peer reviewed article to attempt to back up your statements, whilst conveniently ignoring the copious amount of data to the contrary. To paraphrase Shakespeare, "They doth protest too much, methinks." Here's a tip: if you're going to criticise then do so on the basis of facts not suppositions or downright myths! What was that I said earlier about FUD?


Furthermore, this recent announcement is a great example of how not to build an enterprise PaaS. It's interesting to see that the example used in the announcement is HelloWorld. Somebody more cynical than I might think that it says something about the complexity and enterprise nature of the applications they can support being deployed! Now of course you can argue that you can pull together more feature rich stacks and frameworks on such thin PaaS implementations. Yes, rolling your own stack is a much better use of a developers time compared to getting one out of the box!


I find it worrying for developers on any PaaS like this (and this one is not alone!) because if they need transactions, durability, high performance messaging, security, service clustering etc. then they're either missing entirely or may be provided in some limited form by the underlying platform. Now I have no problem with a platform providing these capabilities, but let's stop trying to suggest that an application server is not a platform! It is! In fact most application servers have been robust, fault tolerant and secure platforms for many years. And in this world, maturity counts, especially when you throw your data at them.


It is nice to see that our ideas of JBossEverywhere (JBoss as a common runtime fabric/infrastructure, no matter what the language) have caught on elsewhere too. Providing a common runtime across languages makes perfect sense. But if you're going to do that then surely it's better to start from the perspective of a strong enterprise platform as your foundation?! As I keep saying, cloud makes enterprise capabilities more of a necessity not less! There's a reason that middleware today looks a lot like it did 40 years ago, at least in terms of core services such as transactions, security, replication etc. And its not because the industry is lazy or users of it don't know what they need!  Unless you're really only interested in writing HelloWorld for the rest of time, you're going to need one or more of these capabilities pretty soon! And you really don't want to have to worry about how they are deployed and configured, let alone whether the implementations work together correctly!


So in conclusion I can understand why, if you don't have the necessary components to provide the rich PaaS infrastructure that people need you'd try and downplay them. We've seen that for many years with competitors railing against JBoss. But it doesn't really hide the fact that where this recent announcement is concerned The Emperor Has No Clothes!

Mark Little

Red Hat Research Day

Posted by Mark Little Aug 16, 2011

We had our second Red Hat/Newcastle University research day yesterday. It was a good gathering of various people from the distributed systems research team at the University, as well as various people from JBoss, such as myself, Manki Surtani, Gary Brown and Jonathan Halliday. We had talks covering a wide range of topics, including:


  • Jonathan on NoSQL, our plans and the current landscape;
  • Gary on testable architectures and the Savara project, which seems to have relevance with some of the work going on within the University on electronic contracts;
  • Manik on Infinispan and issues with large scale caching, which generated some interesting discussions in the room around scalability, performance and reliability.


All of these presentations were great, as usual, and lay the groundwork for interesting research collaborations in the future. It was also good to hear presentations from our University colleagues on aspects such as federated clouds and security (I was fascinated to learn about Bell-LaPadula multi-level security which seems like a good fit for cloud) as well as scalability with uncertainty (trade-offs between gossip protocols and other approaches to consensus). It also turns out that they're using a number of our JBoss projects within their work already, such as JBossAS and Drools.


It was a full day of presentations (7 in total) and much discussion. A good meeting of academic and industrial minds, where both sides learned from each other. I'm really looking forward to the collaborations that will result from this meeting and to planning the next meeting. I think next time we should schedule a couple of days though!

We've been talking about cloud for a while, whether that's IaaS or PaaS. In terms of JBoss and the cloud then there's been a lot of activity for almost 18 months, covering both short term needs and long term vision. We coined the term Enterprise PaaS to distinguish between what we believe is really important and required from a cloud middleware offering and that which is offered by others. I'm not going to reiterate all of that, or how it relates to the bigger JBossEverywhere picture, but today marks a significant milestone in our roadmap towards the vision.


We released OpenShift at JBossWorld and Summit. At the time we explained the differences between the flavours, like Express and Flex. And back then we supported JBossAS 6 in Flex. However, since then we've made huge leaps an bounds with our Java and JBoss support in both Express and Flex. These have been happening in parallel with our work on JBossAS 7, so you can probably imagine how much midnight oil the teams have been burning over these many months! So here it is: OpenShift Express running JBossAS 7. Flex will be running JBossAS 7 very shortly, but we wanted to give people a taster with Express now! This is not only the first real enterprise PaaS, but it's the first one that is EE6 compliant! Hopefully you already know of the advantages of JBossAS 7, and these are all present in OpenShift. I've been developing on it for weeks and the first thing you notice compared to some other PaaS implementations is the boot time: it's so quick that deploying on to OpenShift is almost as quick as deploying locally! (OK, network speeds notwithstanding.)


One of the areas we've concentrated on with OpenShift+JBoss is improving the developer experience. For instance, we want to make it as natural to code for the cloud as it is when you're working locally and since many of our projects use git today, and the dynamic redeployment in JBossAS has always been an important feature for developers, we looked to combine the two in the cloud. As you'll see and hopefully experience first hand, with OpenShift we have JBoss AS a Service and you now simply push your application, e.g., a war, in a git repository and it'll be deployed automatically. It really is that simple!


So how can you learn more? Well not only have the teams been producing code, but we've also been working on a lot of collateral material, such as videos and blogs. Some of this is being released now, but we plan on releasing a lot more over the coming weeks and months as more of our projects integrate further with OpenShift. We'll also be giving various webinars, including a couple of deep dives into the architecture of both the Flex and Express integrations of JBossAS 7, so watch out for them! One theme that you'll hear through many of our videos is "Zero to Cloud in 30 minutes or less!" As I said, we've spent a lot of effort on simplicity and integration with OpenShift so you don't have to waste your time and effort! And the most obvious benefit of this is that you really can develop and deploy your applications in less time than it takes to read this blog entry!


One last thing: as usual for our open source efforts we'll have a forum where you can ask question and give us feedback. Our developers and users have made JBoss one of the most successful open source communities around. Moving to the cloud is intended to benefit those communities and grow them. So it's critically important to us and to me, that whether or not you're a Red Hat employee, you have a say in our future direction. Use the forums, raise issues, give us ideas for use cases we haven't considered. And if you have any problems with responsiveness or clarity, you know where you can find me.

For at least the past 5 years we hear from people that application servers are dead. And earlier this month we heard again how you shouldn't be using them and should be looking at lightweight solutions and the cloud. Phew! I'm glad that that's been pointed out to me, as I was really beginning to worry! Here I was trying to make sure we produced the fastest, most configurable, dynamic and extensible implementation available because it'll form the basis of JBossEverywhere; so we will have to stop that before we waste any more time.


Now of course I'm being sarcastic here. If you've learnt only one thing from my blogs over the past years it's that I don't believe application servers are going away any time soon. It should be no surprise to learn that those vendors who don't have an application server (hint ... not a complete stack) seem to like the original post, whereas those of us who do don't! But as I've said before, my background is as a scientist, so I try to put scientific method before business logic as often as I can, since it usually shows where the business logic will be going eventually anywhere! So try to believe that what I'm about to state is done in an objective way.


If application servers were to vanish, what would replace them? Well let's look at the arguments given for moving away from an application server because they've got to include the answer, right? So let's start with the usual reason for dumping the application server: "it's a monolithic piece of bloated code that includes more things than you really need." (I'm paraphrasing here.) I have this to say to all those who make such statements: try factoring implementation from requirements first before jumping to such conclusions! Yes there are bloated application servers. But then there are bloated implementations of many software components; if your chess program is taking more than 1k of memory then you should feel ashamed I'm not going to point names or name fingers but suffice it to say that not every application server should be tarred with the same brush!


This argument does lead us to ask what are the reason people need an application server? I'll start by stating that I am not going to go into the history of enterprise middleware over the last 40 plus years! I've done that before and there are also enough texts elsewhere that it's left as an exercise to the reader. Suffice it to say that there has been much research, development and deployment experience in this field that the reasons why your transaction service, say, does something in a particular way is very well understood. Fundamentally what the industry has learnt is that there are various core services or capabilities, that your average enterprise user needs. These include transactions, security, messaging, persistence and high availability. It doesn't matter whether you're developing in the bespoke world of the 1970s or through to the Java EE era of today, you'll be able to look at an enterprise application of that period and see those common core components in one way or another.


In the past, these components were thrown together into packages or toolkits for developers to use, with little thought as to how they could interact efficiently or even if they should interact at all. How you could, for instance, make developing transactional applications easier, was often an afterthought. This lead to inefficiencies in developer productivity as well as bugs! So we learnt that we needed to package these things better and consider how they interworked, how they could be used more easily and importantly, how they and applications using them, could be managed better. Why is it worth calling out management? Because the vast majority of these applications are deployed and expected to run for years (decades), so it is inevitable that the people who developed them will not be around at some point in the future.


All of these factors and others (e.g., threads and concurrency control) lead to the concepts of containers and developer frameworks, and from these came standards such as J2EE. Of course some standards are not perfect and they need a lot of love and attention to get them where they need to be. But if you look beyond the standard (or maybe beneath it) at the implementation, you can sometimes see the pearl in the oyster: that these core services are needed and must be packaged correctly or they are of limited utility. Just because a standard may not be good (initially) does not invalidate the reasons that spawned it!


We have answered the question of what are the reason people need an application server? So that should help with the other question of what would be the replacement? If you listen to some folks, it's an arbitrary collection of component implementations, many of which don't come from groups that have even thought about how they may work together in a single application, let alone be deployed for decades! If you listen to other folks the answer is a framework, but unfortunately even the best frameworks need something on which to run, and then you're left to your own devices! And of course I haven't even bothered discussing the niceties that standards bring, such as interoperability and portability, which often go unanswered or unavailable, if you take an ad hoc solution. And I probably shouldn't throw in a comment about lack of maturity of some of these components that are expected to work out of the box and with each other! So neither the framework nor hodge-podge collection of components is really an alternative. You will end up back in the 1970s, having to manage the stack yourself and figure out if version A of component B will really work well with version C of component D. That's hard enough at times with two components, so just try to imagine how hard it'll be when they become N components: O(n)!


But you might ask whether cloud is a game changer and we really need to unlearn everything of the past 4 decades or more, and come up with a completely new approach to enterprise middleware. If you do believe that, then I have a grape coloured cat I'd like to sell you too


In fact in the original post apparently the cloud is the way to go, or simply through Tomcat. Well I can't disagree with the former, since we are heavily involved with that through a range of approaches including OpenShift. PaaS is a good option for many developers, but guess what? Issues such as fault tolerance and security don't vanish as a result of moving to the cloud; if anything, they become more important (remember Amazon or Sony outages?!) You may want to abstract away from on premise APIs such as Java EE, but under the covers it makes far more sense to keep it application server based. (And keeping the EE APIs helps you with portability anyway - remember that you may actually want to move out of the cloud some day!)


And as for Tomcat? Well this is a great way to go down the hodge-podge route if you aren't careful. What you really need is an architecture that can start lightweight and grow seamlessly and opaquely with your needs so that the infrastructure takes the complexity! And yes, I'd recommend JBossAS 7 for that because we've designed it with this scenario in mind! There's also OpenChoice if you need something supported today.


One thing I do have to agree with is that your Java applications need a safe and secure place to run. But that place is here already. You really don't want to be reinventing the wheel just because you don't agree with the way it's packaged. Changing the packaging is a lot easier than changing the contents! And I'd argue that for many applications the packaging is pretty good anyway, especially if you don't want to be locked in by a specific vendor. (Look at CDI before you consider vendor specific frameworks, and doubly so if you've already gone down that route!)


So the application server is here to stay, even if it's under the PaaS covers. Yes there are implementations that do the rest of us a disservice because of their bloated ways. But we need to look beyond them. Maybe the problem is that the term "application server" is too tainted by the past, so we have to change it to something else (I like "Bob" for instance). After all, what's in a name?

Filter Blog

By date:
By tag: