1 4 5 6 7 8 Previous Next

Mark Little's Blog

148 posts

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?

Mark Little

JBossAS 7.0 is here!!

Posted by Mark Little Jul 12, 2011

There have been many highs in my career and many of those have happened since I joined JBoss and took over from Sacha. But today has to be in my top 1 or 2 ever! Today we can officially announce the release of JBossAS 7.0 Final! And it's EE6 Web Profile compliant too, so check out the project pages. It's taken us a while to get here and we've taken some pretty drastic and innovative steps along the way. Sometimes those decisions haven't been ease to make and we've thought long and hard about them. For instance, I recall Jason Greene, Scott Stark and I discussing for ages the various ramifications of continuing with the then current micro container architecture versus radical changes. The decision to change wasn't easy, but even then well over a year ago, we believed it was the right one to make. And now, with the new micro services container, it's proven itself! Some risks are worth taking.


But not every problem on our path has been technical or come from within Red Hat. Without going into details, let's just say that at times it seemed that processes and red tape were being thrown in our way. However, we got past these and the results speak for themselves: the fastest, most configurable and adaptable EE6 implementation (Web Profile) out there. And full EE6 is next on the roadmap, with JBossAS 7.1 due out soon. So if you haven't already tried it I encourage you to download it and give it a try.


I want to take this opportunity to thank everyone who has been involved in the development of JBossAS 7.0. This includes a diverse group of people including the projects, our QE teams, docs, support, product management, program management, marketing and many others. It would be impossible to single out those individuals who have stood out during the last 18 months since everyone has been a rockstar. However, I do want to mention Jason Greene again: any team is influenced both negatively or positively by it's leader and Jason has lead most positively by example throughout. And of course Bruno Georges, the engineering manager, who took over the role just over a year ago and mustered his troops so well! See what I mean? It's really hard to call out one person without immediately thinking of all of the others involved! A great team effort.



Mark Little

Red Monk interviews

Posted by Mark Little Jul 11, 2011

As you can imagine, there was a lot going on at JBoss World/Red Hat Summit this year and I've posted bits and pieces about this already. One of the things that always happens at these gatherings is interviews with press and analysts. Well this time was no exception. But one of the ones that stood out for me was the RedMonk interviews by Stephen O'Grady. If you haven't already seen them then check them out, as Stephen separately interviews Mark Proctor, the Drools lead, and myself. Both are worth listening too as you'll get some great sound bites on our project/product split, our long term vision and aspirations, and I think a reference to an upcoming workshop that RedMonk are holding coincident with a beer festival!

Mark Little

Independence Day

Posted by Mark Little Jul 5, 2011

Whether or not you live in the US, it's hard not to know that the 4th of July is American Independence Day. This is the time when they celebrate winning the War of Independence from the British Empire, though really I think we let them win ;-) But either way, it's an important day, which has also been used to a few times to mark other events, such as the thinly disguised remake of H G Well's War of the Worlds. Well as fate would have it, we're about to release JBossAS 7 Final and it just so happens that it'll be so close to Independence Day we simply couldn't pass up this opportunity!


I've already discussed 10 reasons why you should be interested in JBossAS 7, as well as how this really represents a significant move away from the past. Hopefully you also registered for one of the sneak peek webinars we've been giving, and maybe you were at JAXConf recently to get some hands on demonstrations of what AS7 can do. But think of this too: with JBossAS 7 we're giving our communities the chance to declare independence from their previous overlords (aka closed source application servers)! Learn a lesson from the people of 1776 and stand up for your rights: no longer should you have to suffer the indignities of slow boot times and bloated containers taking up all of your available memory and processing power; cast off the shackles of 20th century architectural application server oppression.


Yes, yes, I know this sounds a lot like a sales pitch, but I'm a developer. I've been developing application servers since the 1990's and I've been using JBoss since the 3.x series. And putting my objective hat on for a minute, I can say that I have never come across a Java application server (or container) that performs as well as JBossAS 7 does or has the modularity and capabilities it has. So if you're using an application server, or just using some components, such as JMS or transactions through some other "lightweight" framework, then you really should check out JBossAS 7 Final!

Mark Little

Taking a stand! Part two.

Posted by Mark Little Jun 30, 2011

