The state of Java application middleware, Part 1

Find out what 'Java middleware' really means, what products fit into this category, and how middleware may impact your efforts as a developer -- and as a business

By Cliff Berg, JavaWorld.com, 03/01/99

Client/server is dead. That's the buzz now that newer Internet-based technologies are flourishing. But those new technologies are merely the natural evolution of earlier approaches, implemented with newer, more open protocols and designed to provide greater scalability, manageability, and diversity.

The magnitude of this evolution is astounding. Most of the major client/server vendors have modernized their products and now direct their marketing dollars into three-tiered technologies. In most cases, the newer products are Java-centric and Internet-protocol centric. For example, I identified at least 46 Java middleware products at last count. Two years ago it would have been hard to come up with half that number.

This is the first of a two-part series of articles dedicated to explaining general-purpose Java middleware in its current forms. In this first article, I'll examine the features of current products and explain why these features are important. In the second part, Anil Hemrajani will examine Enterprise JavaBeans (EJB) and show how the current generation of Java middleware products relate to and support this important component standard.

Background

First of all, let's define Java middleware. The term encompasses application servers like BEA WebLogic, messaging products like Active Software's ActiveWorks and Push Technologies's SpiritWAVE, and hybrid products that build on a DBMS legacy and add server-based Java object execution features. I could have focused on a more narrow segment, such as application servers, but that would have been unfair to the many products that don't fit this category precisely but nevertheless should be considered for multitier applications. Further, even among application servers there is quite a spectrum, including those that are primarily servlet servers as well as those that are ORB-based or OODB-based. Drawing a line between all these products proves increasingly difficult. The unifying feature, however, is that they all attempt to solve the multitier application deployment problem by using Java and Internet technologies.

The business case to use Java in middleware is compelling; among the advantages offered by Java middleware are the following:

The ability of the Internet to economically interconnect offices and organizations
The need for organizations to cooperate by sharing data and business processes
The desire to consolidate generic services and the management of these services
The desire to provide centralized application management, including startup, shutdown, maintenance, recovery, load balancing, and monitoring
The desire to use open services and protocols
The desire to redeploy business logic at will and unconstrained by infrastructure; this necessitates using open APIs and protocols, which are widely supported across most infrastructure products
The need to support cooperating mixed-architecture applications
The desire to move network and service infrastructure decisions out of the application space, so that system managers can make infrastructure decisions without being hampered by applications that depend on proprietary protocols or features
The desire to reduce the diversity and level of programmer staff skills needed and minimize the need for advanced tool-building expertise within projects
The desire to leverage object-oriented expertise by extending it into the server realm -- hence newer object-oriented server products and object-to-relational bridges

The goal of middleware is to centralize software infrastructure and its deployment. Client/server originates from an era of integration within a single department. Organizations now commonly attempt integration across departmental boundaries -- even from one organization to another. The Internet -- which entices businesses with its ability to serve as a global network that lets departments and partners interconnect efficiently and quickly -- has generated the demand for this integration.

Java provides a lingua franca to easily interconnect data and application across organizational boundaries: In a distributed global environment, in which you have no control over what technology choices your partners may make, smart companies choose open and platform-neutral standards. Companies cannot anticipate who will become their customers, partners, or subsidiaries two years down the road, so it isn't always possible to plan for a common infrastructure with one's partners. In this uncertain situation, the best decision may be to use the most universal and adaptable technologies possible.

Java lets you reduce the number of programming languages and platforms your staff must understand. Why? Because Java is now deployed in contexts as diverse as Internet browsers, stored procedures within databases, business objects within middleware products, and client-side applications.

At the age of three, however, Java technology is still somewhat immature, and this is true of the products discussed in this article. On the other hand, we may now be in an era when products never truly reach maturity, because the underlying technologies on which they're based change so rapidly. In fact, I've found significant problems with virtually every middleware product I've used, including supposedly mature products that have been on the market for a few years and have recently come out with significant new features. The point is, by the time a vendor manages to fix problems, new features have been added. The cycle for adding new features is now much shorter than it has ever been, and so products don't have enough time to become stable before they include the next major feature set. This may be something we have to get used to, and learning the strengths and weaknesses of the products we choose is an important part of any application design and prototype cycle.

