1 5 6 7 8 9 Previous Next

Mark Little's Blog

156 posts
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?

When I first mentioned my JBossWorld keynote, I said that we planned to do a lot more behind the scenes work on this over the coming weeks. The aim is to give more details on what we did, because it really wasn't possible to shine the spotlight on the whole demo. Well, not only is the official video now available, but the aim is that the same page will start to contain more and more of the material that we're pushing out elsewhere, including Manik's blog post and the Asylum Podcast. We're also going to be announcing updates on twitter over the next few weeks using the #jbw2011keynote. So keep watching and listening!

Mark Little

JBossAS 7 is coming!

Posted by Mark Little Jun 4, 2011

Unless you've had your head in the sand for the past 18 months then you can't fail to have noticed the releases of JBossAS 6 and then the move through various betas of AS 7. Well we are on the final leg of what at times has seemed like a marathon and at others like a sprint. The team, which includes the various individual project teams, productisation teams, docs and QE, have been working flat out and I can tell you all that once we are finished with the EAP 6 release we will party!


But when AS 7 finally comes out why should you be bothered, especially if you're a user of one of our current releases? There are many reasons and some of them you would probably expect us, or any vendor, about to release the next shiny new product to talk about. So I could talk about the significant performance improvements we've made across a range of projects, such as HornetQ, JBossTS and Hibernate. I could also mention the reduction in runtime footprint that enables us to run the application server on a plug computer. Of course you probably already know about the rapid boot time and additions to our eclipse tool suite that make it one of the top Eclipse downloads. And you may have experienced first hand the developer-oriented features such as the new logging or streamlined build processes. So I'm not going to mention any of those things!


Instead I'm going to concentrate on a few of my personal favourites as well as those of the rest of the JBoss team. So in no specific order, here are 10 things you really need to know about JBossAS 7:


1: full and web profile implementation of Java Enterprise Edition 6. Of course we've been heading in this direction for a while, with previews in JBossAS 5 and a web profile in JBossAS 6, but this time we'll complete that journey and in style! Implementing EE6 is a challenge that only some vendors can match, but implementing it in a way that really shows the full power and flexibility of the standard is a far better and meaningful approach! Several of the key components within our application server have either been rewritten or updated to become best of breed, such as HornetQ, RESTEasy or Infinispan, or were best of breed to start with, such as JBossTS, Web Services or JGroups. If the whole is greater than or equal to the sum of its individual parts then this isn't just any old EE6 implementation, it's the best EE6 implementation!


2: a core part of EE6 and one of it's greatest improvements over previous versions, is CDI. This is a specification which we lead and drove through the JCP and where we also provide the reference implementation, Weld. The specification grew out of our experiences with Seam as well as various legacy frameworks that rely on XML for bindings. CDI makes the development of complex applications straightforward because it hides all of the complexities of non-functional capabilities such as transactions and security. And importantly it does this through annotations, so that you develop using POJOs, which is far more natural for Java developers than early 21st century techniques!


3: a new modular services container replacing the JBossAS 5 & 6 microcontainer. Now before you roll your eyes and move on to the next item, I know better than most that modular containers have been around for a long time. The original Bluestone Total-E-Server/HP-AS was one of the first implementations and we even created a JSR called the Core Services Framework to try to standardise on this type of architectural approach. And JBoss has had a couple of goes at this too. But this time we went back to basics, with the Modular Services Container, and wrote new algorithms for checking module/service dependencies at deploy and run time, such that only the services you need are loaded and started, and when no longer needed unloaded. You no longer have to trim your deployment to get a minimal memory footprint and start time: we give you them out of the box, and if you add your own services later to create new "profiles" then you can be sure that you'll always get the optimal configurations because the container will enforce that for you. As I've said several times over the past year or so, this is very much a SOA-like approach.


4: no more classloader hell! In conjunction with the MSC redesign, the team also took the opportunity to rewrite the book on how classloaders work. Now how you use classloaders, what type of classloader to use and when, are much more carefully defined. The modular approach makes the scoping of classloaders easier and more narrowly defined, helping to avoid conflicts: now you have to explicitly allow deployed services and applications to see and use dependencies. Oh and as a result of this rearchitecture you'll also see a performance improvement as the application server no longer scans the classpath every time a new class is loaded.