We've discussed some of the fallacies that are rumbling through our industry at the moment. Now let's get to some facts and what JBoss is going to do to address them. And this brings us finally to our position and vision behind JBossEverywhere: it is ludicrous for us to discard the experiences, code and communities that we've built up over almost a decade of development. JBoss and open source middleware are intricately linked. Since it's inception back in the early 2000's, JBoss has had various missions and has succeed at them all. Some closed source companies have had to change as a direct result of JBoss. Some have even gone out of business. It's arguable that JBoss has also contributed to the success of a number of other open source projects and companies. Since the acquisition by Red Hat, the JBoss brand has grown more and more successful too. But fundamentally our success is not simply the revenue that we make, though of course that's important (we all like to get a monthly salary!), it's better measured in the number of projects and platforms we have and their technical and community maturity. This isn't looking for plaudits, it's simply a fact.


For the past few years we've been focused on Enterprise Middleware as it is defined in the context of J(2)EE and hence servers and mainframes. That isn't going to go away and Red Hat/JBoss will continue to be a strong voice in the JCP Executive Committee as well as the most popular implementation. But we see so much more applicability for what we have when we look beyond these environments. And yes, that means beyond the current definition of Cloud. As I said above, there are more processors sitting relatively idle today that people will want to tap into eventually. Some of those processors may well be sitting in your home or office now. Rather than those communities having to reimplement the wheel, we will be working with them to ensure that the perfectly good wheels we've got can be positioned in those deployment environments too. We are seizing ubiquitous computing.


So where will we be in the next 5 or 10 years? Well for a start I'm pretty sure that Java will still be the dominant runtime language and that the Java EE 6/7/8 Application Servers will be at the forefront of enterprise deployments, with the JBoss implementations at the front here too. But developers will always want to use other languages that are more domain specific. For JBossEverywhere this just means that we'll be ensuring that our runtime is available across a much wider set of deployment environments and exposed through as many other languages as makes sense to our communities. If that means we have to develop new projects from scratch, then we will. If it means we have to write in other languages then we will (TorqueBox is only the beginning!) If it means that we have to modify some of our existing projects to better sit in, say, a car engine management system, then we'll make those changes. But I believe strongly that many core enterprise requirements can be met today and in the future by our existing implementations.


Now you might ask why I'm so positive about the future of Java and Enterprise Java, when we keep hearing so much doom and gloom? Well I'm not going to suggest that there aren't problems with the current Java processes and if we were happy enough to be lead through this period then we'd have problems. But we are a leader and we won't sit idly by and let things stagnate. You only have to see this with some of the new standards we're pushing, such as JSR 347. And a lot of our rearchitecture of JBossAS 7 and the modular services container gives the ability to look at multitenancy and multi-core approaches.


So can I make a fairly obvious mission statement to attract the soundbites? How about this: if JBoss doesn't seize the ubiquitous computing landscape then it will be displaced by others? I think that counts So how are we going to do this? Here are my four steps to succeeding.


  • Step 1: make our projects highly embeddable and dynamically configurable. Take a look at the keynote for an example!
  • Step 2: make our projects and platforms available through a range of different languages and not just on the JVM. Scala for instance!
  • Step 3: make our projects known about and open to a much wider community of users and developers. Just because someone isn't interested in using a project within an application server, doesn't mean they are irrelevant. For instance, jBPM 5 running on Android!
  • Step 4: keep pushing for improvements in the Java language and the JVM, as well as looking at other domain specific languages or extensions.


So if you're in our communities or just thinking about moving into the Java space, what should you do? Well here are a few recommendations:


  • Get involved with our communities are feed in your requirements, as well as code.
  • Encourage your developers to experiment with other languages that run on the JVM, and our implementations if possible, such as TorqueBox.
  • Talk with your teams about their mobile requirements - they will almost certainly have them and knowing about them now will be better for you than having them creep up at the last minute!
  • Create a tiger team to specialise on constrained device applications.


JBoss defined open source middleware for the last decade, and arguably influenced strongly closed source too. We are defining it now for the next decade at least! If you want to stick with legacy frameworks for developing languages, then knock yourself out. We'll work well with them, just as we do today. But really, we can do so much better! JBossEverywhere isn't about telling you what you already know you need! It's about showing you what you will need in the future. This is not just about improving JBoss technologies, but about improving the way in which people will work and interact!

