Tech Chat: CTO Mark Little on EAP 5, RESTful SOA, and Future Directions for JBoss
DZone recently had a chance to sit down with Mark Little, newly appointed CTO of the JBoss division of Red Hat. In this interview, Mark provides an update on some of the new architectural features in the Enterprise Application Platform (EAP) 5.0 including improved transactional and messaging support. He also provides a status update on several other key projects, such as Seam, JSR 299 (WebBeans), JBoss OSGi as well as the latest Drools 5.0 release. Mark also revisits the REST vs. WS-* debate and delves into how cloud computing and REST are helping Red Hat productize its SOA offerings. Finally, he provides his vision for the future of the JBoss platform and its ecosystem of evolving projects.
The complete transcript of the interview has been provided below:
DZone: We are sitting today with Mark Little, CTO of the JBoss division of Red Hat. Mark was previously chief architect and co-founder of Arjuna Technologies, and has been working in the area of reliable distributed systems since the mid-'80s. More recently, Mark was SOA technical development manager and director of standards at JBoss, prior to taking over as CTO in March. Mark, firstly congratulations on your new role.
Mark Little: Thanks so much.
DZone: During his tenure, Sacha Labourey was pivotal in growing JBoss Europe from a business perspective, as well as seeing through the JBoss transition to Red Hat post-acquisition. Is Sacha's work complete, or will you be continuing to focus on some of those things?
Mark: It’s probably accurate to say that the first phase of Sacha's work is complete. We are in a much stronger position in Europe now than we were prior to the Red Hat acquisition of JBoss. The goal there is to prove globally that we're now concentrating on APAC and South America as well. I can see that as the second stage of the work that Sacha started.
DZone: As newly appointed CTO, what are some of your biggest challenges in the short term?
Mark: I think that probably the biggest challenge that I have at the moment is to continue the integration of JBoss and Red Hat. When Red Hat acquired us, we had our own processes, our own way of doing things. The Red Hat guys had very similar things. Over the last couple of years, we’ve tried to redefine processes as unified development methodologies. We've gone somewhere down that line; we haven't completed it. We need to make that more streamlined and agile. But we've taken things that are very central things. In some cases, just because Red Hat have some processes that seem to work for operating systems it doesn’t necessarily mean that they’ll work for middleware and vice-versa -- so it's bi-directional. It's not like we're having to adopt Red Hat approaches to integrate JBoss into Red Hat. Red Hat is being very, very flexible in adopting some of the things that we believe could provide a beneficial change to their process.
DZone: The JBoss ecosystem of projects continues to grow at a very rapid pace. JBoss Cloud, Infinispan, and JBoss OSGI are just a few examples of some of the more recent projects that have been added to the portfolio. What are the specific criteria needed in order for something to become an official JBoss project?
Mark: There aren't really any specific criteria – they’re more like guidelines. If somebody thinks that a component in a project, for instance, might be more applicable to other projects or to the wider community, they can spin it out and create a new project. So for instance, the JBoss messaging team has been working on JBoss Messaging 2.0 for a long time, and one of the areas that they've been looking at in terms of improvement over JBoss Messaging 1.4 is performance and reliability and scalability. And one thing that's part of that is a new high-performance logging implementation.
There are other areas both within and outside JBoss that could also use this logging implementation. At the moment, we are actually spinning that out as a separate project where it can be more easily consumable.
If it stays within the Messaging project, then you have to consume the project, JBoss Messaging, in order just to get that small component that you may have needed. Although there are no strict guidelines, we tend to do it often on an as-needed basis, and we're very, very lightweight in that regard.
DZone: The enterprise application platform, or the EAP, combines popular JBoss.org technologies like Hibernate, clustering transactions, together with the JBoss application server. At what point does a JBoss.org project graduate to become part of the EAP?
Mark: It's a combination of things. Obviously customer need. The EAP is a commercial-facing product, so obviously what our customers want, we'll work very, very hard to provide them with. But with very few exceptions, what we also try to do is make sure that that thing gets trialed in the community for as long as possible. And that's one of the good things about the whole open source methodology. So we will try to have something as a community-consumable projects for 6, 9, maybe even 12 months before we push into EAP.
There may be a need for exceptions, but we do those as exceptions, not as part of the rules. So we would really like to have projects consumed by the community, so you get community feedback on the quality. And we can modify the project much more flexibly and dynamically in the community than we can in a platform which is not very scalable and slow to move from one place to the next.
DZone: Switching gears a little bit, can you give us an update on Seam and JSR-299?
Mark: JSR-299 is the dependency injection JSR that we've been working on, driven by Gavin King in collaboration with Oracle, IBM, and others in the Expert Group. It's been progressing quite nicely. It passed the vote to proceed to the next stage of adoption. I think at this stage, we're six to eight weeks away from being included in [Java] EE 6. So that standardization work is progressing very nicely, and JBoss and RedHat as a whole is always behind fulcrum standards, so this is why we think it's very important to have it standardized, so we can have it adopted much more widely than just our own implementation.
In terms of Seam, that has been progressing extremely well. The Seam team has also taken on the implementation of the reference implementation from JSR-299. They've been working to integrate the Seam framework into other containers. Obviously it works well within the enterprise application platform. They've been integrating it into our SOA platform.
And generally again, going back to what I was saying earlier, that community adoption, pushing it through the community route, is going extremely well and successfully in lots of projects. And that's been influencing it outside of the standard as well.
DZone: In a recent blog entry Dimitris Andreadis suggested that at best, maybe 20% of real-world systems stand to benefit form an OSGI-based kernel for building modular applications. In other words, the average system, in his opinion, really doesn't benefit from the super-modularity afforded by an OSGI-based architecture. However, shortly thereafter we saw the beta release of JBoss OSGI 1.0. Mark, would you agree with Dimitri’s sentiments on OSGI? And secondly, what are the motivations behind adding OSGI support to JBoss AS 5?
Mark: I agree with Dimitri’s statements, but I'd actually make it wider. I'd say it's not just OSGI. Let's not concentrate on whether OSGI only tackles 20% of the architectures out there. Lots of companies, going back almost 10 years, have looked at providing flexibility in their containers within J2EE more recently, and even before Java came along. Flexibility like that provided by OSGI, or even our own micro-container, is extremely important to a certain set of applications. It's also very important for a product company in order to allow us to use different products essentially on the back of the same components, with different configurations of these components.
Yes, it's not something that every single developer out there is going to want. Out of the box, probably 80% of developers will be very happy with a default EAP configuration. But there may be some developers who need a bit more flexibility and maybe don't need something like Web Services, or don't need transactions or messaging. They may want to configure out of a system in a dynamic way without having to come back to the company in question and getting them to modify the code.
So from that respect, yes, OSGI definitely does not tackle a space that a 100% of users will want, but it still tackles a very important area. From our perspective around OSGI, we've been working with OSGI maybe for the last few years. We've made announcements about OSGI before, and the JBoss OSGI announcement that you mentioned is another step in that direction.
We see OSGI as important to allow us to offer to our customers the ability to take services that may have been written and deployed outside of JBoss and deploy them onto our application server.
Before there was a standard for a service model, like in OSGI, that would have been very difficult, if not impossible. So we don't actually see within JBoss's OSGI a replacement for our own micro-container. In fact our own micro-container is in many ways a superset of OSGI functionality.
What we need is a standard way to allow users to migrate their services or applications from other application servers or other containers into the JBoss ecosystem.
DZone: Can you describe some of the work being done around the core middleware services in the next major release of the JBoss Application Server?
Mark: Yes. We updated quite a bit in the next release of the EAP. The next major release is EAP 5. That would be based on JBoss AS 5.1. Amongst the major changes are things like support for distributed transactions. We've had a distributed transaction manager in JBoss for the last four years now. It's standards-based, based on the JTS. But we have not actually been able to support it in the application server, at least in a platform release like this, I should say.
That is now coming, so EAP 5 will have support for the JTS in it. Following on from that as well, we'll have support for our Web Services transactions product. So this is the one that we've again had for a number of years. We've demonstrated interoperability with Microsoft, IBM, and others on this.
And the EAP 5 will be the first firmware that customers will be able to get support for. It will be in JBoss AS 5.1 as well. So the community, again, will be able to play with that. In fact they're already doing that and we're getting some good feedback from the community in the forums.
I mentioned it earlier, but the JBoss Messaging team has been doing a fantastic job of improving the JMS implementation. JBoss Messaging 2.0 will be in EAP 5. So people will be able to get a hold of that and see the performance and scalability advantages that those guys have been concentrating on a lot.
We'll have a new Web Services stack in EAP 5. We made an announcement a few weeks ago -- in fact I think it was one of the last things that Sacha announced -- about adopting the Apache CXS project as our default Web Services stack. So that's coming. There will be a preview of that in the EAP 5 so customers and users are going to be able to play with that and give us feedback.
Probably the biggest change in EAP 5 is one we've referenced already, the micro-container. So everything has to be re-architected to work with the micro-container and that gives us the flexibility of architecture that we need to allow us to support the new models that are coming in the community and in the industry.
DZone: The JBoss Drools team has recently released Drools 5.0, that contains some interesting new features. Can you give us an overview and tell us how those are being driven into the JBoss product portfolio?
Mark: So the Drools team, lead by Mark Proctor, has been doing some very cool work in rules over the last few years. This has sort of culminated in Drools 5.0, which obviously includes the core rules engine but they've also added support for CEP, a complex event processing implementation. They've added some support for lightweight workflow systems.
And probably the most immediately interesting one from a customer perspective is the Business Rules Management system. This is what we are driving into our next platform release, the DLMS, which we're announcing imminently. It has been in the community. It's a repository for storing your business rules and managing them and tagging them. We've had a lot of positive feedback from early adopters on this, as well as from the community. So we have high hopes for this, and it should be the next big thing in our platform release.
DZone: Revisiting an old debate from a few years ago, is the REST versus WS-* debate truly over in your opinion? Given what we've seen over the last couple of years with the new APIs coming around RESTful architectures, would you say that REST has officially won that debate?
Mark: No, it's definitely not over in some areas. There are some people that will continue to debate REST versus WS-* in the same way that other people will continue to debate Apple versus Windows. It's the right tool for the right job. I think REST is very good in certain areas, and I think at the end of the day the web is based on RESTful principles. We know it works, we know it scales, we know its fault tolerant. So there's a really good use case there for why we should use REST.
But Web Services do bring benefits as well. Interoperability, development interoperability, wide industry adoption. So there are things that Web Services bring today that REST simply does not have. And it's not that REST cannot provide them, it's simply that the industry has not as yet got behind REST to define things like transactions and complex security protocols and management. All of these things are what you find in the WS-* architecture.
So I think in terms of REST versus WS-*, we should have as industry actually get over that and start to use REST where it makes sense and use WS-* where it makes sense, educate each other in terms of where you should maybe be using REST when you're currently using WS-*, and vice-versa.
But stop having these little arguments. They really don't progress us too much forward these days. They did over the last few years, they highlighted that maybe REST was overlooked too much by certain areas of the industry. I think we've pretty much raised REST in terms of what people know about it. Now let’s start to use it and start maybe to drive these additional standards into REST.
DZone: There have been some interesting projects that have come to light recently. Folks like Bill Burke have been working on RESTEasy project and there's the JBoss Cloud project that Bob McWhirter has been leading. What is JBoss's vision for how SOA applications will be built moving forward. Are technologies like REST and cloud computing going to be important driving forces behind how JBoss ultimately productizes its SOA offerings?
Mark: Yeah. Certainly REST in terms of SOA is a very valid architectural principal. In general, we've been talking about supporting REST in our SOA platform for a long time. The work that Bill's been doing on the RESTEasy project makes that a lot easier. Obviously it's standards compliant, which is very important to us for everything we do. So we definitely see REST being pushed further and further into our SOA platform. As I mentioned on the REST and WS-* debate, I don't think it would be to the exclusion of other approaches -- SOA is technology agnostic. You can do a good SOA implementation based on CORBA or email, that doesn't have to be on REST or HTTP. As long as you can maintain the flexibility of allowing people to use the model that speaks best to the underlying implementation, that's the best case for it.
And cloud, the work that Bob's been doing, again that does feed into SOA. This being across the industry, not just with us, that SOA platforms, SOA suites, whatever you want to call them, are increasingly being used as the basis for developing applications that are then pushed into the cloud because SOA is about loose coupling, it's about hiding implementations and in some areas, its also about hiding where services are, whether it's composite services or individual services. And the cloud kind of subsumes some of this. So if a service is deployed on the cloud, a SOA platform should be able to hide that but also needs to be able to accommodate that.
So a lot of what's been happening in projects - RESTEasy, JBoss cloud, the Infinispan work - I would see those definitely being big driving forces for where SOA is going from a Red Hat perspective in the future.
DZone: At one point it seemed that JBoss was trying to build everything it needed within its own ecosystem. That seems to be changing though.
Mark: Yes, for a number of reasons. Probably the most public one is that we're only a limited-size company and the things that we could do and that our customers want us to do, we simply can't do them all in-house. But also, there are very good implementations of other software components that are out there that are not JBoss components. It makes a lot of sense, again from an open source perspective, for us to collaborate and cooperate with those ecosystems, wherever they are. For instance, as I mentioned earlier, we're now using the Apache CXF project as our Web Services stack. We still maintain our own Web Services stack at the moment, but the aim is that CXF will become the default Web Services stack at some point in the future.
We're also working with the Apache Qpid community now with the JBoss Messaging team. AMQP is a standard in the works that will hopefully become a standard. That has several implementations, one of which is called Qpid in Apache.
We've had groups in Red Hat working on AMQP-based messaging solutions in C++ and Java. We're now working with those within Red Hat and within the Apache community to drive our technology from JBoss Messaging into Apache Qpid, to include that and give the benefits back to the community as well.
So in general, we're definitely opening up and trying to cooperate and collaborate a lot more with different communities, and not trying to develop things in-house so much.
DZone: Now, Mark, you yourself have been making some noise in the area of SOA governance, in particular around process governance and testable architectures. Can you give us a flavor of what that's all about and where you think it'll be going in the coming months and years?
Mark: Yeah. Process governance or testable architectures, it actually dates back a number of years to a standards discussion that was going on in W3C around the Web Services Choreography Description Language. This is an effort that was supported by a number of major vendors at the time, Oracle included, all to define a Choreography Description Language which was based around something called pi calculus. This allows you to define your services which are active in a choreography. Precisely define the roles and relationships, their interaction patterns, and to prove - in a formal methods way - whether they will work correctly in a deployed environment.
Now, as its name may imply, the Web Services Choreography Description Language was originally intended for Web Services. But like many of the Web Services standards that are out there, it actually can be used quite easily outside of the context of SOAP and HTTP.
So what we within JBoss have been doing for the past couple of years is working with some partners in the community to take this WS-CDL, as it's known, and apply it to general SOA. We have been working with our JBoss ESB project to allow services as defined in the ESB to be defined within WS-CDL, and then you can test them, you can simulate them, and you can prove - before you've even deployed anything - whether the services have the right interfaces or whether they have the right roles and relationships or whether the will exchange messages correctly.
And then you can deploy them into the wild, if you like, and monitor them in runtime, to continue to ensure that they behave according to the way that you originally intended.
This has actually gotten a lot of feedback from the community as well as from analysts and other partners, who find it's quite interesting, because one of the problems with - it's distributed systems, not just those based on SOA principles - is proving that they work before you actually put them out there into the real world. It's still more of an art than a science.
What testable architectures does is try to put the emphasis back onto the science and away from the art. So we're quite excited about the work that we're doing. We think it's an obvious differentiator for what we're doing in JBoss in the SOA space. We're going to be pushing forward, as I said this is being done primarily in the community for the last year and a half. The next phase of this is to do a tech preview for our platform and we’ll see where we go from there.
DZone: Mark, switching gears a bit, JavaOne is approaching very quickly. Can you give a sense of some of the key areas of focus for JBoss at the show this year? And for those that are attending, are there any particular sessions that you'd recommend?
Mark: At JavaOne this year, we'll have a booth, as we always have. We'll be having quite a lot of sessions presented by some of the key project leads who are attending JavaOne . We've got a few sessions within JavaOne ourselves. They include a focus on work we've been doing around REST and transactions, some work that the Drools guys have been doing with some fairly important customers. There's actually quite a lot within JavaOne as whole that is JBoss-specific. I won't recommend one over the other; I think they're all very, very good. If anybody needs to attend any JavaOne sessions, particularly the JBoss ones, you'll get good value for money.
If you are around, I definitely recommend you come to the JBoss booth, because we will have a mini-theater where we will be presenting things on all aspects of JBoss. We've got many sessions on our new micro-container architecture. We'll be talking about OSGI, we'll be talking about ESB, our SOA strategy. We'll have talks from the Drools guys on the BRMS and JBoss Drools 5.0.
It's also worth mentioning about the JBoss Drools team having a bootcamp, which is going on currently with JavaOne . I think it's probably over-subscribed at this stage. But if you check out the JBoss Drools website, you never know, you may just get in if somebody cancels.
DZone: Can you provide us with a sneak preview of what the JBoss Premier is going to be about this year at the show?
Mark: Obviously I can't say too much. I can probably hint. We've already talked about the next generation of our EAP products, EAP 5. So we may be doing something around that. There's also the BRMS release, so we'll talking about that. And there will be a very strong message in the area of standards and openness.
DZone: JavaOne this year is coming right on the heels of the recent announcement of Oracle acquiring Sun. I wanted to get your perspective on whether this in any way affects Red Hat/JBoss’s position towards the Java platform.
Mark: I think it's obviously a very important announcement. It has the potential to change the whole landscape, not just for us, for lots of companies, big and small. We're at a stage where we really don't know what we don't know. Oracle and Sun continue to act as independent companies. They have to, at this point. The acquisition hasn't completed. We just have to see what Oracles does going forward. Certainly in the past when we've been working with them in the JCP project, they've made some statements about how they want Java and the JCP to be much more open and led in a more community-driven manner. So hopefully, they'll continue with that line of thinking. We'll just have to wait and see.
DZone: Can you describe some of your major goals in the coming years from two perspectives: from the perspective of the JBoss community as well as JBoss, the business.
Mark: I probably could summarize both in one sentence: Global. I think it's really important that we grow the community. The JBoss community is big and thriving. I would like the see the JBoss open source community continue to grow, continue to be a place where people could, consider having projects that are not necessarily ever going to make it into the JBoss or Red Hat products, but somewhere that, basically, as a good place to drive an open source project. When you're creating an open source project, currently you are probably thinking about Apache, CodeHaus, and SourceForge it would be nice if you thought about JBoss in that way as well. And we have had a few groups come to us and suggest that over the last year or so. My goal is to make that much broader.
From a business perspective, we want to grow into other areas, other non-English-speaking areas of the world. As I mentioned earlier, APAC, Latin America. These are all big areas for us. On our platform, they need to take into account the differences, sometime, subtle, sometimes not so subtle, that those areas will require from them. Obviously, we'll want to think about starting about internationalization.
But also, growing the community there. If we grow the community adoption, then that inevitably leads to growing the subscriptions and the business. So the two, I think, need to be tied together. I don't think that we should look at growing the business without trying to build a community, and likewise, I think growing the community should have a knock-on effect on the business, if we do it right. And that's certainly one of my main goals going forward.
I know Sacha tried to successfully do that when he took over after the Red Hat acquisition, from Marc [Fleury]. Certainly, now that the baton has been passed, I want to continue making the inroads that he had set in place, and keep the momentum going.
DZone: Mark, once again, congratulations on your new role at JBoss, and thank you very much for your time today.
Mark: Thank you very much, too.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)