5: testable by design. Over the years we've learnt a lot about testing our projects in isolation and in conjunction with each other. Of course we use Hudson/Jenkins and we also inherited the Distributed Test Framework. But it wasn't really until the development of JBossAS 6 & 7 that we had the need to make sure that they were implemented from the ground up with testability in mind. As a result we have Arquillian which is being implemented in lock step with JBossAS 7 and also proving to be a hit in it's own right. In fact the combination of JBossAS and Arquillian offer an environment that is unparalleled in it's simplicity and power. Factor in other projects, such as Byteman, that allow for far more complex testing, such as fault injection, and you have an environment that will produce the most tested implementation yet.


6: configuration and domain management has been improved significantly. Gone are the days when you had N different configuration files for the M different components within the application server. Now there will be only one! And changing configurations is much better supported through a shell (command line) and programmatically, with both fully synchronised. If you've used Un*x shells then you'll find familiarity with the shell, with tab completion and an extensive suite of commands, which allow you to monitor and manage the application server as well as applications that are deployed on it. But beyond making managing a single instance easier, we've gone much further with clusters. Manual updates of changes to individual cluster members, often an error prone approach, have been replaced with the new domain manager, which automates the process using a master/slave or coordinator/cohort mechanism.


7: RESTful services and interfaces throughout. Of course with the adoption of JAX-RS as part of EE6, REST is now as well supported and available to application developers as Web Services. But that's not the same thing as having core parts of the application server available through REST. In JBossAS 7 we've now got projects such as HornetQ, Infinispan and management, exposing REST interfaces. And other work is being driven through the RESTEasy project as REST-Star, including transactions and security.


8: OSGi has evolved a lot over the years from its narrowly scope beginning. These days it seems that everyone is either looking to implement OSGi containers or develop their applications using OSGi bundles. A while back we announced that we would support OSGi on EAP 5 and beyond, but that we would not be using one of the containers already available. The reasons for supporting OSGi are fairly obvious, including the fact that it has become a de facto standard and we want to continue our mission of portability of applications (plus for some scenarios, such as SOA, a bundle is a very natural choice for deploying a service). But why not use one of the existing implementations? Well for a start we've got our own excellent container implementation. But realistically we want to support a range of models, so we don't want to rule anything out at this point. And our OSGi implementation on the new JBossAS7 container has improved the support significantly.


9: multiple language support. Ok, not quite a feature of JBossAS 7, but because we've made sure that we focus on developers and what they want, we've opened up a whole range of use cases that were rather difficult to do previously. So projects like TorqueBox, which offer Ruby users access to enterprise capabilities, have been able to spring up on JBossAS 6 & 7. And other projects, such as Infinispan, are finding calls for integration with, say, Scala on the rise. This is great, because it helps to showcase JBossEverywhere once again!


10: We've been sure to make the architecture of the application server cloud-friendly, so that it's the perfect substrate for an enterprise Java PaaS (and through indirection and abstraction techniques such as those employed by TorqueBox, for a much wider choice of languages as well.) Of course it's going to be a number of years before the Java Enterprise Edition standard really tackles the cloud through EE7 and EE8, but we are already pushing that envelope. If you're interested in seeing how the future of PaaS will unfold then you can get a glimpse of that by watching JBossAS 7 and beyond.


So there you go. 10 things that make JBossAS 7 stand out from its predecessors and the competition. Hopefully when you try it out you'll agree with some of these and maybe come up with some of your own (some things we may take for granted might be significant improvements in your life.) Over the next few weeks you'll see and hear more from us on AS7. And maybe, just maybe, I'll get a chance to make some more bigger announcements soon!

Mark Little

The Future of Middleware

Posted by Mark Little Jun 3, 2011

There's a special event being organised as part of Middleware 2011 called the Future of Middleware Event (FOME). I've been asked to contribute to the event and associated paper/book. It's an honour to be able to contribute to this along with others such as Doug Schmidt and Steve Vinoski (both friends I've known for a long time and who have had a significant impact on middleware over the years). It's also very relevant given everything else that I've been talking about recently. I'm looking forward to it because it'll be a great showcase for some of the things we're going to be working on over the coming years, as well as some of the things we've been doing recently!

Now that the dust has settled on JBossWorld and we've started to talk about JBossEverywhere, it's time to announce a few things that you should expect to see and be able to contribute to over the coming months and years. I want to write some of these pieces regularly to give everyone an idea of where we are going. Maybe at some point we'll create a JBossEverywhere project so there'll be the usual forums for people to use.


