The state of Java application middleware,
Part 1 - JavaWorld March 1999
Tutorial Details:
The state of Java application middleware, Part 1
The state of Java application middleware, Part 1
By: By Cliff Berg
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
lient/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.
Object, component, and container models
Application components must adhere to some runtime deployment model, which specifies how the component communicates with its environment; (possibly) how it is installed, started, stopped, and called; and how it accesses services important for its environment. Popular Java-centric server-component runtime and container models include RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages), and Java stored procedures. In addition, the component models can be expressed in a variety of underlying languages, inc
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: The state of Java application middleware,
Part 1 - JavaWorld March 1999
View Tutorial: The state of Java application middleware,
Part 1 - JavaWorld March 1999
Related
Tutorials:
 3D graphics programming in
Java, Part 3: OpenGL
3D graphics programming in
Java, Part 3: OpenGL
|
How to write
a Java Card applet: A developer's
guide
How to write
a Java Card applet: A developer's
guide
|
Web services hits
the Java scene,
Part 1
Web services hits
the Java scene,
Part 1
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Good
introduction to JDO
Good
introduction to JDO
|
Comparison between the two major JDO architectures
Comparison between the two major JDO architectures
|
Jini's relevance emerges, Part
2
Jini's relevance emerges, Part
2
|
J2SE 1.4
breathes new life into the CORBA community, Part
1
J2SE 1.4
breathes new life into the CORBA community, Part
1
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Should you go
with JMS?
Should you go
with JMS?
|
A first look at JavaServer Faces, Part I
A first look at JavaServer Faces, Part Learn how to implement Web-based user interfaces with JSF
|
Introducing the Portlet Specification, Part 1
Introducing the Get your feet wet with the specification's underlying terms and concepts
|
Clustering and Load Balancing in Tomcat 5, Part 2
Clustering and Load Balancing in Tomcat 5, Part 2
|
A Generic MVC Model in Java
A Generic MVC Model in Java
Model-View-Controller (MVC) is a widely used design pattern, especially popular in graphical user interface (GUI) programming. JDK 1.5 introduces parameterized types, or generics. Combining the two allows for a generic imple
|
JMS Messaging Online Resource
JMS Messaging Online Resource
JMS Tutorials
JMS provides a way for Java programs to access an enterprise messaging system, also known as message oriented middleware (MOM). Check out the below tutorials.
|
Getting Started with Java Message Service (JMS)
The Java Message Service (JMS) is designed to allow Java applications to use enterprise messaging systems. It makes it easy to develop enterprise applications that asynchronously send and receive business data and events. Learn how to implement it for you
|
Getting Started with Java Management Extensions (JMX): Developing Management and Monitoring Solutions
The Java Management Extensions (JMX) API is a standard specification developed through the Java Community Process (JCP) as JSR 3 for managing and monitoring applications and services.
|
First Step towards JDBC!
First Step towards JDBC!
First Step towards JDBC
Introduction
T his article introduce you with JDBC and shows you how to create a database application to access the databases. For the shake of simplicity, in very first example Access database and
|
Introduction to the JDBC
Introduction to the JDBC
Introduction to the JDBC
Introduction
T his article introduce you with JDBC and shows you how to our search engine with database.
What is JDBC?
J ava Database Connectivity or JDBC for short is set of Java API's that
|
Solaris 10 OS Certification Beta Exams
If you are an expert in system and network administration, you can get involved in the creation of three new Solaris 10 certification exams. These Beta exams count toward official Solaris Certification and allow you to provide comments and technical feedb
|
|
|
|
