© 2000 Anthony Grace
|
|
© 2000 Anthony Grace |
| No rated * * * * * | Resize -A +A |
5.1 Introduction
Enterprise JavaBeans ( EJB ) is the server-side component architecture for the J2EE ( Java 2 Enterprise Edition ) platform. EJB 1.1 was provided in December 1999, as part of the first J2EE platform release. EJB 2.0 is expected to be completed by the end of 2000 ( according to the ‘roadmap’ for its release as announced by Sun ). EJB enables rapid and simplified development of distributed, transactional, secure and portable Java applications. EJB is not a product; it is a specification which defines the EJB component architecture, and the interfaces between the EJB-enabled server and the component.
The EJB standard has been widely accepted by many key vendors
in the industry.
Many have already shipped products implementing the EJB specification
or plan to do so.
Basically it looks as though the standard is here to stay. To
begin with, a little history of the development of the Java language
environment might be of help. Java began as a platform-independent
language for creating client-side applets that run inside Web
browsers. Release 1.1 of the Java Development Kit ( JDK ) added
important features such
as object serialisation and database access. In addition, we can
get a servlet API to make it equally suitable for writing server-side
programs - servlets. As well as this, there was the JavaBeans
component model. When all of this is put together, we get what
JavaSoft termed in April 1997 the ‘Java Platform for the
Enterprise’.
Enterprise JavaBeans is an extension to the JavaBeans model targetted at the middle tier. Enterprise JavaBeans takes the lightweight JavaBeans model and extends it with multi-user security and resource management. Note, that to Web-enable Enterprise JavaBeans all we need is a Java-capable Web server.
During the 1990s, traditional enterprise information system providers began responding to customer needs by changing from the well-known two-tier client / server architectural model to more flexible three-tier and n-tier models. New forms of middleware appeared, such as CORBA and DCOM, which separated business logic from system services and the user interface, placing it instead in the middle tier between the two. The steady evolution of these new middleware services was driven by the growth of the Internet and the greater emphasis on lightweight, thin clients.
Multi-tier architectures greatly simplify the development, deployment and maintenance of enterprise applications. Programmers can now concentrate on coding the specifics of their business logic, and rely on different back-end services to provide the infrastructure, and client-side applications - both standalone and within Web browsers - to provide user interaction. Middleware has become a critical part of software development - companies no longer want to rely on low-level communication facilities to integrate their present and future software.
Several separate development efforts pointed the way to what would become the EJB technology. First of all, servlet technology enabled developers to create CGI-like behaviours which supported Java and which could run on any Java-enabled Web server. Secondly, JDBC technology provided a model for integrating the ‘Write Once, Write Anywhere’ features of the Java language with existing database management systems. Finally, the existing JavaBeans component architecture proved extremely useful in encapsulating complete sets of behaviour into easily configurable, reusable components on the client-side. There was a need to extend this modular nature of the client-side JavaBeans components into an enterprise architecture, providing true plug-and-play interconnectivity across the different tiers. The convergence of these three concepts - server-side behaviours in the form of servlets, JDBC connectors to enable access to legacy enterprise systems, and modular, easy to deploy components - led to the EJB standard.
5.2 Components
Components are pre-developed pieces of application code that can be readily assembled into working application sytems ( easy deployment ). As stated already, Java technology already has the, mainly client-side, JavaBeans component model, which supports reusable development components. The EJB architecture logically extends the JavaBeans component model to support server-side components.
Components, being object-oriented in nature, follow one simple rule: one component for one job. For example, a spell-checker component should only know how to perform spell checking and nothing more. It does not need knowledge of grammar rules. Many companies have already adapted the component paradigm. For example, Netscape’s LiveConnect; with LiveConnect, Java components and Netscape plug-ins can share a common object and messaging model. Using the LiveConnect API, an applet or a bean embedded in an HTML page can manage an external non-Java component and interact with other components on the page. Breaking components down into their essentials allows for modular development of larger applications.
Components are not the same as objects. Components can encapsulate entire groups of objects, but still provide a very well-defined interface. When using components, the inner workings ( the relationships between the objects used within the component ) of any particular component are totally hidden from applications using the component. All data and state information is inaccessible from the outside world. Everything is a black box. The only thing that can alter a component’s internals directly is the component itself. Also, the behavior of components cannot be inherited due to the inability to directly alter a components internals. Finished components should not need any extra behaviour implemented by a subclass; this could lead to a break in encapsulation. Note, that objects external to the component may inherit from the objects used within the component. This does not detract from encapsulation, nor does it mean that the component itself can be inherited.
A major advantage to be gained from the use of components is a marked reduction in complexity. Object Oriented Programming ( OOP ) reduces problem domain complexity by decomposing the problem into real-world objects. Component Object Programming ( COP ) decomposes it even further by grouping those real-world objects into individual scenarios. A consequence of this is that unit testing can now be done on a component-by-component basis, which fits in rather well with most project life-cycles. Project teams can be better divided into groups to develop specific components, test them, and finally join them together to form complete applications. The end result is that component-based applications are more extensible and robust. Whenever we wish to add another component, the entire system does not have to be validated. This in turn, results in faster, cheaper and more reliable applications than OOP alone can deliver. Component technology promises a world in which customised business solutions can be assembled from a set of off-the-shelf business objects. Application software companies have already begun to implement applications using server components. Some e-commerce companies are beginning to supply individual application functions, such as a shopping cart and a credit validation service, as customisable components.
5.3 The Java Platform for the Enterprise
The portability characteristics of EJB components are made possible by the Enterprise Java platform. The Java platform is ideally suited for multi-tier computing. On the client, Java provides improvements to the presentation logic via dynamic interaction and animation, through Java applets and JavaBeans. The portability of Java along with its built-in security and multi-threading, makes it the platform of choice for thin-client computing. This is mirrored in the support for Java in all of the major Web browsers today.
The main idea behind Enterprise JavaBeans is to provide a framework for components that can be ‘plugged in’ to a server, thus extending that server’s functionality. The following diagram describes the EJB model:
Figure 27: The Enterprise JavaBeans Model
On the server-side, the Java platform is made up of a set of Application Programming Interfaces ( APIs ) that provide enterprise-class services to multi-tier applications written in Java. The term ‘Java Enterprise Server platform’ refers directly to this set of server-side APIs. Basically, EJB is a cross-platform component architecture for the development and deployment of multi-tier, distributed, scalable, object-oriented Java applications. EJB simplifies the process of writing business applications as components, by providing this set of services to support scalable transactional application server components, thus avoiding the need to deal with low-level system details of managing transactions, threads, load balancing, etc. Developers can now concentrate on the business logic and leave the task of managing the data processing to the EJB framework.
Figure 28: The Java Enterprise Architecture
Through the use of EJB, we achieve real rapid application development as well as code reusability without sacrificing the thin-client manageability and security of the mainframe. This is due to the ease with which we can partition, through EJB, the application into the user interface and the business logic. We can specify the user interface in a Java applet or application, or in HTML using a Java servlet. On the server-side, the business logic is packaged as Enterprise JavaBean Components. EJB can be deployed with ease anywhere on the network. In addition, they can be reused within other business applications running on diverse platforms, and easily managed from a remote console. Prior to EJB this was not easily done. It was a constant struggle to make server-side business objects persistent, find them over the network, secure them, isolate them from sharing conflicts, protect them from failures, manage their lifecycle, and ensure their scalability and availability. EJB screens us from these complexities.
5.3.1 The EJB Server-Side APIs
Enterprise applications typically require access to a wide range of infrastructure services, such as distributed communication services, naming and directory services, transaction services, messaging services, data access and persistence services, and resource sharing services. Since these infrastructure services are frequently built on different platforms using different products and technologies, it is difficult to build portable enterprise-class application systems. However, the Enterprise Java APIs provide us with a common interface to the underlying infrastructure services, regardless of the implementation.
Figure 29: Enterprise Java APIs
API DESCRIPTION
EJB The Enterprise JavaBeans API defines a server component model
that provides portability across application servers and implements
automatic services on behalf of the application components.
JNDI The Java Naming and Directory Interface API provides access
to naming and directory services, such as DNS and COS Naming.
RMI The Remote Method Invocation API creates remote interfaces
for distributed computing on the Java platform.
JIDL The Java Interface Definition Language API creates remote
interfaces to support CORBA communication in the Java platform.
JIDL includes an IDL compiler and a lightweight, replaceable ORB
that supports IIOP.
Servlets and JSP The Java Servlets and Java Server Pages APIs
support dynamic HTML generation and session managemant for browser
clients.
JMS The Java Messaging Service API supports asynchronous communications
through various messaging systems, such as reliable queuing and
publish-and-suscribe services.
JTA The Java Transaction API provides a transaction demarcation
API.
JTS The Java Transaction Service API defines a distributed transaction
management service based on the CORBA Object Transaction Service.
JDBC The JDBC Database Access API provides uniform access to relational
databases, such as DB2, Oracle, Informix, Sybase, etc.
5.3.2 Architectural Elements of the EJB Framework
Distribution
As developers, we do not have to learn new languages like IDL ( Interface Definition Language ). We can easily create distributed beans, as they rely on standard Java language elements, such as interfaces and classes, to define remote methods. Support for remote client access is provided through two standard Java APIs: Java Remote Method Invocation ( RMI ) and Java Naming and Directory Interface ( JNDI ). With RMI, we can create distributed applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. Once a Java program has obtained a reference to a remote object, it can make calls on the methods of that object. It can obtain an object reference either by looking up the remote object with the JNDI naming service, or by receiving the reference as an argument or return value. JNDI allows Java applications to store and retrieve objects of any type by name, as well as to associate objects with directories and search for objects by attributes.
JNDI is a Java extension that provides Java applications with a unified interface to multiple naming and directory services. Thus Java applications can easily locate various services on the network through virtually any directory service. The JNDI service is layered on top of RMI, and uses RMI to communicate with the server on which it performs the lookup. Although the specification mandates the use of RMI for remote method calls, it can be used with all industry-standard distributed object protocols, such as IIOP which is supported through a Java-to-IDL mapping.
Transactions
The J2EE transaction model allows us to specify relationships among methods that make up a single transaction, at deployment time. This way, all methods in one transaction are treated as a single unit. Transactions are all-or-nothing proceedures; either all of the steps in the transaction complete, or everything is rolled back.
EJB uses the Java Transaction Service ( JTS ) API for all transaction monitoring. JTS is a Java implementation of the Object Management Group’s ( OMG ) Object Transaction Service ( OTS ) specification. This allows enterprise beans to work together with other objects conforming to this standard, such as CORBA components. JTS provides methods for starting, commiting and rolling back transactions, and the means to retrieve the current transaction context. It is the transaction context which makes it possible for developers to create an enterprise bean that can participate in the same transaction as non-EJB components; for example, DCOM or CORBA components.
The EJB framework shields developers from much of the underlying complexity in this area. Although developers can elect to do their own transaction management and access JTS directly for a finer level of control, it is not recommended. The EJB container can handle almost all of the necessary transaction management without the developer’s intervention. At the very least, the developer will specify what a bean’s transactional requirements are and the container will look after the starting, commiting, or rolling back of transactions, as needed. Containers will be looked at more closely further on.
Transaction attributes are specified on an application component during assembly. This permits us to group methods in transactions across application components, which means we can easily change application components within a J2EE application, and reassign the transaction attributes without changing code and recompiling.
As well as performing transactions across multiple databases at multiple locations, an Enterprise JavaBean can also initiate multiple transactions across multiple EJB servers. The EJB servers work together to propogate the transaction context across each server; this process is entirely transparent to both the client and the Enterprise JavaBeans component programmer. Each Enterprise JavaBean has a transactional attribute that can be modified by tools provided with the container / server application.
Thanks to the required capabilites of an EJB container, we can, as stated above, seamlessly update multiple databases distributed across multiple locations, without having to write any of the low-level logic necessary to commit or rollback transactions. Each EJB container is required to implement the javax.jts.UserTransaction interface, which is a small part of the overall JTS API. This interface is shown below.
public interface javax.jts.UserTransaction
{
public final static int STATUS_ACTIVE;
public final static int STATUS_COMMITED;
public final static int STATUS_COMMITTING;
public final static int STATUS_MARKED_ROLLBACK;
public final static int STATUS_NO_TRANSACTION;
public final static int STATUS_PREPARED;
public final static int STATUS_PREPARING;
public final static int STATUS_ROLLEDBACK;
public final static int STATUS_ROLLING_BACK;
public final static int STATUS_UNKNOWN;
public abstract void begin();
public abstract void commit();
public abstract int getStatus();
public abstract void rollback();
public abstract void setRollbackOnly();
public abstract void setTransactioTimeout(int seconds);
}
Note, that JSP pages and servlets are not designed to be transactional and should usually delegate transactional work to an enterprise bean. However, if transactional work is necessary in a JSP page or servlet, it should be very limited.
Persistence
First of all, some of the constituent elements of the EJB architecture need to be defined. Enterprise JavaBeans technology supports both transient and persistent objects. A transient object is called a session bean, and a persistent object is called an entity bean. A session bean is created by a client and typically exists only for the duration of a single client / server session. A session bean performs operations on behalf of the client, such as accessing a database. Session beans can be transactional, but are not normally recoverable after a system crash. Session beans can be stateless, or they can maintain coonversational state across methods and transactions. Once the job is done and the client disconnects, that particular EJB instance is destroyed. All state information is lost when the session ends. The container manages the conversational state of a session bean if it needs to be evicted from memory. A session bean must manage its own persistent data.
An entity bean is an object representation of persistent data that are maintained in a permanent data store such as a database; it could represent specific data or collections of data, such as a row in a relational database. A primary key identifies each instance of an entity bean. We can create entity beans either by inserting raw data directly into the database, or by creating an object using an object factory create() method. Entity beans are transactional, and are recoverable after a system crash.
The JavaBeans component model usually limits beans to desktop-bound visual controls that run in client-side ‘container’ applications. Enterprise JavaBeans must also run within a container. However, in this case the containers can be server-side application servers ( Java-based or otherwise ), transaction monitors, databases, CORBA ORBs, Web servers, or any server container that conforms to the Enterprise JavaBeans specification. Basically, Java guarantees portability across hardware and operating system boundaries, while the Enterprise JavaBeans specification guarantees portability across container types and other toolsets.
Enterprise JavaBean objects are kept in containers to provide the proper system-independent interface for distributed computing. The container could be considered a sort of multilingual interpreter which facilitates and translates requests between client and server beans. In order to maintain the neutral interface, the client bean, the container, and the server bean maintain contracts which define how each will work with the other. The EJB server has to provide one or more EJB containers, which provide homes for the enterprise beans. Any number of EJB classes can be installed in a single EJB container. A particular class of enterprise bean is assigned to one and one only EJB container, but a container does not necessarily represent a physical location. The physical manifestation of an EJB container is not defined in the Enterprise JavaBeans specification.
At deployment time, the container automatically generates an EJB Home interface to represent the enterprise bean class, and an EJB Object interface for each enterprise bean instance. The EJB Home interface identifies the enterprise bean class and is used to create, find and remove enterprise bean instances. The EJB Object interface provides access to the business methods within the bean. All client requests directed at the EJB Home or EJB Object interfaces are intercepted by the EJB container to insert life-cycle, transaction, state, security, and persistence rules on all operations.
Figure 30: Enterprise JavaBeans Container
To the client, there appears to be direct interaction with an Enterprise JavaBean through the Home and Object ( or ‘remote’ ) interfaces. However, the Enterprise JavaBeans architecture is designed to enable clients and components to exist in different runtimes on different systems on a network. The container intercedes between client and component, concealing both the bean instance and its actions from the clients.
The entity bean represents data that is persistent; in other words, it can survive beyond the lifetime of the EJB container. As well as business logic, entity beans also represent data stored in a database, although this is not mandatory under the specification. In fact, other data stores, such as flat-file or object database, may also be used. According to the specification, there are two types of persistence: container-managed and bean-managed. With container-managed persistence, entity bean data is automatically maintained by the container using a mechanism of its choosing. For instance, a container implemented on top of an RDBMS might manage persistence by storing each bean’s data as a row in a table. In this type of scenario, it is the responsibility of the container to generate code to transfer data from the entity bean instance to the data store. This code will be generated at deployment time, making it easy to move beans from one environment to another. Alternatively, the container could use Java language serialisation for persistence.
One major advantage of container-managed persistence is that it does not tie the bean to a particular database representation. Whenever the database schema changes, the bean can be easily redeployed, and the container can be made to generate the code necessary to handle the new table structure. This minimises the impact of database changes to the entity beans. Another advantage of this approach is that the entity bean’s code is significantly simplified. The entity bean contains only business logic, while lower-level classes contain the persistent mapping. This separation of business logic from the persistent storage mechanism makes the software more portable, in that it can easily be adapted to a new storage mechanism.
With bean-managed persistence, the bean itself is entirely
responsible for storing and retrieving its instance data. The
developer is responsible for writing code to access the data store
itself, say by using straight SQL. This does not imply that the
developer should also manage transactions. Even though a bean
uses bean-managed persistence, it can still elect to have the
container take care of transaction management. The EntityBean
interface provides methods which the container uses to notify
an instance when it needs to store or retrieve its data.
Security
Enterprise JavaBeans technology automates the use of Java platform security so that entreprise beans do not need to explicitly code Java security routines. Security properties are defined at deployment. The security rules for each enterprise bean are defined declaratively in a set of AccessControlEntry objects within the deployment descriptor object. An AccessControlEntry object associates a method, or an entire bean, with a list of principles ( users or groups ) that have rights to invoke the method. These control lists that are generated can change over time to reflect changes in business needs, without requiring recompilation of the enterprise beans. The EJB container uses the AccessControlEntry to automatically perform all security checking on behalf of the enterprise bean.
Distribution
Enterprise JavaBeans technology uses the Java Remote Method Invocation API to provide access to enterprise beans. As EJB developers, we must define an RMI Remote interface for each enterprise bean. The container then generates the EJB Object interface from the Remote interface definitions. Details of these and similar topics can be got from the Sun website:
http://java.sun.com/products/ejb/white_paper.html
The EJB specification also defines how Enterprise JavaBeans will map to CORBA objects. Due to the requirements in the specification, the following scenarios will be possible:
A CORBA client ( written in any language supported by CORBA
),
can access Enterprise JavaBeans.
A client program can mix calls to CORBA and EJB objects within
a transaction.
A transaction can span multiple EJB objects that are located
on
multiple CORBA-based EJB servers, possibly provided by different
vendors.
This implies that there are two types of clients which use an Enterprise JavaBean:
An Enterprise JavaBean / CORBA cclient that uses the JNDI to
locate
objects, RMI over IIOP to communicate with remote objects, and
the javax.jts.UserTransaction to perform transactions.
A standard CORBA client written in any programming that has
a CORBA
IDL mapping defined. This type of client would then locate the
object using
a COS naming service, CORBA IDL to manipulate the objects, and
the
Object Transaction Service ( OTS ) to perform transactions.
In order for the first type of client to exist, is has to be able to use RMI over IIOP. This facility is being provided with J2EE. When complete, RMI over IIOP will utilise the CORBA pass-by-value extension and will permit Java applications to fully interoperate with CORBA applications developed in other programming applications. As a matter of interest, look at the following website:
http://www.iona.com/
By using IIOP, enterprise beans can interoperate with native language clients and servers. IIOP allows easy integration between CORBA systems and EJB systems. Enterprise beans can access CORBA servers and CORBA clients can access enterprise beans. CORBA and Java make a powerful couple, especially since Java provides automatic garbage collection of unused objects. Until now, Java’s performance had prevented it from being seriously considered for CORBA server implementations. However, as Java performance increases, we will see more and more CORBA server implementions using Java. Java extends the power of CORBA, lending it the ultimate in portability. With Java, CORBA can be installed almost anywhere in the enterprise or on the Internet. Considering the heterogeneous nature of most large networks, Java’s portability has the potential to make the deployment of CORBA-based systmes much easier. While Java RMI might be the better choice for small-scale systems implemented entirely in Java, anyone interested in developing large-scale systems would do well to consider the use of the Java and CORBA technologies together.
5.4 Building J2EE Applications with Reusable Components
The fast-moving and demanding world of e-commerce has put a new kind of pressure on application developers. Now more than ever before, enterprise applications have to be designed, built, and produced for less money, faster, with fewer resources. In order to reduce costs and accelerate enterprise application design and development, the J2EE platform provides a component-based approach to the design, development, assembly, and deployment of enterprise applications.
The J2EE specification defines the following kinds of components:
Application client components
Enterprise JavaBeans components
Servlets and JavaServer Pages ( JSP pages )
- also called Web components.
Applets
Where an application component is installed depends on which tier in the multi-tiered J2EE environment the application component belongs to. The tiers are client tier, Web tier, business tier, and enterprise information tier.
Client Tier
J2EE applications can be Web-based or non-Web-based. With
Web-based applications, the user’s browser runs in the client
tier and downloads static HTML pages or dynamic HTML pages generated
by JSP pages or servlets in the Web tier, from a Web server.
With non-Web-based applications, a stand-alone application
client, or
applets that do not run in an HTML page but in some other network-based
system such as a car-phone, run in the client tier and access
enterprise beans
running in the business tier without going through the Web tier.
The non-
Web-based client could include a JavaBeans class to manage the
user input,
and send it to enterprise bean classes running in the business
tier for processing.
Note that JavaBeans classes are not considered components by the
J2EE
Specification. For details of the JavaBeans specification, refer
to the Sun
website.
Web Tier
J2EE Web components can be made up of JSP pages, Web-based
applets, and servlets that display HTML pages. Note that HTML
pages that
invoke servlets or JSP pages, and are bundled with Web components
during
application assembly, are not considered Web components by the
J2EE
specification. Similar to the client tier, the Web tier could
include a
JavaBeans class to manage the user input, and send it to enterprise
bean
classes running in the business tier for processing. As already
stated,
Web components running in the client tier rely on containers to
support
client requests, responses, enterprise lookups, etc.
Business Tier
Business logic code is handled by enterprise beans running
in the
business tier. An enterprise bean receives data from client programs,
does
any necessary processing, and then sends it to the enterprise
information
system tier for storage. Enterprise beans also retrieve data from
storage,
process it if needed, and sends it back to the client. Enterprise
beans
running in the business tier rely on containers to do most of
the low-level
work, thus shortening development time.
The business tier is also known as the Enterprise JavaBeans
( EJB )
Tier. The business and Web tiers together, make up the middle-tier
in a
3-tiered J2EE application that consists of a client tier, middle
tier, and
storage ( or enterprise information system ) tier.
Enterprise Information System Tier
The enterprise information system tier handles EIS system software,
and includes enterprise infrastructure systems such as enterprise
resource
planning ( ERP ), mainframe transaction processing, database systems,
and
other legacy information systems. For example, application components
might need to access EIS for such things as database access. In
the future,
the J2EE platform will support the ‘Connector’ architecture,
which is a
standard API for connecting the J2EE platform to EIS.
5.5 Designing Web-Based Applications
The first thing to consider when designing the user interface and back-end engine for a J2EE application, is whether to make the application Web-based or non-Web-based. There are several things that need to be taken into consideration such as: platform configurations, download speed, security, network traffic, and network services.
Client and applet user interfaces are usually created with the Swing API, which is available with the Java 2 platform. The Swing API offers a comprehensive set of GUI components, such as tables, trees, buttons, etc., which can be used to provide an extra measure of interactivity than is available with a typical HTML page. Swing also supports HTML text components that can be used to display responses from the server.
In general, a Web-based application uses HTML to display data,
XML to define data so that it can be read and processed by another
program, and JSP pages and / or servlets to manage the flow of
data between the user and the business or storage tier.
To sum up, there are four general types of Web-based applications
that we can implement with the J2EE platform. Moving from simplest
to the most complex, they can be summarised as follows:
Basic HTML
HTML with basic JSP pages or servlets
JSP pages with JavaBean classes
Highly structured applications that divide application
logic into areas organised by function.
It is important when designing a Web-based application, to first decide what to use to build it. If we are beginning with just a simple application, our design should accommodate growth if it is likely that we will add further functionality to the application over time. Refer to Section 4 of this document for details of JSP pages and servlets.
5.6 Conclusions
The challenge facing developers today is that despite an attempt by the industry to create a standard query language and semantics, vendors have usually gone in their own direction, each implementing slight but insidious differences with far-reaching consequences, thus making applications non-portable. Also, the options open to application programmers are both complex and subtle; there is no clear architecture for separating code that implements transaction control from code that implements business logic.
Enterprise JavaBeans is an attempt to remedy these problems by defining a standard architecture for creating multi-user applications based on a multi-tier approach. This new architecture greatly simplifies the choices that an application programmer has to make, and delegates most of these concerns to an infrastructure layer that is the responsibility of the middleware vendor.
The Java Enterprise Server platform offers us many of the same advantages on the server as Java does on the client, such as portability and security. Java provides the necessary ‘glue’ that integrates and extends the different systems across the enterprise. Using the Java Enterprise Server platform, an organisation can quickly deploy platform-independent applications leveraging existing transaction processing monitors, system management, data access, CORBA Services and other system infrastructures. In other words, an organisation can use the Java platform to ‘layer and leverage’ existing hardware and software in new and exciting ways.
[Your opinion is important to us. If have a comment, correction
or question
pertaining to this chapter please send it to comments@peoi.org.]
| Previous: CGI the Java way |
Next: Foreword |