Skip navigation

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!


Red Hat Research Day

Posted by marklittle 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.

Filter Blog

By date:
By tag: