Download Enterprise Java and Rational Rose -- Part I

Copyright Rational Software 2001
http://www.therationaledge.com/content/jan_01/t_entrose_ka.html
Enterprise Java and Rational Rose -- Part I
by Khawar Ahmed
Technical Marketing Engineer
Rational Software
Loïc Julien
Software Engineer
Rational Software
"We believe that the Enterprise
JavaBeans component model and
associated Java 2 Enterprise
Edition standards will dominate
the application server market and
drive a potential market growth
rate of almost 180 percent yearto-year."
Mike Gilpin, Giga Information
Group
In this two-part series, we explore the synergistic relationship between
Java 2 Enterprise Edition (J2EE), a popular development platform for
distributed enterprise applications, and Rational Rose, the industry's
leading CASE modeling tool. Part I provides an introduction to J2EE from
an architectural perspective. Part II will begin by explaining how Servlets
and JSPs work within the J2EE architecture and then go on to show how
Rational Rose can help developers build better J2EE applications.
With the advent of a "the network is the computer" application paradigm,
the popularity of distributed applications has grown dramatically, and J2EE
has quickly become one of the dominant distributed applications
environments. If its adoption rate to date is any indication, J2EE, which
includes the Enterprise JavaBeans (EJBs) technology, should prove to be a
promising means for achieving component-based software development.
Of course, component-based development will be effective only if it can be
used to build distributed systems with contemporary n-tier application
architectures, and if those systems are portable across different hardware
and runtime environments: servers, underlying databases, etc. We believe
that using Rational Rose greatly simplifies the task of developing J2EE
applications.
J2EE: Responding to Enterprise Application Needs
Enterprise applications have grown more complex over the past several
years, reflecting evolutionary changes in software technology. Let's start
off by looking at some common characteristics of these applications:
●
●
●
●
●
Enterprise applications are often mission critical, meaning they have
a direct impact on the bottom line. Think about businesses like EBay
or Etrade: their Web site IS their business!
Enterprise applications are often distributed; they are deployed
either on multiple machines in the same general area or on
geographically separated machines. These days, the typical
distribution vehicle is an intranet or the Internet.
Enterprise applications typically require the ability to handle a large
number of users (or flexibility to expand quickly should the need
arise).
Enterprise applications require certain services, such as security (to
prevent unauthorized access) and complex transaction processing
(an Internet bank would require both withdrawal and deposit
transactions to complete a fund transfer transaction, for example),
as well as database access.
Enterprise applications often have a large user base. System
administrators should be able to upgrade, maintain, and redeploy
the application with minimal effort.
These are exactly the kinds of challenges J2EE is designed to address.
Every new technology is created in response to certain needs, and J2EE is
no exception. Essentially, it is a unified release of various Java
specifications developed and popularized by Sun over the last few years.
The J2EE specification focuses on two basic categories: technology and API
specifications.
The technologies within J2EE address server-side development needs.
These include:
●
●
●
Enterprise JavaBeans, which are used for building components that
live on the server.
Java Servlets, which provide the means for interactions with Web
clients.
JavaServer Pages, which allow developers to create dynamic
content for thin clients.
The primary purpose of the J2EE APIs is to enable developers to write
J2EE applications in a vendor independent, portable fashion. The following
J2EE APIs are available:
●
J2EE connector -- to link an enterprise application to one or many
EISs (Enterprise Information Systems).
●
●
●
●
●
●
●
JDBC Standard Extension -- to link an application to a relational
database.
Java Message Service (JMS) -- to bring the power of messaging to
an application.
Java Transaction API (JTA) -- for transactional enterprise
applications.
JavaMail -- to bring a mail mechanism to enterprise applications.
JavaBeans Activation Framework (JAF) -- to be used within
JavaMail.
Java™ API for XML Parsing (JAXP) -- for any XML-based enterprise
application.
Java Authentication and Authorization Service (JAAS) -- to bring a
security layer to enterprise applications.
What really makes the J2EE packaging work are the new things Sun
Microsystems has added:
●
●
●
●
An Application Model. This development guide helps you understand
how to use the various pieces of J2EE.
A standard platform for enterprise application development.
A compatibility test suite. Vendors of J2EE products use this suite to
test their products for J2EE compliance.
A reference implementation. This is an implementation of the
platform described above. It gives you an operational perspective of
J2EE: something you can actually run and see in action. It's great
for hands-on learning about J2EE, demonstrating J2EE capabilities,
and so on.
Simply put, J2EE makes it easier for mere mortals to write some very
complex software. Essentially, you don't need to be an expert in
distribution issues, scalability issues, and all the nuances of security. That
is all built into the specification. Vendors of J2EE runtime environments
provide the underlying technology for you to use out of the box. To a large
degree, you can mix and match tools, vendors, and technologies. That
means you are not hostage to a single vendor. Plus, you can leverage
existing investments instead of starting from scratch when you make an
infrastructure change.
Another advantage of J2EE is that it decouples application development
from deployment and execution. You can defer the details of deployment
to the Deployer, a new role defined by the J2EE specification. The deployer
specializes in, and is responsible for, deploying J2EE software to specific
servers. Separating this function allows the developer, or Application
Component Provider, as J2EE refers to the role, to create a generic
application. The deployer is then free to customize the application for the
target execution environment, in accordance with what database will be
used, who is allowed to access the application, etc.
Finally, using J2EE makes it easier for a developer to build, maintain, and
update an enterprise application. It allows you to use third party or
Common Off The Shelf (COTS) components in your application. If
something changes, then you can modify just that specific component
rather than the whole application, and so on. To do the work of putting
together components from different sources, J2EE defines another new
role: an Application Assembler. Figure 1 shows the relationship among the
different roles that J2EE specifies.
Figure 1: The Relationship Among J2EE Roles
(View full size graphic in new window)
In a nutshell, J2EE brings together the pieces and players required for
building scalable, distributed systems, and provides a comprehensive
platform for building enterprise applications in Java.
J2EE and Other Java Platforms
You are probably wondering if there's a relationship between J2EE and the
other Java platforms. In fact, there is! Sun has defined three platforms, all
derived from the core Java technologies. They are targeted to three
specific domains in order to provide specialized solutions for each:
●
The consumer domain and the embedded market.
●
The "general" application domain that uses core Java technologies.
●
The enterprise application domain and the e-business market.
J2EE and Multi-Tier Architecture
An enterprise application may (but does not necessarily) consist of several
tiers. Tiers are primarily abstractions to help us understand the
architecture. The J2EE architecture usually involves four distinct tiers, as
shown in Figure 2.
Figure 2: Multi-Tier Architecture
Say you are doing some shopping on the Net. Your browser is in the Client
Tier displaying applets, HTML, etc. When you press "Submit," it invokes a
servlet to run on the Web server, which resides in the Web Tier. The
servlet may need to get some data via an EJB residing on the App Server
in the Business Tier. The EJB may then need to access a database and
retrieve the information you want in the Enterprise Information Systems
(EIS Tier) .
More precisely, the tiers are distinguished as follows:
The Client Tier -- The Client Tier provides for the interaction
between the Web application and the end users, typically
through a thin client such as a browser. The technologies
involved in this configuration are D/HTML, XML, XSL, Java™
Applet, etc.
A client may also be an "application-based" client that connects
to an Enterprise Information System client. Such clients are
commonly referred to as think clients.
The Web Tier -- The Web Tier is the interface between the end
user and the business logic of your application. By separating
the presentation logic from the business logic in this fashion,
you can update the look and feel of your application without any
modification to the business logic itself. This also allows you to
have a throw-away facade that lets you stay in sync with the
latest Internet technologies. At this level, you typically find the
JSPs (Java Server Pages) and Java Servlets technologies, as
well as use of XML, XSL, HTML, DHTML, GIF images, JPEG
images, etc.
The 1.2 specification of J2EE also introduced the notion of a
Web Application, which means that your Web-tier application
can be packaged in a Java Archive called a Web Archive (.war
file).
The Business Tier -- This is where you implement the
business logic, that is, the actions that make up your
application. These actions are encapsulated within components
called Enterprise JavaBeans (EJBs). By far the most popular
technology of the J2EE family, the Enterprise JavaBeans
architecture brings to your application all the system-level
services it might require, such as transactions, security,
persistence, or multi-threading. These aspects of EJBs are
handled by the EJB container, which we will discuss shortly.
The EIS Tier -- In this tier, you provide persistent storage for
the resources required by your application.
Although an application does not have to have all these tiers as
independent entities, it helps to conceptualize an application component as
belonging to a specific tier so you can structure it appropriately. Such an
approach is recommended for achieving a sound architecture.
The J2EE Conceptual Model
Let's now visualize J2EE as an onion with several layers of skin.
The outermost layer is the server software, which enables application
software to run on the physical hardware. The container is the next layer
in. It provides generic services and hosting for the enterprise application.
The enterprise application consists of EJBs, servlets, and JSPs. Each
container provides services to the EJBs and servlets it is hosting. These
services are provided via the J2EE APIs, as specified by the J2EE
specification.
To understand the container model within a more familiar context,
consider this. If you, as a developer, want to access a relational database,
you probably don't really want to know what kind of caching architecture
the database provider is using. Nor is there likely a strong desire on your
part to implement all the access details. Given that all databases are
conceptually similar, what you need is an abstraction for the database that
easily provides access to the data and associated services. A container
that holds your data with a set of services is that abstraction. The J2EE
simply extends this container/data architecture to the enterprise
application domain.
Figure 3 shows the J2EE Conceptual Model.
Figure 3: J2EE Conceptual Model
The J2EE platform defines four containers: a Client Container and an
Applet Container (Client Tier), a Servlet and JSP Container (Web Tier) and
an EJB Container (Business Tier). These containers provide deployment
and runtime support for the associated tier components. A container is
located within a server. The relationship between a server and the
containers within it is illustrated in Figure 4.
Figure 4: Relationship Between a Server and the Containers Within It
What Are Enterprise JavaBeans?
The primary purpose of Enterprise JavaBeans (EJBs) is to simplify the
development of business logic. EJBs, which are non-visible, server-side
beans, fulfill this purpose by specifying a general, server-side framework
for building distributed and secure components, which support
transactions out of the box.
So, you may ask, who provides all this distribution and security
infrastructure? The answer is vendors such as IBM and BEA. When
vendors indicate their compliance with the J2EE EJB specification, they are
signaling that they conform to the specifications.
EJBs fall into two very distinct categories:
●
●
Session beans. Think of these as beans that implement workflows
or processes (for example: making a hotel reservation, transferring
funds from one account to another, etc). These are by nature
transient activities. Once the task is complete, the bean has no
reason to exist.
Entity beans. These are object-oriented representations of
persistent data residing in relational databases (for example: a
representation of hotels in Seattle, a business's customers, your
bank accounts).
Each EJB has a remote interface as well as a home interface, as shown in
Figure 5. EJBObject and EJBHome implement these interfaces,
respectively. The client never actually interacts with the bean directly;
instead it calls methods on some objects that you, as the bean creator,
had nothing to do with.
Figure 5: The Enterprise JavaBean Interfaces
The primary purpose of the home interface is to provide a "factory"
interface for the EJBs. Clients use the home interface to address questions
such as how to locate an EJB, how to create an EJB, or how to delete an
EJB. For example, a client creates an EJB by using the home interface's
create methods. Remember that these are methods that the developer of
the EJB provided. The create() methods, of course, are not implemented
by the EJB. Instead, they simply correspond to "ejbCreate" methods in the
EJB itself, which get called in response to a create method call.
The remote interface covers everything else. It is implemented by the
EJBObject, which, in essence, wraps the EJB and knows all about
networking, transactions, security, and so on. EJBObject, through the
remote interface, exposes the business methods implemented by the bean
and delegates them when the business methods are invoked. The
EJBObject provides other services, such as a way to test whether two
EJBObjects are identical, identify the corresponding home object for the
EJBObject, etc.
What is the upside of such a complex architecture? Well, for one thing, it
means that no matter where the bean is located, the client doesn't need to
do anything differently. So you can easily change things without breaking
the application.
Second, it enables the container to intercept the requests so that it can
provide all those services that you get from your runtime environment. Do
you want only a certain group of people to access a specific business
method? No problem. If the deployer specifies security attributes at
deployment time, then, when the method is invoked, the container can
intercept it to make sure only the authorized people are trying to access it.
The same is true for transactions, persistence, etc.
Session Beans
As we mentioned earlier, a session bean exists to carry out a specific task
on your behalf. Think of it as an extension of a client program that
executes on the server side.
Now imagine that you are doing some bank transactions and using a
session bean. Would it make sense for the bean also to perform tasks on
behalf of another client who may be online at the same time? Obviously
not, because your account information, etc., is specific to you. So session
beans are typically private and cannot be shared. In essence, there is an
ongoing interaction strictly between you and the session bean, and it
maintains what is called "conversational state."
Typically, there is no persistence associated with your session, meaning
that if your session ends abruptly, it is usually not possible to recover and
continue on.
The EJB specification allows you to differentiate between the session beans
as either stateless or stateful.
●
●
Stateless session beans typically carry out "atomic" operations. That
is, the bean is asked to do something, and once the bean has
fulfilled that request, the conversation between the client and the
bean is over. A good example is a bean that implements a credit
card authorization. You enter a number, the bean obtains the
authorization, and it's done. Another party could then request
another credit card authorization, and a new session could be
started using the same bean. In other words, the container does
not save any value for the bean attributes during the session.
Stateful session beans are useful for more complex activities. These
beans remember things from one method call to another, so you
could call a bean repeatedly and continue your "conversation" or
session. For example, if you were to go shopping on the Net and
use a shopping cart to keep track of your purchases, a stateful
session bean could represent that.
Entity Beans
The other type of EJB is called an entity bean. Entity beans were actually
introduced in the first EJB spec, but the container providers were not
required to support entity beans. That changed with the EJB 1.1 spec, and
support for entity beans is now required for J2EE compliant application
servers.
Entity beans provide an object-oriented view of the persistent data in a
database. Things such as customer, employee, and account, as well as
things such as banks, tickets, and reservations, all map nicely to entity
beans, allowing you to work with objects rather than database records.
There are many advantages to using entity beans. For one, you can simply
call methods (e.g., mybean.setdestination()) instead of dealing with
obscure SQL queries. In addition, objectification allows you to reuse the
entity bean concept throughout your system consistently.
Since an entity bean refers to database records, it needs to be uniquely
identified. That's why you have a primary key for each entity bean. For
example, for an employee entity bean, the primary key may be the
employee ID.
From a user perspective, all the details of database access,
synchronization, and so on, are all taken care of, and things become much
simpler. For instance, the container ensures that the same method is not
called concurrently, unless explicitly specified by the bean provider.
Since entity beans deal with databases, there has to be coordination
between the two to keep things in sync. This process of coordination is
referred to as "persistence."
Two types of persistence schemes are available for entity beans.The
simpler one is called Container Managed Persistence (CMP). This is
attractive because, as a bean developer, you simply tell the container to
take care of things. You can have it take care of business logic, specify
how entity bean attributes map to fields in the database, and then sit back
and relax while the deployment utility actually generates all the SQL calls
at deployment time.
The nice thing is that, by using CMP, your entity bean doesn't have to
embed direct database queries. So it remains independent of the
database, and hence easily portable.
But say you want more control over how the persistence is handled (e.g.,
you want to do it more efficiently than the auto-generated code). In that
case, you can specify Bean Managed Persistence (BMP) and write all the
database access logic as part of your bean.
Of course, the disadvantage of bean-managed persistence is that you now
have to understand the database structure, know SQL, and do a lot more
coding, too!
Working with EJBs
In order to create an EJB, the first thing you need to do is find its home
object. You do this by using the "nickname" for the bean and querying the
Java Naming and Directory Service (JNDI), such as Novell NDS, LDAP, etc.
Once you have a reference to the home object, you can invoke a create
method on it. When a create is invoked on the home interface:
●
●
The EJBHome creates an instance of the EJBObject and gives it the
bean instance of the appropriate type to work with.
Once the bean instance is associated with the EJBObject, the
instance's ejbCreate() method is called.
❍
For entity beans, if a matching record already exists in the
database, then the entity bean is populated from it; otherwise,
a new record is inserted into the database.
❍
●
●
For session beans, the instance is simply initialized.
Upon completion of the ejbCreate() method, EJBHome returns a
remote reference for the EJBObject to the client. Remember that
since we are dealing with remote objects, a remote reference is
actually a stub.
The client can now call business methods on the stub. The stub
relays the methods to the EJBObject, which in turn delegates those
methods to the bean instance (of the class we created), and the
result is relayed back through the chain when the method returns
This sequence of events is shown graphically in Figure 6.
Figure 6: Using an EJB
(View full size graphic in new window)
Next Month: Servlets, JSPs, and Building
Better J2EE Applications with Rational Rose
We hope that we've given you a good basic understanding of the J2EE
architecture and its benefits, as we conclude Part I of this article with an
invitation to join us next month. In Part II, we will first take a look at how
servlets and JSPs work within the J2EE architecture. Then, we will discuss
in detail some of the ways you can harness the visual modeling power of
Rational Rose to build better J2EE applications. Please click here to go to
Part II!
For more information on the products or services discussed in
this article, please click here and follow the instructions
provided. Thank you!
Copyright Rational Software 2001 | Privacy/Legal Information