Tech Chat - David Ward on JBoss Developer Studio
DZone recently interviewed JBoss Solutions Architect David Ward to talk about what's new in JBoss Developer Studio (JBDS) and the Enterprise Application Platform (EAP). Ward distinguishes EAP from the various projects found on jboss.org and describes JBoss' flexible deployment and configuration model. He looks at how JBDS tooling works together with Seam and Hibernate, describes the improvements in the jBPM Visual Designer and highlights new features in the JSF editor, including RichFaces components. He concludes by providing a roadmap for EAP and a vision for where he thinks developer tooling is headed in the next five years.
The complete transcript of the interview has been provided below.
Nitin Bharti: We're sitting today with David Ward, solutions architect within the JBoss division of Red Hat. David has over 12 years experience designing and developing enterprise systems across various fields, and is a long time JBoss evangelist. Welcome, David.
David Ward: Welcome.
Nitin: Can you tell us a little bit about the work you're currently doing at Red Hat?
David: Sure. As a JBoss solutions architect, my job is to work with customers on a technical level, talk about various pain points they have, or the goals that they have, both from a business and a technical standpoint, and to try to help them apply various technologies from our middleware suite to what they're trying to accomplish.
Nitin: Why would someone choose to become a subscriber to the enterprise platform, versus just downloading the JBoss.org bits, and using them for free?
David: When most people think about JBoss, they think about the application server. They think, "Where am I going to get it?", so they think jboss.org. What a lot of people don't recognize, is that jboss.org is a collection of over 40 different projects, and when customers go there they get somewhat confused about what they should pull down; what versions, and how do they know that they're going to work well together?
When you go to jboss.org, you need to know the right versions of the right software to pull down. With the JBoss Enterprise Platform, we do the work for you of picking and choosing the right version of the right technology, and pre-bundling them for you. In addition to the vertical tests that each of the projects have had, we also introduce horizontal, breadth-wide testing across the various projects.
This can include, not just from an API conformance level, but also from a performance testing, tuning level. We do certification testing on different operating systems, JVMs, different databases. Our patch process goes through this recertification, so we actually provide a stable platform for you to deploy your applications on, rather than the early release, often bleeding edge-type stuff that you'll find at jboss.org.
Nitin: Last summer, Red Hat announced the first release of the JBoss Enterprise Application Platform, which was based on version 4.2 of the JBoss app server. Could you reiterate what was included in this release?
David: Sure. The Enterprise Application Platform 4.2 has three major components in it. One, of course, being the application server 4.2. One being JBoss Hibernate, which is the leading ORM persistence engine out there. And the third thing being JBoss Seam, which is an enterprise Java application framework. These three main components form the basis of the application platform.
Previous to the platforms, people would actually have to get different subscriptions to support different components. So, a different subscription for the app server, versus clustering even, versus Hibernate. With the app platform a single subscription gives you support for everything that's contained in it.
More recently we've had our 4.3 release of the application platform, which made major changes in two fashions. One is an updated web services stack, one that fully supports JAX-WS. And also, the replacement of JBoss MQ with JBoss Messaging. JBoss Messaging supports fully distributed queues and topics, and HA failover. It also has significant performance gains over the old JBoss MQ engine.
Nitin: Some people assert that Tomcat and Jetty are becoming increasingly popular. The full-stack application servers like JBoss, less so. Would you agree with this statement?
David: Well, I definitely have seen an increase of popularity across servlet containers, and Tomcat in particular. However, I have seen nothing but growth also in the full-stack, like JBoss Enterprise Application Servers.
When you look at the customer base that we have, they've got certain concerns that just a standalone servlet container is not going to provide to them. So, things like a mature transaction management service, a performant persistence engine, things like that are of great concern to our customers. High availability, failover and clustering, you're not going to get that in a standalone servlet container, and it's something that JBoss can provide.
You might not need EJB, or JMS. One of the strong points of JBoss has always been the deployable nature of the services. So just like we can hot deploy applications, we can also hot deploy services. And undeploy. So you can actually pick and choose just the services that you need, and just deploy those in a custom way, a custom configuration in JBoss. So you have that lean, mean fighting machine minimal deployment, which is something that has always been a good thing about JBoss.
Nitin: How do you manage configuration of your services?
David: Configuration of services today in JBoss 4.2 services is done using JMX services. So, generally, what you'll find is either a service archive or an XML file which describes that service. And you can localize in on that point and just configure that piece, simply removing that XML file or that service archive will undeploy it from the system, so most developers are very comfortable with this scenario.
When you start talking about production configuration and management, and monitoring, and that sort of thing, we do have our JBoss operations network, which is more administrations operations team tooling. So you can do remote configuration and deployment across multiple JBoss nodes.
Nitin: What are some of the useful features in the JBoss Operations Network (JON)?
David: The current version of the operations network is 1.4. It has several useful features regarding auto-discovery of JBoss instances that are out there, deployment of applications, configuration changes, monitoring, and so forth. Many customers use it today, and it's part of a certain bundle offering that you can get with JBoss.
When you start talking about JBoss 2.0, which is actually right around the corner (Editor's Note: JON 2.0 is now GA), we basically went back and redid a lot of the code, and freshened it up. Much more configurability across more components than we supported in 1.4. We have a new plug-in architecture with our agents. JON uses a server agent-type delegate mechanism, so that you can easily extend the capabilities of the administration tooling.
Nitin: Developers have a wide variety of choices when it comes to Eclipse-based IDE's. Let's talk about the editor a little bit. What would you say makes JBoss Developer Studio unique?
David: There are a few things, when you say editing. There are different types of components that you can edit. So when you talk about the presentation tier, for example, JSF editing. Out of the box it has a very advanced JSF editor, where it fully respects XHTML, facelets, includes, and Cascading Style Sheets.
You can toggle back and forth between a code-view and using Mozilla Rendering Engine internally, so a visual view, and a split pane view to go back and forth. We have a palette of JSF components you can drag and drop in there to make it very easy. When you talk about presentation tier editing, there's a lot of that stuff out of the box.
From a persistence-type editing , we do have, as part of our hibernate tooling piece of Developer Studio, HQL, which is a hibernate query language editor, as well as JPAQL, where it does contextual assists. So over dot notation, over your relationships, it will actually suggest to you different relationships and properties that you can work with in your query.
It also facilitates a mapping diagram, so you can actually see the relationships between your JPA entities and your persistent tables. You can go ahead and actually see the SQL that Hibernate is going to run for you under the hood so you can actually go back and forth there. So you know you have got a good working query before you put it into your application.
When we are talking about tooling, regarding Seam, Seam brings the whole story together. We've got various wizards that make it easier for you to create new forms and new actions and wire together your presentation with your business logic and your persistence.
Nitin: What are some of the major attractions of Seam that make it stand out from other application frameworks?
David: So, Seam has a lot in it. The thing that I think differentiates it the most is that it doesn't force upon the developer a single methodology or way of doing things. When you look at some of the other more popular Web frameworks out there, they all either have verbose XML that you have to configure which can be tedious and error prone. You have to extend certain classes or implement certain interfaces.
And Seam is very different because it is more of an enabler than an enforcer. Simply by using annotations, you can actually mark a plain old Java object or a Stateful or Stateless Session bean or messenger bean as a Seam component and then you can use that component using a simple expression language across different areas of your application. People might think, "Well, you're still using a proprietary API." Well, the truth is that it is actually the foundation for the WebBeans specification. So Java WebBeans is a new JSR that is out there. So similar to the stories we've had before as far as Hibernate drove the JPA standard, Seam is now driving the WebBeans standard.
So as far as other things that make Seam unique, it does have a very powerful bi-jection engine. Most people are familiar with IOC containers done at injection of services. Seam can do that as well as out-jection. It can actually take changes or components that you modify in one context or scope and actually push those out to other contexts or scopes. You have that bidirectional injection, if you will.
The last thing I think I would want to note is Seam's ability to auto-manage those different contexts or scopes. So most people are familiar with a request scope, or a session scope, or a global application scope to their applications. Seam actually introduces two other scopes. One is a business process scope so that Seam can share contextual data between multiple actors within a business process very easily and it also has what's known as a conversation scope.
So think of it like you are buying something online. You are going through this pipeline of billing details, shipping details, things like that. That's a conversation. Seam can actually support multiple paths or multiple conversations at the one time without clobbering or stepping on each other's toes. Across all these contexts that I talk about, Seam does the automatic cleanup after itself. So you don't have to remember as a developer to remove something from an HTTP session which is a classic way of a memory leak.
Nitin: Can you talk a little bit about how Seam tooling works with other JDBS tooling?
David: Sure, and I will use a real example for this. Seamgen is something that we had for a while which allows you to interactively, via the command line or via Ant, if you wanted to create new actions in Seam, or forms, or even point it at an existing database and create a fully working CRUD based application. In the Developer's Studio, these things are exposed via drop down menus, for example, where you can go ahead and say: create a new Seam web project. Point an existing schema and generate this CRUD app.
The Seam tooling in that regard actually leverages the Hibernate tooling to create the persistence tier. All the JPA entities delegate that work to Hibernate tooling to do that. It leverages the Hibernate Validator project to put on those entities certain restrictions based on that information from the database, like a max length on a field, or not null, or something like that. That's on the persistence side. Seam will then go ahead and go the rest of the route by creating your presentation tier, all the HMTL pages that are required, not just to query the database, but to elicit out, edit it, modify the associations and also take those same restrictions that the database is enforcing and the JPA layer are enforcing but also put that up to your presentation tier. So a required field, for example, is enforced and max length and that sort of thing.
Nitin: What type of support does JBDS provide for Spring development?
David: The Developer's Studio includes the Spring IDE. People who are familiar with that can go ahead and use that comfortably within the Developer Studio. I should note there's a couple of other ways that JBoss Seam in particular supports Spring. First of all, the application server had for some time the Spring deployer, where you can take the a .spring archive which is a normal jar archive with a Spring extension, have your bean factory configuration there like an application context in all of your class files, hot deploy that in JBoss and that is made available via JNDI to other applications.
The other is support directly from Seam. You can actually, by adding XML to your Spring XML, go ahead and expose out Spring beans as Seam components. You can also go the other way, as well. So with JBoss, we try not to suggest that people do a full rip and replace. Spring is a very popular technology so we do our best to allow you to integrate and make more gradual transitions where it makes sense.
Nitin: Can you talk a little bit about jBPM Visual Designer and how that works?
David: Sure. So, first a little background on jBPM. jBPM is our Java business process management workflow engine. It’s different from most other BPM tools out there, because it is a very lightweight embeddable library. It doesn't have any dependencies upon our application server. You can use it stand alone. The only thing it requires is Hibernate on the back end to store its contextual data.
Now when we are talking about integration with the Developer Studio we are talking about the jBPM Visual Designer. The Visual Designer gives you drag and drop functionality and a palette of components that you can use to define your workflows. So, things like human task nodes or non human actions, transitions, splits, joins, what have you. All these things you can go ahead and drag and drop and draw the lines to connect them on the screen.
You can also toggle from that view to a source view of the jPDL XML and the tooling keeps those things in sync. The other thing that the jBPM Process Designer does is it allows you to automatically create process archives, which basically takes your workflow definition and the classes and other artifacts that are required, puts those in a process archive and you can remote deploy them to your running application.
Nitin: How can jBPM and Seam be used together?
David: This can be done in a few different ways. First of all, under the hood, Seam leverages jBPM as a library for what is known as pageflow, which allows you a much more elegant way of defining your transitions to page to page, versus the more verbose and hard to maintain JSF navigation rules. So that's how Seam uses jBPM out of the box. Seam also has greater support for jBPM when it comes to that process context which I touched on earlier. When we are talking about multiple human actors that are collaborating or working on a workflow together, there's certain contextual data that needs to be made available throughout that process, and Seam has specific support for that process scope in doing so.
Nitin: Switching gears a bit, can you talk a little bit about the testing support provided by JBDS?
David: Sure. One example here would be when you are creating a new Seam project, there's wizards for that as well: "Create new Seam web project," for example.
It also will create, when you do that, a peer project. So, say you called the project "My Project." It will create a "myproject-test." And the nice thing about this is that every time you use the tooling to create a new business action--so, a Seam action--it'll automatically create a new test class for you in that peer test project, and it'll do it as a TestNG test case.
When you go over to that test case and you run it, what'll happen is it goes ahead and it bootstraps up the embeddable JBoss EJB container. So you actually have a production-like environment for your test case to run in without actually having to start up the full-blown application server. In addition to that, of course, you can just do straight-up TestNG or JUnit, if you want to.
Nitin: What are the preferred tools for deployment within JBDS?
David: When we're talking about deployment from JBDS, we're talking about deploying into, normally, the Enterprise Application Platform, even though, of course, you can create standards-based applications and deploy them in other containers if you want. But looking at the Application Platform, it of course has always supported hot-deploy, redeploy, un-deploy of applications as well as services.
The value-add here that you see with the Developer Studio is with incremental deploys. So you can actually make a small change to an XHTML page, for example, or a class file, and simply just redeploy that delta into the running Application Platform instance, hit reload in your web browser, and you can go ahead and test out your change. Obviously, this greatly reduces the overall length of the development test, change, tweak, redeploy, test again cycle.
Nitin: What types of tools do you provide for version control and team collaboration?
David: Out of the box in the Developer Studio, we do have basic team collaboration and synchronization, with CVS. However, being that it is Eclipse 3.3 under the hood, you can go ahead and, for Subversion support, use the Subclipse project and pull that in, or any other Eclipse-compatible team collaboration plug-in.
Nitin: You talked a little bit about Seam and how it provides an integration point between the persistence tier, the business tier, and the presentation tier. Jumping into the presentation tier a bit, could you shed some light on what Ajax for JSF and JBoss RichFaces provide and how developers can use these for building Web 2.0 applications?
David: Ajax for JSF and RichFaces were originally donations from our partnership with Exadel, as well as the Developer Studio itself. We got a kick-start from them. The Ajax for JSF library basically brings that Ajax behavior to standard JSF components.
The example here would be, say you had an input text field and you needed to do some validation. In your server-side code, your JSF code, you can decorate that component with Ajax for JSF support, and you can wire in, let's make it on the on-blur on that field, make a trip to the server, run your Java-based validation logic. The response goes back to the client, and then you can decorate that user interface field with a warning that you needed it to be a number, no letters allowed, or something like that.
RichFaces leverages that technology and also provides a very large palette of JSF components, above and beyond what you would find in the standard toolkit. So things like a date picker, input number, sliders and spinners, collapsible trees, collapsible panels. Think of it as a rich palette to work with.
And while I'm on the thought of a palette, inside the Developer Studio, you actually have various Seam components, Ajax for JSF and rich component palette, right within the JSF editor, that you can drag and drop onto the page and use.
Nitin: What can we expect to see in the next version of JBDS?
David: So we're actually coming up on a 1.1 release pretty soon here, and the major piece of that is updating it to the latest Enterprise Application Platform, 4.3. The current 1.0 version of the Developer Studio deploys with App Platform 4.2. So, making sure that people are developing with the right version of the platform, the same version of the platform they're going to production with, is obviously very important.
There's also various bug-fixes that are in there, as well as improvements to lower memory and performance of the JSF editor, smaller things like being able to export out your mapping diagram in Hibernate to GIFs, improvements in the visual designer in jBPM, and so on.
When we're looking more towards the future of the Developer Studio, it'd be looking at inclusion of the Rules plug-in and support for other platforms.
Nitin: What can users expect to see in JBoss Application Server 5, in terms of new features and functionality?
David: The biggest thing on most people's minds is JEE5 certification. The current App Platform, 4.3, is a J2EE 1.4 certified application server. But most of what is in EE5 we actually already support now in 4.3. So, things like EJB 3, Java Persistence API, latest and greatest Servlet specifications. People can use those today, but full EE5 certification is obviously very important in App Server 5.
From an architectural standpoint, the Application Server today is comprised of pluggable services via Java Management Extensions. And that's that hot-deploy stuff that we were talking about, of services as well as applications.
This is being replaced in App Server five with what's known as the JBoss Microcontainer, which is an IOC container on steroids, if you will: a very flexible deployment mechanism, class-loading component technology, allowing you to very easily define relationships and dependencies across services--JMX, of course, still supported. That's really the main focus of App Server 5.
Nitin: In the coming years, where are some of the areas you'd like to see improvements in JBoss, overall?
David: I think continuing down the path we are right now, as far as beefing up our tooling, both on the developer side and the operational side, are things that I'd like to see to move forward.
Right now, the JBoss Developer Studio is mostly focused on our flagship Enterprise App platform. But support for management and configuration of our SOA platforms, particularly around our ESB technology, is something that I think is very important and stuff that I know is being worked on. Providing wizards for creating Portlets for our Portal platform is important. So I think we're progressing down that way, and I'd like to see that continue.
On the operational side of the tooling, much like we're continuing down on the developer side, I would like to see continued support for other platforms in our operations network. With our revamp of the underlying architecture of the JBoss Operations Network 2.0, it's going to make this possible.
One of the things that I didn't touch on with the App Server five is a new Profiler Service, which makes configuration and remote configuration much easier. We're going to see that as a cornerstone and being leveraged by the management tooling.
Nitin: Overall, how do you see the face of tooling changing in the next five years?
David: I think we're talking about bridging the gap between the role of the developers as well as the roles of business analysts and designers. So, right now, the developer tooling is just that: it's tooling for developers, right? Making their work easier.
Now, there are certain aspects of the Developer Studio, like the JSF editor, that make that visual component easier, but you're not going to expect to see an Eclipse-based framework on a designer's desktop. So somehow allowing them to collaborate better would be a good thing.
We are making strides in this way, specifically around integrating with business analysts. So, for example, if you look at our JBoss Rules technology, we have a business rules management system, which is a very Web 2.0 style, browser-based interface, which allows them to design their rules--there's wizards there--version their rules, push them out to production. And this is tooling for business people. So we're making strides in this way, and I would like to see the desktop technology to support this move in that direction as well.
Nitin: Thank you, David.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)