Mark Little

Taking a stand! Part one.

Posted by Mark Little Jun 30, 2011

I've been talking about the ideas behind JBossEverywhere for a long time and diving into details during and after the keynote. I've also presented on these concepts since to several JBUGs and other groups. Most of the people I've spoken with just "get it", but there have been occasions where I've had to dive into a bit more detail to fully explain what I mean: some things that may seem obvious to me aren't necessary that obvious. Plus I've been asked that despite the vision, what is our stand or position? Well hopefully this article will settle things so we can move on and get this done. Before I go on though, it's worth stating that this will be an unapologetically Java and JBoss specific article: I can make many of the same arguments you're about to hear more generally about middleware, but I'm not going to do that!


OK what is our position? Well let's look at some positions or visions that have been attributed to others in the same area we operate. One of them is that Cloud is the death of middleware. Hmmm. Now if that statement had been made by vendors who don't have a vested interest in persuading you to move away from existing middleware implementations to their own, or who don't have any investment in middleware, I might give it more than a few seconds thought. Now of course you could say that given my position, I'm hardly being objective either, and to a degree I can see your point. However, I've lived through 3 decades of middleware standards and implementations, including DCE, CORBA and J(2)EE. My background is heavily influenced by scientific method and analysis, so I try to be objective even when it may go against perceived business sense.


So let's just assume that for the rest of this article I'm writing with my professorial hat on and not my Red Hat, OK? And let's think about that statement: "Cloud is the death of middleware". What does it really mean? I think we first need to look at what is meant by middleware, which is pretty poorly defined. Given the vendors involved, I suspect it's more Enterprise Middleware that is assumed. So what is being suggested is that security, transactions, reliable messaging, availability etc. are no longer required in the Cloud? Give me a break! Let's look at a human-centric equivalent of (public) Cloud: outsourcing. If you've ever been involved in outsourcing something, such as IT or a call centre, then you'll have drawn up a set of questions or rules by which the prospective recipient who will run the outsourced effort must be held. These would include looking at their plans for high availability, security of your data (particularly if they host data on behalf of your competitors) and especially how to get in contact with then 24x7 in the case of a problem. If you don't have such a set of criteria and you have outsourced then please let me know so I can make sure I never use you and that if you have any of my data then I can scrub it from your system now!


Public Cloud, or at least public PaaS, needs good middleware and needs it now. When you look at what PaaS really is, then defining it as Middleware as a Service is not going to be far off the mark. Why isn't it defined this way? Well just look at where the term PaaS comes from and that will give you your answer. Middleware techniques and protocols have been developed and honed for well over 4 decades and in many cases haven't changed for years. Of course Cloud offers new problems and challenges, such as multitenancy, but some things remain fundamental. And what about scalability? Hmmm, have you ever looked at the Web? That's a pretty big system! It dwarfs any Cloud data centre and works pretty well. So let's put this one to bed: Cloud isn't the death of middleware! Far from it.


Before moving on, let's tackle a related statement: that Java Application Servers are either heavyweight or dead. Again, this isn't being said by people in an objective manner. I've already discussed this issue separately, and you should take a look at that for completeness. However, the general gist of that article is that a good implementation of the Java EE specifications need not be heavyweight, bloated or irrelevant to applications that don't need all of the enterprise capabilities. Java EE 6 and beyond are the right stacks to consider, both for small scale and large scale applications, and specifically JBossAS 7. Maturity of implementation is critical in these areas for very obvious reasons, and we have a set of best-of-breed components that other vendors are trying to replicate and continuing to fall short on their aims! The concept of the Application Server will evolve over time, pushed by requirements and restrictions on different deployment environments, but let's not try to kid ourselves that somehow it simply isn't needed: it is, but what *it* is tomorrow will look very different from what it looks like today. And guess what? JBossAS 7 is *it*!


Another position I've heard recently is that Java needs to make itself relevant in the Cloud or cede the space to languages such as Ruby. That's so profound and visionary. (Where did I put those sarcasm markups?) That's about as obvious a statement to make as, say, a football coach telling his team that "If we score more points than our opponents then we'll win." Come on, surely we can do better? If any language cannot adapt to changes in the industry then it will be replaced by those that can. That's the way it's been for decades, and no I'm not going to drag up the COBOL reference (oops!) Java, the JVM and Java middleware is already relevant to a large part of the community that wants to move to the Cloud. Of course there are challenges, and I mentioned some of them before, such as multitenancy, which need to be better addressed in the language itself. Statements like that may make good soundbites, but not much more. (I really wish I could remember where I mislaid my sarcasm markups!)


