The Enterprise JavaBean specification demonstrates the evolution of distributed objects from middleware to application components. In this article we'll discuss where EJB fits into the distributed object landscape.
Middleware in the Middle Tier
The three-tier architecture is fundamental to the deployment of applications on an Internet-based infrastructure. A Web server fronts the middle tier (see Tier 2 in Figure 1), and there are many systems behind it that constitute the value-add for an e-business application. From a practical perspective, e-business applications are assembled from disparate components and must be accessible to Web clients (Tier 1) through the Internet and reach relevant data repositories (Tier 3), such as financial data or travel reservations.
Middleware is the glue that integrates systems within the middle tier. It plays a vital role in application reliability since integration points among the various systems are potential points of failure. As distributed object technology has become well accepted within mainstream software applications, standards such as CORBA and Java's RMI have emerged as preferred object-communication mechanisms. However, from an application perspective, these technologies present a rather low abstraction level, leaving the task of defining how components should interoperate to the programmer. This means inventing proprietary programming interfaces that must be adhered to by all parties involved with the creation of the application.
One fact of life concerning technology is that the "waterline" is always rising, making technology more accessible and easier to use (see Figure 2). In the Internet era the waterline corresponds to the higher level of abstraction presented by technologies for assembling Web-based applications. More to the point, software frameworks provide a simpler model for creating e-business applications, supporting the development of software components that can easily work together.
An application component implements some core business logic for an application. A framework is a software infrastructure that defines certain rules of engagement among application components. These rules are typically implemented as services with standardized interfaces that allow components to interoperate without prior knowledge of other components' existence. The ability to cut and paste information between different desktop tools is a classic example. A framework also provides an execution environment for end users and applications, as in the Microsoft Windows desktop.
Although frameworks and component models offer convenience for quick assembly of applications, only those based on proprietary technologies and captive install bases, such as Microsoft's OLE for desktop integration, have historically enjoyed widespread industry acceptance. But thanks to the Internet, the tide appears to be turning for an open standard framework as the industry embraces EJB.
Relationship of EJB to CORBA and RMI
CORBA is an open industry standard that facilitates remote object invocation via published interfaces. However, it doesn't yet specify a market-accepted component model for plug-and-play interoperability. (We'll touch on CORBA's new component model specification in a little while.) To illustrate this point, contrast CORBA with its parallel universe, Microsoft:
DCOM is to CORBA as OLE is to ________.
In other words, DCOM and CORBA provide the communication substrate in their respective universes. OLE is the framework that sits on top of DCOM; you'd experience it daily as a Windows user. But in the CORBA universe, what is analogous to OLE? What provides the higher abstraction level moving up the waterline?
The answer isn't particularly clear yet, but EJB seems to be emerging as a viable solution for e-business applications.
The EJB specification defines an execution and services framework for server-side Java components. Application servers house EJB containers that together manage threading, transactions, object lifecycle and other EJB needs. EJB's growing acceptance as a standard component model for middle-tier applications is supported by commercial products from industry movers like IBM, BEA Systems and Oracle, and by increasing adoption by customers. For an EJB to be accessed from outside the framework, its container must expose a public interface through CORBA or RMI (see Figure 3). Since RMI is a Java-only communication mechanism, it can be used over IIOP to speak to non-Java applications.
It should be noted that the CORBA Component Model (CCM) part of the recently adopted CORBA 3.0 specification defines a framework for application components implemented in any major programming language. CCM extends the EJB model that will allow Java and other programs to operate on the same CORBA platform.
Challenges for Objects in E-Business
With the rapidly growing need to integrate heterogeneous systems and enable applications for e-business, system components are being tied together as distributed objects. These can be new application modules, such as EJB components, or existing applications that are encapsulated in order to be integrated into the environment. Distributed objects exhibit some very useful characteristics:
- Objects can be located anywhere across a network, obviously a necessary attribute for distributed applications.
- Transparent access allows clients to interact with servers regardless of physical location. The underlying CORBA or RMI infrastructure takes care of locating a server resource. Transparency is also very important to developers as it allows them to build applications without having to worry about networking or communication details.
The sophisticated nature of three-tier e-business applications presents several challenges for successful deployment:
- By using CORBA's IDL for describing object interfaces, an application can be implemented in the programming language that's appropriate for the task at hand and can reside on any platform. For example, a Java object running on a Windows platform can invoke a C++ object on a UNIX platform. The Java client isn't aware that the server is implemented in C++ since it's communicating with the server using native Java constructs.
- Distributed objects provide the basis for building and deploying component-based applications capable of supporting e-business.
- Complexity: A typical e-business site consists of many different system components, including various platforms, application modules and network connections. Distributed object applications introduce a whole new development paradigm that requires deployment and maintenance issues to be considered as early in the development cycle as possible. Ask yourself: How will I diagnose system problems in the lab or the field? How will I control or log usage of my server objects?
- Coordination: In a system with this magnitude of diversity and distribution, there are many participants in the creation and deployment of the various components. It's no longer typical for an entire application life cycle to be managed by a single department; input must be marshaled from multiple sources. Questions of coordination include: Does the client application developer understand the semantics of the interface presented by a particular server? Is the correct version of the server implementation being used?
Before going live it's imperative to test the system and validate that it'll perform correctly. Rapid change introduces uncertainty: Will the system function properly? Will it scale with anticipated loads in production? What happens if a server object fails? The ability to methodically capture test cases and performance metrics is essential to quantifying the success of change. Even after ensuring that the system will work in a test environment, the behavior of the live system must be monitored. This will uncover potential problems and allow iterative improvements to be made, thereby maximizing the system's reliability.
- Change: In the age of e-commerce, applications are updated more rapidly. Delivery cycles can be months, weeks or even days. Numerous e-business applications are built every day only to fail in production due to a lack of scalability, flexibility or reliability. Middleware products are changed from one vendor implementation to another or even between implementations from the same vendor witness the existence of multiple application servers from leading vendors. Moreover, changes to e-business applications are introduced incrementally into live systems since the entire system can't be brought down to roll out a new release of a component.
Application servers based on the EJB specification facilitate the creation of Web-based e-business applications. Such applications operate in the middle tier and rely on distributed object communication for interoperability. To make sure an EJB implemention will run reliably, one can test its behavior and scalability from outside the framework. This can be achieved by exercising functionality and simulating usage models through public interfaces via the CORBA or RMI protocols. Test automation can help streamline the process of assuring the reliability of an EJB application.
Segue Software's reliability solutions address EJB functionality and scalability, and offer mechanisms for diagnostics and control in a distributed object environment.
The power of distributed object technologies such as EJB lies in the support for object-oriented designs and distributed implementations. The payoff for a successful component-based application can be substantial, but the costs can be even more significant if the proper steps aren't taken to guarantee the quality of design and implementation. To ensure the reliability of e-business applications, it's necessary to cover the following essentials for successful deployment:
As distributed objects evolve from middleware to application components, the need for advanced test automation grows. EJB is an early example of industry consensus around application components in the middle tier of e-business, and is therefore driving the technology waterline for test automation upward.
- Function: Validate that each component functionally behaves as expected.
- Scalability: Ensure that components perform well under various load conditions.
- Diagnostics: Monitor, troubleshoot and analyze behavior anywhere in the system.
- Control: Meter usage of and control access to objects.
Todd Scallan is the
director of product
management for Segue Software's distributed computing products. He holds a BS in electrical engineering from Lehigh University and an MS in computer engineering from Syracuse University.
He can be reached at: [email protected]