Goals for middleware

The EJB middleware component standard was developed with the following goals:

To provide component interoperability. Enterprise beans developed with different tools will work together. Also, beans developed with different tools will run in any EJB environment.
To provide an easy-to-use programming model while maintaining access to low-level APIs.
To address lifecycle issues, including development, deployment, and runtime.
To provide for compatibility with existing platforms, which allows existing products to be extended to provide support for EJB.
To maintain compatibility with other Java APIs.
To provide interoperability between EJB and non-Java applications.
To be compatible with CORBA.

The focus of the EJB standard is therefore on creating an interoperability standard for Java middleware, shielding programmers from having to deal with many of the difficult issues that arise when developing distributed applications. This allows software developers to concentrate on business logic instead of writing sophisticated homegrown infrastructure and tools. As a result, businesses can put most of their educational resources into training staff in business processes, which typically is what provides the greatest payoff.

To the list above, I add the following additional goals for enterprise-class Java middleware. These product features are needed in the long term in order to successfully run and maintain a middleware-based environment:

It should accommodate the interconnection of multiple business units, companies, and customers in a distributed infrastructure without compromising security or introducing chaos
It should allow flexible yet reliable access control mechanisms to assure that business-partner data is accessed only in the intended ways, and only by the intended parties
It should allow system administrators to manage a distributed computing environment containing large numbers of business logic components in a uniform way, without having to understand or apply unique procedures to particular components
it should allow system administrators to make infrastructure component selections without impacting applications, and to tune and scale those components and have a uniform and generic means of measuring the performance and resource needs of all applications
It should allow business components to be relocated between clients and servers without impacting the architectures of either
It should provide a security mechanism that allows particular users to add new components, without having to give the server administrator access to all components and data sources (this is a great opportunity for value-added capability, as it is critical to extranet and partnership applications)

Components and features of Java middleware platforms

The fastest-growing category of Java middleware today is probably application servers. However, it is essential to realize the wide variety of application servers (and other kinds of middleware products) that exist. Distinctions among Java middleware product categories today are represented not by a line but by a vast middleware continuum. I will now discuss the features of Java middleware, based on my own work comparisons, which encompass every class of Java middleware product I know about.

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | Next >

Resources

Digital Focus's Java middleware information Web site includes a list of Java middleware and middleware product newsgroups http://www.digitalfocus.com/middleware
The Sun RMI/IIOP early access release provides a preview of the upcoming RMI-over-IIOP product http://java.sun.com/jdc/earlyAccess/rmi-iiop/index.html
The CORBA Component Specification defines a proposed CORBA standard for server object deployment, activation, state management, and lifecycle http://www.omg.org/techprocess/meetings/schedule/CORBA_Component_Model_RFP.html
The EJB Specification, revision 1.0, defines the Enterprise JavaBeans component model ftp://ftp.javasoft.com/docs/ejb/ejb.10.pdf
The Java Transaction API Specification, revision 0.93 (the latest as of February 18, 1999), defines a transaction management interface for performing client-demarcated transactions, as well as an architecture for building interoperable data sources and XA-compatible drivers http://java.sun.com:80/products/jta/jta-093.pdf
The JDBC 2 Standard Extension API Specification, revision 1.0, adds new capabilities to JDBC for connection pooling, transaction management, and Rowsets http://java.sun.com:80/products/jdbc/jdbcse2.html

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq

We're hiring Senior Software Consultants! Come work for the fastest-growing Agile consultancy in the mid-Atlantic region! - Stelligent

RESEARCH CENTERS: Java Standard Edition | Java Enterprise Edition | Java Micro Edition | Development Tools

About Us | Advertise | Contact Us | Terms of Service/Privacy

Featured Whitepapers

Newsletter sign-up

The state of Java application middleware, Part 1

Find out what 'Java middleware' really means, what products fit into this category, and how middleware may impact your efforts as a developer -- and as a business

Background

Goals for middleware

Components and features of Java middleware platforms