As a community I have faith that we'll make those changes and we are definitely involved in pushing those changes forward at a much quicker pace than we've been used to before. But the Cloud, and specifically PaaS, isn't going to be a mono-language area. There will be many different languages for different use cases. But where we stand on this should be fairly obvious, particularly if you roll up both of the positions we've considered so far: for Enterprise PaaS you need Enterprise Middleware, and if CORBA taught us anything it's that you can have a single runtime written in a language that isn't used by your developers and as long as that runtime is good (efficient, reliable, manageable etc.) then your users/developers won't care. They'll see all of the advantages and none of the disadvantages that they associate with the underlying language. We're seeing that already with projects such as TorqueBox, where Ruby developers can use the application server without ever having to know Java. And we'll be seeing more of these kinds of projects from JBoss in the future, but read on.


But even looking at these previous two statements they are far too narrowly focused. Yes Cloud is important today, but it's not where we should be putting all of our attention. That needs to be in the area of ubiquitous computing, which should subsume Cloud and mobile. Let's look at mobile for a few moments, and with apologies to others, I'll state what seems to me to be a fairly obvious fact now: there will only be two dominant platforms in the future; iOS and Android. Of course there'll be needs for niche players, but the old order has fallen. Smart phones will dominate and the types of applications that people want to write on devices, such as phones or pads, are already increasing in complexity. Native applications aren't going away any time soon. Yes, I know this kind of bucks the trend, with others pushing for thin clients in general such as the Chrome Book (and yes, I know this isn't for a mobile phone but stick with me on this). But look at it this way: if all we wanted to do was run a browser on the phone to access applications or data that are hosted elsewhere, then we probably should have stopped innovating with the hardware a few years back!


There are billions of phones on the planet. But there are tens of billions of processors, including those in your washing machine, games console or car engine management system. Many of them are more powerful than workstations from 2 decades ago! This is ubiquitous computing. It's pretty obvious that the types of applications that will eventually be written for them will grow in complexity and store more information locally. (I've lost count of the number of times I lose wireless or phone signal on my phones and pad!) Application developers, whether on the phone or embedded devices, will want the kinds of capabilities that we take for granted in the JBoss world, including messaging, transactions and security. This is ubiquitous enterprise computing!


So now on to the second part of this stand ...

Do you know how big your operating system is? These days, with cheap memory and ever faster processor speeds does it really matter? Do you know what's going on within the operating system? Or how much of it you use on a daily basis? The answer to all of these questions is probably no; in general, operating systems today are extremely well written pieces of software, often modular in nature and making efficient use of available memory and processing resources.


But if you do look into you favourite operating system, either by taking a look at the source code or it's architectural manuals, you may be surprised to learn what it has to do in order for you to just read email, write a document, or browse the web, or do all of these safely and concurrently. You'll most likely find that there are also many services or capabilities within the operating system that you may not need on a day to day basis. For instance, atomic (or even transactional) updates to multiple filesystem entries. However, if the types of applications you use increase in complexity then some or all of these things will be needed. And these days you don't have to download them into you operating system before you can run the applications: they're so well implemented and efficiently integrated already that you don't notice them when they're not needed.


This is all well and good, but what has this to do with middleware? Well we've heard a lot over the years about bloated middleware and the need for lightweight stacks or frameworks. Now I think a lot of the hype over these has often been driven by vendors or individuals with ulterior motives. Of course there are or have been suboptimal middleware implementations, where what you didn't need really did get in your way, e.g., through perceivable performance overheads. However, to infer that these are the normal situation is inaccurate. As is trying to give the impression that specific middleware architectures, such as Java Enterprise Edition, are necessarily bloated from the start. Sure if you provide a poor implementation that may be the case, but a good implementation should be far closer to the operating system analogy that I mentioned before: if you don't use something then you won't know it's there, but when you really do need it, the implementation will make it available to you opaquely.


