Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

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

  • Print
  • Feedback
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.

  • Print
  • Feedback

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