If you recall, one of the aims behind JBossEverywhere is to enable our projects and platforms to run on arbitrary devices. However, that is a relatively straightforward thing to achieve, at least with many of our projects. The ultimate aim is to design and implement an infrastructure that can support an application across a wide variety of environment, ranging from embedded devices through to the mainframe. To achieve this we'll be looking back as well as forward in terms of research and development. Approaches such as disconnected operation and dynamic adaptability from the 80's and 90's, genetic algorithms and event driven architectures from the past decade, and highly asynchronous distributed systems as well as the continuing rise of REST from the last few years and into the next, will be instrumental in the evolution of JBoss. But at the heart of what we will be developing will be core technologies such as JBoss Modules.


Now you may ask "will we be using <fill in the blank> as it stands?" For instance "will we be using HornetQ/JMS as it stands?" There's no stock answer that can be used, except "maybe". If you look at JMS, I think it has several deficiencies as far as Java EE goes, but it's definitely good enough. However, I don't believe it is the right API for a truly asynchronous message-oriented infrastructure. But that doesn't mean our implementation, HornetQ in this case, isn't right for that infrastructure. We've been very lucky over the years and all of our projects that support standard APIs such as JMS, JTA or JPA, tend to have far more flexible and versatile APIs under the covers. We may decide to use some of these APIs as they are, or we could provide more layers on top.


From the perspective of the implementation language, we'll obviously be concentrating on Java, but others such as Ruby, Ceylon and Scala will definitely play a role. We live in a time where multiple languages within an environment or application are the norm and to ignore that fact is either silly or arrogant. I like to think we are neither! So if you are not into Java, that doesn't mean you can't contribute. Quite the contrary: we need you more than most!