Now of course I'm leading this topic to the subject of JBossAS 7, because it's a perfect implementation of what I've outlined above. The new architecture, including the modular service container, mean that services you don't need aren't going to impact you. But if your application, or something on which it depends, eventually has a dependency on one of these services, then it'll be made available automatically. You don't have to know a priori what you need, or have an in-depth knowledge of 3rd party dependencies. As a result AS7 boots in seconds and has a footprint that means it is highly embeddable.


So why start with just a web server, building up an ad hoc application server through trial and error, when there's an enterprise container that gives you the same performance benefits with no downsides? It's a bit like saying you should start with a raw file system, paging and swapping, and the concept of processes, then when you need them introduce threads, locks, shared memory and IPC. Not exactly the most efficient use of your time! With JBossAS 7 you will be able to use the application server for simple applications and not have to worry about the services that you don't need just yet. But when your needs increase, you can be sure that those services you didn't plan for previously will kick in, just as they do within the operating system you're probably reading this article on now. And since you probably don't even worry about what that is doing, why should you worry about what JBossAS 7 is doing for you under the covers? Let us worry about that and let us get it right so you don't have to!

I mentioned earlier about presenting at a couple of JBUGs this week. Fortunately both presentations were on the same subject: where next for JBoss. Both events were packed. I'm not sure of the exact make-up of the audience in London (and thanks to Atos for hosting!), but in Newcastle we had people from the University as well as several local companies, all either existing users of our projects or considering using them. In Newcastle we managed to duplicate the keynote demonstration too, though this time without the mobile device UIs that we showed in Boston. It went very smoothly! There were some good questions too around some of the underlying aims behind JBossEverywhere and hopefully I persuaded some of the new attendees to come back to future events.


At the London event I didn't have the luxury of the hardware we used for the demo, so instead I took a copy of the official video. Again it was a packed room, with a number of JBoss/Red Hat people there including Manik Surtani (who was wearing almost exactly the same outfit as he did in Boston!) So once I ran through the slides, we watched the video and I took questions again. Some of the key concepts seemed to resonate with folks, although there were specific questions around Cloud and how it relates: as I tried to say in the video, I think this is the future of Cloud, so our current strategy with efforts such as OpenShift are complimentary. Plus as I pointed out during the talk, it's good to have a vision to catalyse people and focus their efforts.


I enjoyed presenting at both events. It was good to hear comments and suggestions. I know that this theme is something that I'll be focussing on quite a bit for the rest of this year, with several presentations already submitted to a variety of conferences and workshops. And maybe other JBUGs if there's interest!

Mark Little

JBUGs coming up

Posted by Mark Little Jun 12, 2011

If anyone is interested in either hearing about the future of JBoss, or see the demo that we gave at JBossWorld, then you should either come along to the Newcastle JBUG where I'll be giving the presentation and then we'll be running the demo, or you can come along to the reformed London JBUG where I'll be giving the same presentation (though no demo). If you just want to ask me any other questions then come along anyway!

If you've watched the video of my JBossWorld keynote or followed other presentations I've given around the future of JBoss or middleware in general, then you may have heard me talk about JBoss technologies evolving into a fabric, or ubiquitous middleware that is always there, in the background, no matter what device you may be deploying your application on. The name "fabric" springs to mind, though it is used by many others to mean different things. I suppose another word to use might be "ether", given the historical use of the word in the physics community. (OK we would need to ignore the fact that the belief in the ether ended when Michelson-Morley's experiment proved it did not exist.)


Let's stick with Fabric for now though. Well at the Red Hat Partner Summit I was giving a presentation on The Future of JBoss and was talking about JBoss as a Fabric. I've used a number of analogies to try to illustrate what I mean by this, including the distributed operating system one I've used before. Another one I used was that of TCP or UDP: capabilities that we all just take for granted these days, no matter where you're deploying your application these days. Now of course not all of the JBoss capabilities (projects) will be available in all environments. So in the grand tradition of cloud (to which we are most certainly not tying Fabric), I suppose we are talking about Just enough Middleware (JeM), Just enough JBoss (JeJ), or Just enough Application Server (JeAS) - though I've used that one before.


So what next? Well I'm fairly sure I want to create a new project for Fabric so that the wider community can get involved, though I may wait until after AS7 goes final. That means a project name of course, which is a problem as I'm not so good with names. Maybe Aether?

Filter Blog

By date:
By tag: