Q&A: The State of Java with Jamie Thomas of IBM
Q. We feel the most successful acceptance and use of Java has been in the middleware as the Java 2 Enterprise Edition (J2EE). What advances are on the J2EE roadmap in 2004?
A. J2EE is coming into its own for corporate computing. The major J2EE application server vendors have demonstrated a sustained commitment to the J2EE specification and a general level of excellence that spans a large variety of business computing needs. The J2EE specification has matured and has become entrenched in a large enough number of computing projects to prove itself as a stable computing platform.
J2EE is powerful because it creates critical mass and inspires confidence. ISVs and customers can build applications to the J2EE specification knowing that their applications will perform well regardless of whether they are hosted on WebSphere, or WebLogic, or a number of other commercial platform products. This in turn is fueling a growing investment in literature, programming skills, development methodologies, tools, and technological innovation that further expands the economic value of the platform specification. We will see the core value of J2EE advance in two major areas this year. The first is in the deployment of Service-Oriented Architecture (SOA)-related attributes that were introduced in the J2EE 1.4 specification. This includes JAX-RPC for Web service invocation (JSR-101) and Web Service for J2EE for implementing and deploying web services in a J2EE environment (JSR-109), as well as the other supporting JSRs that these depend on. The other area of focus for 2004 is in making it even easier for developers to rapidly create business applications that benefit from the robustness and stability they can reap from the J2EE platform. All major J2EE vendors have introduced activities in their products that are intended to simplify development or automate deployment of J2EE applications. All of these activities are largely aimed at making it possible to create J2EE applications with even less knowledge of the total breadth of the J2EE programming model and specification -- lowering the barrier of entry for programmers. I expect that many of these activities will surface as part of the J2EE standard specification in the future.
Q. How has the Java developer community responded to the inclusion of the different API for Web Services in JDK 1.4?
A. The response has been mixed and largely separates those who believe that SOA is a fundamental principle in application design vs. those who believe Web services are just another distributed computing and component-isolation technology. It is important to separate the concerns of component modeling, distributed systems integration, and business composition. These concerns are distinct and drive their own set of information technology trade-offs. Component modeling attempts to address the issues of program modularity, re-use, and execution management. It should be used primarily as a device for achieving engineering and maintenance efficiency within an application design. Distributed systems integration addresses the issues of information system topology and utilization. Distributed system integration should be used to enable the efficient utilization of computing resources -- allowing the application to be divided and spread over different computing resources as needed to balance the physical limits of the computing infrastructure for a given set of computing workloads. Business composition attempts to address the issues of business structure and flexibility. It should be used to integrate the functions of different parts of the business (and the applications that support them) to correspond to the ways that the business itself is integrated. It should retain enough flexibility to support recomposition of application functions as often as the business itself is restructured, or as often as the business needs to deliver new products to its customers.
Too often in the past we've attempted to address all of these concerns with a one-technology-for-all-needs approach to computing. In fact, these concerns should be separated and dealt with as independent aspects of the application design and implementation. If you want to decompose the application into components solely for the purpose of enabling encapsulation and re-use, then you should use a local-EJB interface to that component. If you want to enable re-distribution of the component to allow for some better scalability or efficiency in the distributed system topology then you should use a remote-EJB interface for the component. If you want to compose a business service that is otherwise independent of your application, then you should use a web service interface. These are not transparent dimensions of the application design and therefore we should not be concerned that they require the use of different APIs.
Where we get in trouble is when we start out with an application that makes one set of design assumptions and later try to change those assumptions without changing the design of the application. If we start out creating a stock-quote function and implement it as a remote-EJB -- using that remote-EJB (RMI-IIOP) interface to enable local-remote transparency for re-distribution -- and then try to offer that function as a business service for incorporation across the enterprise or as a business product, then we have to face the question of whether to expose that EJB with its RMI-IIOP interface or its web service interface. By recognizing the concern that we're trying to address with that component design, the answer becomes more obvious.
Having said that, there are other emerging problems with this topic in J2EE. As service-oriented architecture (SOA) takes hold within information systems design, we're finding that there is an intersection between it and the basic principles of message-oriented application design -- especially for point-to-point messaging. There are many business services that are intrinsically asynchronous in nature. As an extreme example, filling out a mortgage application is a service that has multiple steps and interactions -- and that may take hours, days or weeks to return an answer. We'd like to be able to use asynchronous messaging within the services design; we should not have to make an implementation-time decision about whether to use JAX-RPC or JMS. Likewise, there are occasions where we've used the adaptive properties of the Java 2 Connector Architecture to integrate components of the application design that may have been implemented on other information technologies and that, in retrospect, actually have the characteristic of being a composable business service. In both of these cases we're faced with the dilemma having to shift from 'technology-oriented' interfaces to a service-oriented interface, but where the service-oriented interface support in J2EE -- namely JAX-RPC -- is not yet prepared to handle the capabilities of the technology-oriented interfaces of JMS and CCI. This will be the next challenge for J2EE to address.
Q. How has Java evolved to fit the needs of the growing Web services market?
A. J2EE has responded very well to the emergence of service-oriented architecture, and the specifics of web services. More often than not, technology organizations -- whether they are product vendors or standards organizations -- tend to entrench on their own particular brand of technologies and value-assumptions. In doing so, they tend to react defensively to the emergence of new technologies that appear to threaten their value propositions. That has not been the case with Java and J2EE. Instead, the J2EE community has looked beyond the edges of the technology to recognize the strengths and weaknesses of each technology, and in this case, to recognize that the value of J2EE and web services compliment each other. Said simply, web services are about exposing an abstract representation of application services for business composition that is both language and technology neutral. J2EE is a powerful and flexible technology for implementing applications, including application functions that model business services. The combination is synergistic. There is more work to be done in this space, but we've got a solid start with the inclusion of web services support in J2EE 1.4.