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.
Q. How has .NET impacted Java in the Web Services space? How is Java and .NET coexisting in the market? Are we going to see radical enhancements in the support for Web Services in Java in the near future?
A. Microsoft appears to have dedicated themselves to a business model that attempts to limit their dependence on open system standards. I’m sure that gives them a lot of flexibility to optimize the efficiency of their innovation processes. However, given their dominance in the market place, that focus on proprietary technologies has in many ways constrained the growth of the information technology industry at large. It’s as if GE were to declare that their appliances will only support outlets of a certain proprietary shape or voltage. It might give their appliances some sort of technological advantage, but it would limit the utility of electricity in our homes because we’d have to install different outlets for different appliances. Given that Microsoft has finally overcome its reluctance to support an open standard for interoperation, that has put a lot of importance on web services. The web services specification has its own intrinsic value to the extent that it enables a service-oriented architecture for business composition. However, it now has the added advantage of being the only technology specification that enables open interoperation with Microsoft. In that sense, .Net has validated both SOA and the use of web services to enable standard interoperation with Microsoft’s proprietary platform. This further legitimizes the support in Java for web services, and in doing so indirectly expands the information systems marketplace by increasing the utility of business composition. The only ‘radical’ enhancement I envision happening for web services support is simply the result of an accelerated understanding of the role of business composition in application design, and the skills, methodologies, patterns and tools that enable it to be used more efficiently, and to enable greater value to customers and their businesses.
Q. Java began as a cross-platform technology with a small footprint for small devices. How has Java kept this promise with the Java 2 Mobile Edition (J2ME)?
A. One of the greatest challenges we face with the Java platform specifications is in harvesting and cross-pollinating them for mutual benefit. J2ME has retained its focus on the small footprint requirements for pervasive devices. However, increasingly, ISVs and customers want to be able to share their development skills and tools between a variety of deployment platforms for their applications. Building the presentation logic for an application that will be hosted on a J2EE application server should not require a completely different set of tools, technologies and programming practices than those that are needed to build the presentation logic for an application that will be hosted on a cell phone or PDA. In essence, there is a driving need to incorporate some of the programming model concepts introduced by J2EE into the J2ME platform. Likewise, the reduced footprint characteristics and provisioning concepts employed in the J2ME platform have benefit to the J2EE platform — for reducing the hardware and deployment components of the total-cost-of-ownership (TCO) equation. Ideally, there would be one core programming model for J2ME and J2EE supporting a range of quality of service and scale objectives that can be measured along a continuum. I think there is a growing interest in the community to achieve that goal.
Q. How promising is the Desktop Java technology?
A. It’s hard to imagine Java ever fulfilling its ‘write once run everywhere’ mantra without providing an attractive set of services for all of the major styles of information computing. Desktop computing is clearly an important style of computing, and Desktop Java is targeted at catering to that need. The fact that you can leverage your existing Java skills for building desktop applications combined with the premise that desktop applications built to Java and Desktop Java services will be portable between Windows and other desktop platforms such as Linux is going to make it very attractive to a lot of application developers.
Q. Considering the growing popularity of Eclipse, what new development tools can we expect from the IBM stable for Java?
A. We believe that greater developer productivity and increasing business agility can be drawn from model driven architecture (MDA) approaches to application development. This is a leading premise in the Rational tools suite, and was driving force behind the decision to acquire Rational last year. The fact that the Rational tool suite was already based on the Eclipse framework means that Rational modeling tools can already be incorporated into an integrated development environment; it enables us to deliver that value proposition to ISVs and customers immediately.
Q. How is Java growing and evolving to serve the needs of the developer community?
A. Information computing technology was introduced to corporate businesses fifty years ago. Since that time, the developer community has faced the same challenge: to reduce the backlog of application development requirements that the business has put on information computing. This translates into the need to both increase developer productivity (the rate at which application assets are created) and application durability (the period and conditions under which those assets continue to return value to the business). Java has already gone a long ways towards increasing programmer productivity simply by enabling portability of programming skills — moving from one project to the next no longer requires that you completely retrain all of your developers, even if the next project is trying to address a completely different set of computing needs. The J2EE platform goes a long ways towards making application assets more durable — component technologies separate the concerns of the business logic from the concerns of the underlying information technology to enable the component to be re-used in a larger variety of conditions. It also allows for specialists in different information technologies to all contribute collaboratively to delivering an application solution to the business.
Java continues to evolve and introduce even more benefits in both of these areas. The J2EE platform vendors continue to improve the quality, scalability, and ubiquity of their respective products — which in turn increases the value and efficiency of applications that are implemented to the J2EE specification. J2EE 1.4 has introduced support for web services for business composition that in turn will increase the efficiency and agility of business processes. The focus for the J2EE 1.5 JSRs is on further reducing the barrier to entry for programmers that want to gain the benefits of the J2EE platform for their application development needs.
Q. Why did IBM choose not to join the Java Tool Community?
A. There hasn’t been a compelling reason to join it. The JTC has yet to publish a clear definition of what it intends to accomplish — other than to be a community. IBM has focused its time and attention on ensuring that Eclipse succeeds as an open systems tools platform standard. It is not clear that supporting another tools community beyond Eclipse has any benefit for IBM, our customers, the tools industry or the information computing industry at large. That’s not to say that Eclipse.org may not get involved with the JTC in the future.
Q. What does 2004 hold for Java? What improvements are necessary to maintain its momentum?
A. I expect Java to improve on two fronts this year: First, the major J2EE platform vendors will deliver commercial implementations of the J2EE 1.4 specification for use in production environment. This will further extend the utility of the J2EE specification for use in common and mission-critical application deployments, and in turn further the expansion of intellectual capital built on the Java foundation. The inclusion of web services standards in the J2EE 1.4 specification will enable the exploitation of the benefits of business composition within application design. I expect ISVs and application developers will hone their skills in service-oriented architecture; businesses will see an acceleration in the user of Java to achieve the benefits of business composition and agility that can be achieved with service-oriented architecture. Second, we will see improvements in the development tools to further productivity of application developers and to lower the barrier of entry to exploiting the value of the J2EE platform. These advances will likely be incorporated in the next release of the J2EE platform specification.