There are many questions that remain unanswered at the moment, and just as many that remain unasked. We don't have the answer to them all. I don't have the answers to them all (yet). But the fun bit is a combination of asking them and then searching for those answers. (Understanding the questions that you need to ask is often as informative as finding the answers to them.) But one question I've been asking myself for a few years is: precisely what is the abstraction we're trying to get? Well in a past life I did some work on distributed operating systems, where the abstraction presented to users was of a single, logical OS even if it spanned an arbitrary number of physical nodes/machines. (Let's ignore the facts that hiding distribution is often not the right thing to do!) This is the kind of abstraction I think makes sense for JBossEverywhere: the abstraction of a single logical middleware layer, even if it spans an arbitrary number of machines of an arbitrary type, e.g., mobile, mainframe or laptop. Domain specific APIs, such as Java EE, layer on top of this, adding or hiding capabilities where necessary. Because of course whatever we develop has to continue to be used within our EE suite of projects and platforms.


So does this mean, for example, that you can expect to see JBossAS running on natively on, say, an Android device? Well I really don't see why not, from a technical perspective. And I'd love to see it happen, as it's a logical extension of some things I started (and implemented) almost 2 decades ago! But this will be a long R&D process and the journey will be as interesting and innovative as the end results. And I'm loving the times that I can grab to put more flesh on to the bones of this goal: ubiquitous jboss!


I hope you are as excited by this as I am. How many other middleware vendors offer you the opportunity to get involved and shape the next generation? Most of them will simply say this is how it's going to be, like it or not. But that's not how we operate!

Every now and then I get asked to explain the differences between our projects and platforms. It's getting less and less these days, as most people now understand it. However, it does come up and it's worth repeating here. I was going to launch into my explanation, which is well rehearsed by now, but then someone reminded me that Rich Sharples did a great job of this last year on his own blog. If you're at all unsure about the differences between our projects and our platforms, then take a look.


However, there is one thing that I want to emphasise about this "split": everything we do in our platform work goes into the "upstream" open source projects. We don't keep anything back from the communities that help to create the projects. As Rich explains, our productisation processes push the project code through a set of very stringent processes, e.g., qualifying against a range of database drives, hardware platforms and operating systems, to which the communities may not have access or the time. Yes, it can take weeks or months for us to iterate through our processes to create the necessary quality, fixing code, applying updates that we, or the community, didn't realise were necessary originally, etc.


But once we're done and we are sure that the resultant product can be released, we make sure that the changes go back into the project source repositories. Of course it may not make sense for us to put them back into the trunk of the project, e.g., the project may have moved on to a new major release. And code changes the productisation engineers make often go back into the code for the community projects as soon as they happen, especially if they are major functionality bugs or security issues. Disenfranchising our open source communities is not something we've ever done, or considered and it's not something that we're going to start now!


Our platforms benefit from our community work. Our communities benefit from the platforms too. So what is the benefit of the support contract that Rich mentioned? Well, as he says, using EAP as an example:


"JBoss EAP is supported for 7 years and with every additional minor or micro release we further improve the performance, security and stability of the Enterprise Platform. We’ve now released 2 micro and one minor release of JBoss EAP – that’s about 150 top-level issues in total. While the issue rate will slow over time – we’ll still be in a position to fix issues and respond to new security threats in 2016.

All those fixes are made available upstream and will ultimately make there way in to upstream binary releases but what the upstream project can’t guarantee is that those fixes will be isolated from more substantial changes and improvements – community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation."

So if you're wondering whether or not we're still the home of open source, as I said last year, the answer is yes. We do everything in the open and we keep nothing back from our communities. I'm fairly sure many of our competitors cannot say the same thing!

I've been tracking the TorqueBox team for a long time, even when the "team" was really just Bob McWhirter. I like what the team are doing and have even been pulled in to learning Ruby and contributing the initial transactions support. So it was good to be able to attend some of their team meeting at JBossWorld and hear the plans for the future. It was also interesting to realise that TorqueBox is yet another example of JBoss Everywhere: providing the enterprise capabilities offered by JBoss projects and platforms to a wider audience of users and developers than we've done traditionally. Who knows ... at some point maybe we'll look at other languages than Ruby to do something similar. Until then check out TorqueBox and my congratulations to the team!

Mark Little

Ubiquitous Computing

Posted by Mark Little May 16, 2011

So just what is JBossEverywhere then? If you've seen the video of my keynote then it should be clear. However, I want to go into more details here just for the avoidance of doubt.


What it is not is simply a way for writing thin client applications that access various JBoss components or services that are running elsewhere. It isn't a new framework for writing HTML5, JavaScript, GWT or native web applications. It may utilise these technologies to achieve a goal, but that goal is so much more.


As I said in the presentation, the underlying theme behind JBossEverywhere is ubiquitous computing. Now there is no way I can take credit for that concept: ubiquitous computing has been around for many years; I remember it being discussed by all of the big middleware and hardware vendors at the turn of the century, as the next big wave. Some people may be forgiven for thinking that it simply didn't turn out that way, but they'd be wrong. You only have to look around you to see that it happened (is continuing to happen every day.) We just take it for granted that technology is an implicit part of everything we do today, yet you only have to turn back the clock a decade to see how different it was. And go back 3 decades, as I showed in the talk, and you could be walking into an episode of the Twilight Zone!


But what has this impact of hardware got to do with anything I want to discuss here? Put quite simply, these devices are an area where middleware, and JBoss in particular, can play an important role. Just as the new wave of personal computers were thought of as constrained 30 years ago and often looked on with distain by those in the workstation and mainframe arenas, yet now they power a lot of enterprise computing, so too will go many of the devices we see around us today as being of limited utility.


Your mobile phone already has capabilities that would put to shame PCs of the 1990's. They have also quickly become critical to our day to day lives, moving from supporting basic games to complex B2B applications. These applications need enterprise capabilities, such as messaging and transactions. In fact I've believed this for over a decade, having made Arjuna run on an HP Jornada 720 in 2000, with the intent to take this further had HP decided not to junk Bluestone only months later! A lot of the work I've done in intervening years on extended transactions and end-to-end transactions has also been an offshoot of these thoughts.


But it's not just mobile phones. Due to the economics of scale, it's not far fetched to assume that sooner than you think your washing machine, car or even coffee pot, will have more raw processing power than workstations or laptops of years gone by. Being able to tap into these processors is something that will happen, security considerations not withstanding. In fact as I've said before, this is really where I think cloud will go (return). At the moment cloud, or at least public cloud, is little more than offshoring; useful yes, but not taking things far enough. The true cloud is the processors around us, and being able to use that cloud offers many advantages and opportunities. And once again, middleware will be useful there.


So JBossEverywhere is about defining middleware components and frameworks that can be used on these various devices. We should not expect people to reinvent the wheel, e.g., transactions, when there's a perfectly good wheel already out there. It'll mean developing new projects and pushing the envelope, but that's what we're good at. New frameworks that will combine adaptability, configurability, monitoring etc. to allow them dynamically cope with changing deployment environments so that the application doesn't have to (in many cases.)


I suppose another way of stating the goals of JBosEverywhere is Ubiquitous Middleware, or specifically Ubiquitous JBoss!

Filter Blog

By date:
By tag: