Interview with Mark Hapner

 Distinguished Engineer, J2EE architect, Sun Microsystems, Inc.

Topic:Whats new in J2EE 1.4 Date: May 2003

Mark Hapner is the specification lead for J2EE 1.4 and is also Sun's representative to the Web Services Interoperability Organization. In short, he is one of the key individuals at Sun driving J2EE's technical direction. Mark joined Sun's Java Software Division in 1996 to participate in the development of the JDBC API. Following that, he co-authored the Enterprise JavaBeans specification and authored the Java Message Service specification. In this Hard Core Tech Talk, Floyd Marinescu of TheServerSide.com interviews Mark about whats new in J2EE 1.4, technical issues surrounding the platform, and future directions.

Floyd: What are some key new features of J2EE 1.4?

Mark: Highlights are rich Web services support integrated with Servlets and EJBs, an enhanced version of the Connector architecture that provides sophisticated bidirectional integration with external systems; standard J2EE Management and Deployment functionality; Java Server Pages fragments and standard expression language; and, a new standard for extending J2EE containers with a pluggable authorization facility.

Floyd: It looks like there are a lot of additions to J2EE 1.4, will there be a steep learning curve for developers? Will vendors come out with 1.4 compliant servers quickly?

Mark: The short answer to the first part of your question is no. And here's why. The primary 1.4 technology that impacts developers is Web services. Developers are already gaining experience with this using the Java Web services Developer Pack and with J2EE products that included initial support for Web services. I expect developers to quickly pick up on 1.4's Web service support since it leverages their existing knowledge of Servlets and EJBs.

A majority of 1.4's functionality - Connectors, Deployment, Management, Authorization - provide a more seamless integration of J2EE containers in an enterprise's computing environment. Developers indirectly benefit from this better integration but it does not complicate their world with a raft of new APIs to learn.

Re the second part of your question, I can't speak for J2EE vendors plans for 1.4 products; however, given the customer demand for Web service standards, I expect that vendors will be competing vigorously to deliver 1.4 products.

Floyd: You mentioned that the Connector Architecture is now 2-way. Can you tell us more about that?

Mark: The Connector that is part of J2EE 1.3 allows an external system to become a J2EE resource that can be called by J2EE components. This has been enhanced in 1.4 to support external systems that asynchronously deliver events, notifications and other forms of messages directly from the external system to a Message Driven Bean component.

One part of this enhanced Connector is a work management facility supplied by all J2EE 1.4 containers that minimizes the work needed to implement an asynchronous Connector and insures its workload is properly managed by the container.

Floyd: EJB 2.1 Message Driven Beans coupled with a Resource Adapter could open up a whole new category of EAI functionality. Can you comment on what new use cases and functionality are open to J2EE developers as a result of this combination?

Mark: EJB 2.1 MDBs together with the Connector provide a standard way to integrate a broad range of external event handling, notification processing and general message server facilities into J2EE applications. Applications just see all these as sources of different message objects. This allows developers to apply the MDB model they are already familiar with for JMS message processing to an open-ended set of external message sources. These could be notifications from ERP systems, special forms of email connectors, etc.

Floyd: How would a developer decide between an EJB or a servlet to implement a WS?

Mark: Since both servlets and EJBs support the full capabilities of JAX-RPC for implementing Web services, a developer would select between them based on their basic component approaches. Those that desire a more formal business component with declarative transaction support and method level authorization would select EJBs. Those that like a less formal, HTTP request handler style would use Servlets. In 1.4, both make it easy to implement a Web service.

Floyd: Adding Web services over servlets essentially adds remoteability to servlet code. Some have said that this could reduce the EJB value proposition. What is your take on this?

Mark: EJBs' primary value is its support for a more formal business component for partitioning business logic; Container Managed Persistence that simplifies the development of persistent domain models; and, its support for messaging driven services via MDBs. In addition, EJB will continue to provide support for RMI-IIOP distributed programming for those apps that need the more closely coupled model it supports. You could look at this the other way around, EJB is now directly supporting what used to require a servlet.

Floyd: When writing servlet/EJB Web services, do you need to code WS semantics into your code?

Mark: J2EE and JAX-RPC allow developers to use the full functionality of Web services. They do this in a way that is natural for Java and J2EE developers and that hides the complexity of WSDL, Soap, XML, UDDI, etc.

J2EE 1.4 also gives developers full control over the Java/WS mapping if they desire. Most developers don't need this level of control; however, it comes in handy when maintaining existing J2EE Web services as they evolve to cope with changing internal and external requirements.

J2EE 1.4 also provides support for developing clients that dynamically integrate with new Web services via the JAX-RPC Dynamic Invocation Interface (DII).

Floyd: What use cases would require the use of the JAX-RPC Dynamic Invocation Interface (DII)?

Mark: One use case would be a specialized app that generically exercises a port, possibly to check its availability or performance. Most J2EE apps will be written to a specific WSDL port type so only more specialized apps will use this feature. It's just good to know it's there if it's needed.

Floyd: Do the new Web services features make the J2EE platform up-to-date with .NET's Web services support?

Mark: Floyd, many J2EE vendors have been shipping production support for Web services for over a year. The JAX-RPC technology has been a Java Standard since June of last year. So, the Java Community is not having a problem 'keeping up' with Microsoft. J2EE 1.4 is the first release of J2EE since JAX-RPC has been available so it is the community's first opportunity to make it a required part of J2EE; however, J2EE developers are deploying Web services now with J2EE 1.3 and JAX-RPC.

Both J2EE and .Net are focused on the same application space - Web site and Web service applications. Each is delivering support for the evolving set of standards that allow these applications to interoperate. The standards themselves are no longer a point of competition. J2EE 1.4 delivers comprehensive support for Soap 1.1 and WSDL 1.1 and has tightly integrated them with the existing servlet and EJB component models. J2EE will continue to focus on complete, interoperable support for Web standards. The Java/ J2EE community has and is making a major contribution to these standards and views them as central to the future of application development.

The primary difference between J2EE 1.4 and .Net is that the Web sites and Web services implemented with .Net only run on Windows while the Java/J2EE community has created a fully open/portable application stack. This includes competition at the JVM level; competition at the application server level; competition at the tools level; and most importantly, delivers full machine architecture and OS independence. MS could have done the same if they had really wanted to compete with Java/J2EE. Instead they have taken a path with .Net that has locked its developers into Windows and prevented their huge investment in training and tools from being used on other platforms.

The world of the Web is bigger than Windows. Whether it is J2EE, PHP, Perl or other open approaches to developing Web applications, developers are demanding technologies that give them the freedom to apply their knowledge broadly across computing environments. If MS had not embraced Web services and a VM-based stack they would have lost their developers. Now that .Net has begun to deliver this functionality they are hoping that developers won't notice that this is yet another proprietary MS stack with a veneer of Web service interoperability.

Floyd: How does J2EE 1.4's recent decision to require support for the WS-I Basic Profile 1.0 affect developers?

Mark: First, this is a major commitment by the J2EE vendor community to deliver support for WS-I BP 1.0. This is proof that the J2EE community takes Web service interoperability very seriously.

To J2EE developers, this means that, by default, the J2EE 1.4 Web service clients and Web service endpoints they build will conform to BP 1.0. This should take the guess work out of actually getting Web services to talk to each other. Currently, developers who attempt to design more sophisticated Web services based on XML Schema are taking a risk because support and interoperability for this is spotty. Since BP 1.0 includes strong support for XML Schema, developers can be more confident that these more complex services will work and interoperate.

J2EE 1.4 also contains Web service support for functionality that is outside BP 1.0, such as the Soap Encoding binding. These non BP 1.0 compliant features will still be supported; however, the J2EE 1.4 defaults will be changed to align with BP 1.0.

The J2EE Community clearly felt that it was worth a few months wait to include this extra measure of interoperability in 1.4. Sun expects to have the final version of the J2EE 1.4 platform available this summer with J2EE 1.4 products coming soon after.

Floyd: When is it appropriate to use traditional J2EE facilities (JCA, JMS, RMI-IIOP) for integration between systems, as opposed to Web services?

Mark: Each form of integration has its strong points so it is difficult to describe in a few sentences when to use each. Broadly, Web services should be used when maximum interoperability is desired; J2EE Connectors (JCA is the Java Crytography API) should be used when closely coupled integration with an external system is needed; RMI-IIOP should be used when a rich object oriented distributed object model is needed; and JMS should be used when a reliable, store-and-forward, publish/subscribe messaging system is needed to integrate asynchronous services.

I expect that many applications will use combinations of these integration technologies. For instance, many Web services will be implemented as J2EE applications that are business logic tiers that use a Connector to access an existing ERP, CRM, etc. system.

Floyd: What plans does Sun have to integrate J2EE security and transaction with Web services?

Mark: For true interoperability, both security and transactions require full specification of descriptions that augment WSDL so that developers can express in an interoperable way what security and transaction functionality is needed to access a Web service. Once this model is in place, J2EE will support it. The goal is definitely to have the J2EE container do as much of this work for the developer/deployer as possible.

In the short term, J2EE vendors will likely provide vendor specific 'helper' APIs that allow developers to insert security and transaction headers into Soap messages and to support their use on the server side.

Floyd: The new JSP 2.0 spec now had three ways to implement custom tags. Can you describe these and explain in what scenario each option is most appropriate?

Mark: The full JSP tag extension facility is very powerful but is also fairly complicated. You need to have a fairly deep understanding of its facilities to implement a tag. A new Simple Tag Extension facility is provided in JSP 2.0 that supports a simpler subset of tag extension and provides a way to implement these with both Java classes and directly with JSP itself. This allows both JSP page developers and more casual Java developers to tap into the power of custom tags.

There is quite a bit of overlap between these two forms of tag extension facilities. The short answer to which a developer should use and when is that most tags that don't have bodies containing scriptlets should be implemented with simple tag extentions. Whether a simple tag should be implemented with Java or JSP depends on the developer's skills and the complexity of the tag's function.

Floyd: You mentioned the new "fragments" in JSP 2.0. How does this differ from doing a <jsp:include>?

Mark: Currently, Java developers can extend JSP with custom tag libraries while JSP developers were limited to using jsp:include to replicate some common lines of JSP. In 1.4, JSP fragments allow JSP developers to write their own JSP tags in JSP.

Floyd: I thought tag files allow JSP developers to write tags in JSP, not fragments. What exactly is a fragment?

Mark:Fragments allow a JSP developer to create a parameterized set of JSP actions and invoke these using a parameter list. Includes could only be reused for a fixed set of JSP actions.

Floyd: What effect do you see the deployment and management API's having on the tools market?

Mark: The deployment API makes it easier to integrate IDE tools with J2EE containers so it will generally help a broader range of tools and containers provide a better IDE experience for developers. It will also help reduce the work current tools vendors put into basic container integration so they can free up a bit of resources for more advanced J2EE support.

The Management API standardizes the way management consoles interact with J2EE containers. This minimizes the work needed to make a management console J2EE container-aware. This, in turn, minimizes the impact of adding a J2EE container to an existing computing environment because the environment already knows how to manage it.

Floyd: What are some of the things that developers will be able to do in managing a server?

Mark: Actually the question should be slightly different since developers don't manage app servers - operations staff manage app servers via management consoles. The J2EE 1.4 Management standard provides a CIM model of Managed Objects that describes the server itself and the J2EE apps that are running on the server. It leverages the JMX management standard. Its primary purpose is for integrating J2EE containers with management consoles; however, J2EE apps can access a container's managed objects via a set of standard Management EJBs (MEJBs) provided by all 1.4 containers.

What operations staff will be able to do is to see what apps are running; what transactions are active, what resources are configured, etc. They do this now via app server specific consoles. The benefit of the management API is that now commercial management consoles will be able to provide an extension for J2EE app servers that leverages this standard management model so that the impact of adding a J2EE server to the mix of servers in an enterprise is reduced.

Floyd: Is Java Server Faces included in 1.4?

Mark: Java Server Faces can be used with J2EE 1.4 but is not included in 1.4 because its schedule didn't line up with 1.4's schedule. . It may become part of J2EE in the future

Floyd: Are deployment descriptors(DDs) migrated into XML schema's from dtd's? What benefits has schema given you, in the world of deployment descriptors?

Mark: The new 1.4 DDs leverage XML Schema and Namespaces to provide better support for extensibility; more complete validation; better sharing of common elements; and capture richer semantics. These are just the normal benefits you would expect when converting any DTD schema to a thoughtfully designed XML Schema.

Floyd: JDO isn't in J2EE 1.4. Where do you see that specification fitting into Sun's platform? Will is appear in 1.5 or later?

Mark: JDO is a Java technology that is independent of J2EE. There are no current plans to include it as a required part of J2EE; however, there may be J2EE vendors that provide support for it.

Floyd: Has there been any movement for J2EE 1.4 or 1.5 on adding JavaDoc-style attributes to methods (ala BEA WebLogic Workshop's .JWS file paradigm, or XDoclet), thus eliminating the need for external deployment descriptors?

Mark: The job of the JCP-developed JSR 175 - A Metadata Facility for the Java Programming Language - is to standardize a Java attributes facility. J2EE will certainly leverage Java attributes to allow much of what is in J2EE deployment descriptors to be included in the Java source for a J2EE component. Since work on JSR 175 has just recently begun, the timing of J2EE's use of its work has not been determined.

It is likely that in simple cases, use of Java attributes will replace deployment descriptors; however, for advanced cases, they likely will still be needed. It is important, for instance, that deployers be allowed to customize a J2EE app's security without having to change its source code so keeping this security information in a deployment descriptor is an important benefit.

Floyd: What are some of the current thoughts on competing with the productivity of writing ASP.NET Web services? (which even without an IDE have significantly less code and don't require separate configuration compared to the current versions of JAX-RPC or JAXM -- both of which require their own deployment descriptors for each service)

Mark: JCP-developed JSR 181 - Web services Metadata for the Java Platform - is focused on providing a higher level model for developing Web services similar to what is now provided by BEA Workshop. There are also other J2EE tools vendors who are adding enhanced Web service support. Ease of development is important and the J2EE community will meet .Net's challenge.

Floyd: When will JMS and JAXM converge?

Mark: JMS is an API for integrating with MOM systems with J2EE. It is likely that MOM vendors will enhance their facilities to carry Soap messages in addition to their existing message types. There will likely be an enhanced version of JMS that includes more explicit support for Soap messages and XML to support this.

JAXM is an API for integrating Soap message brokers with J2EE. It does nothing but SOAP and requires no functionality beyond Soap. It allows products that only support reliable store-and-forward of Soap messages to be integrated with J2EE. The fact that MOM and Soap message broker products may overlap to some degree does cause some confusion; however, it would not be practical to force Soap message broker products to implement the full set of JMS functionality just so they could integrate with J2EE.

Floyd: Will JAX-RPC be extended to be able to call asynchronous Web services? It currently only allows a J2EE client/server to invoke a synchronous RPC.

Mark: JAX-RPC will likely be extended to support calling all forms of Web services defined by Soap and WSDL. Currently, neither of these define an 'asynchronous' form of Web service. When they do, it will.

Floyd: Can JAX-RPC be used to talk to non-SOAP based Web services? If not, are there any plans to support this?

Mark: If the question is 'Will JAX-RPC define some form of JAX-RPC specific protocol or will it define an RMI-IIOP binding?' then the answer is that it could but there are no specific plans to do so. Currently, it seems the Web service community is more focused on interoperability than it is on the efficiency of the protocol.

Floyd: How closely related is the J2EE Application Verification Program to server compatibility program? Will a 1.4 version of the AVK be coming soon?

Mark: The J2EE CTS and AVK test the two 'ends' of the platform. The CTS tests the J2EE 'socket' (appserver) to insure it delivers high quality power and the AVK tests the appliance (J2EE app) to insure it will run correctly on that power. Think of the AVK as the J2EE equivalent of UL certification. The 1.4 version of the AVK should be available soon after the J2EE 1.4 platform ships.

Floyd: I've heard that the Sun ONE AppServer is now sharing part of its codebase with the J2EE RI. Will this improve Sun's time-to-market for delivering Sun ONE over its competitors?

Mark: Since the J2EE RI code is available to all J2EE licensees, it doesn't necessarily give the Sun ONE App Server an advantage over their products.

Floyd: Now that we have XA transactions, nested transactions aren't that far out? Are there plans to support nested transactions?

Mark: Support for XA nested transactions is not currently planned; however, once it is actually supported by the major transactional systems it is likely that the JTA/JTS specs will be enhanced to support it.

Floyd: When can we see a series of security API rich enough to enable universal single sign-on (user identity defines security rights in the web web, ejb, database, etc)? Why not just borrow it from Corba instead of waiting for Web services to reinvent it?

Mark: J2EE is laying the groundwork for single sign-on by providing the J2EE Authorization API in J2EE 1.4 and the newly filed JSR for Authentication - JSR 196. Together, these provide a standard way for integrating the security provided by an app server with the existing security infrastructure of an organization.

The Liberty technology is another critical piece that insures an open technology for federating network identity.

These steps plus the work of the WS-Security WG, XKMS, SAML, DSIG etc to standardize the 'plumbing' of web security are likely the industries best chance of achieving true single sign-on.

Floyd: The new J2EE 1.4 sample application from the blueprints team is the Adventure Builder, not the J2EE Petstore. Further, the AE has chosen not to use EJBs in its implementation. What are your thoughts on the new application. Does this reflect a change in Sun's stance on the applicability of EJB?

Mark: The new app is one of several apps that the Blueprints uses to teach development techniques. Not all J2EE apps use EJBs. The Blueprints need to show examples of web sites developed with and without EJBs. The Blueprints will also include apps that highlight the use of EJBs.

Floyd: I've noticed a trend in JMS 1.1 and JSP 2.0 where API's have been re-factored or new API's have been introduced to make common development tasks simpler. This sets a precedent - changing a spec to make things simpler. Given all the recent complaints about EJB complexity, what do you think about applying a similar philosophy to EJB?

Mark: The J2EE community is continuing to look at how to simplify development and improve developer productivity. EJBs support for Web services via JAX-RPC has taken some steps in this direction. It is also likely that future versions of EJB will use the Java attribute facility provided by JSR 175 to simplify both EJB code and deployment descriptors.

Floyd: Why was the requirement to support standard deployment (JSR 88) dropped? This (along with management) seemed to be a key benefit of the 1.4.

Mark: There's a bit of a misunderstanding here.

JSR-88 specifies requirements for a tool that manages the deployment process and supports plugin components that handle the app server specific aspects of the deployment process. The tool is typically provided by a tool vendor and the plugin components are typically provided by the app server vendor.

What we removed recently in 1.4 is the requirement for the app server vendor to supply a tool that meets the JSR-88 requirements. The app server vendor is still required to supply the plugin components that work in a JSR-88 deployment tool.

App server vendors already had deployment tools that were customized to work with their app server. While they saw some advantage in providing plugin components that could work in tools supplied by others, they didn't see the strong need to supply such tools themselves. They certainly didn't expect someone to use their tools to deploy to other's app servers.

The major advantages of JSR-88 seemed to be in enabling independent tool vendors to supply tools that would deploy applications to any J2EE 1.4 app server, and to allow an enterprise to develop its own in-house tools that would support deployment to the app servers used in the enterprise.

Floyd: Any final thoughts you'd like to leave us with?

Mark: The scope of J2EE 1.4 was recently expanded to include support for WS-I Basic Profile 1.0. This is not just a press release: it is a solid commitment by J2EE vendors to deliver Web service interoperability. Developer's are demanding a Web service platform that doesn't lock them into a specific hardware, OS or app server vendor; and, that fully supports Web service standards. J2EE 1.4 delivers on all counts.