New York
University
Computer
Science Department
Courant
Institute of Mathematical Sciences
EJB
Application Servers
Course Title: Application Servers Course Number: g22.3033-011
Instructor: Jean-Claude Franchitti Session: 7
1. BEA WebLogic (Tengah)
Application Server
More
than 3500 rely on BEA's end-to-end e-commerce transaction platform.
A
suite of software solutions that enable a business to rapidly launch products
and services.
100%
focused on e-commerce transaction software, and everything we do is about
getting our customers to market faster.
BEA
software delivers transactions 24x7 so that customers can sustain a thriving
e-business with a reputation for maximum performance.
BEA's
complete e-commerce transaction platform includes:
·
E-commerce
application servers, BEA WebLogic
and BEA TUXEDO, for building,
deploying, and managing e-commerce applications and transactions. The BEA
WebLogic family delivers a proven e-commerce transaction platform for Web-based
solutions and applications built using distributed object technologies,
including Enterprise Java (J2EE) and CORBA. BEA TUXEDO is an e-commerce
transaction platform for distributed mission-critical applications.
·
BEA eLink for
integrating new and existing applications with front-office or back-office
systems, and with other businesses across the Web.
·
Reusable components
that enable business logic to be snapped together into applications within a
matter of weeks.
·
A wide range of
education, customer support, and professional services to help small companies
and large corporations get e-commerce initiatives off the ground and up on the
Web.
2. Bluestone Sapphire Application Server
Sapphire: An enterprise-level
application server which offers a high level of reliability in a distributed
setting
Bluestone
Software helped pioneer the application-server field, so it's not surprising
that its Sapphire/Web 6.1 product is still a leader in the market. And, if this
recent release is any indication if things to come, Bluestone may find itself
in a leadership position for a long time to come.
Sapphire/Web
is similar to SilverStream's application server, in
that it takes an integrated "development-platform-and-server" view of
what an app server should be. But while SilverStream specializes in taking HTML
and Java to their limits, Sapphire/Web lasers in on more sophisticated technologies,
giving users the choice between Java and C, and supporting a slew of standards
(including Enterprise JavaBeans, XML, COM, CORBA, and more).
Sapphire/Web's
development tools are quite strong -- which is no surprise, since it began life
mainly as a development tool. The ability to implement both Java and COM is a
great thing for those shops that haven't yet made a strategic (and often
costly) investment in either technology. The smart money says that JavaBeans
and COM will probably have to coexist in at least the near future -- allowing
for both, Sapphire/Web takes a logical approach.
On
the server side, Sapphire/Web 6.1 is surprisingly nimble, with both rule-based
and event-based load balancing and failover available in a multiserver
environment. In fact, it contains perhaps the best load-balancing and failover
technology that we've seen: Bluestone claims that its "Fast
Fail-over" technology delivers a 50 to 100 percent performance improvement
on start-up of Sapphire/UBS application servers, speeding the application
recovery time from 50 to 150 percent. In theory, end users should never see
performance degradation even when there is a hardware or software failure.
Plus, Sapphire/Web is scalable to the point where it can handle upwards of
millions of simultaneous users.
Sapphire/Web
is actually the sum of the following components:
·
Sapphire/Universal
Business Server (UBS) -- features the aforementioned load balancing and
failover, as well as state management and application process isolation.
·
Sapphire/Developer --
features the aforementioned application builder, which includes a Java-based
GUI, source-code control, an interface builder and support for JDBC, XML,
Microsoft Active Server Pages (ASP), dynamic HTML, cascading style sheets
(CSS), and DHTML.
·
Sapphire/Application
Manager (SAM) -- controls application deployment and transactions.
·
Sapphire/Integration
Modules (SIMs) -- data-integration modules that connect UBS to a wide range of
environments, including COM/DCOM, Enterprise JavaBeans, PeopleSoft, CICS,
CORBA, MQ, MTX, Tuxedo, Gradient WebCrusader and LDAP directories. Future
integration with ERP products from the likes of SAP are promised for the
future.
Sapphire/Web
can be deployed in almost any environment, as Sun Solaris, Windows NT, HP-UX,
Digital UNIX, OS/390, IRIX, AS/400, AIX versions are available.
There's native support for Oracle, Informix, Microsoft SQL Server, Sybase, and DB2 databases, with additional support for any JDBC or ODBC database. Finally, Sapphire/Web will work with any Web server, including the Apache HTTP Server and the Netscape family of Web servers.
Sapphire/Web
6.1 comes close to fulfilling the promise of object-oriented programming:
instead of descending to the code level for your programming, you can implement
reusable objects, both menial and indispensable, to create applications and
save making the choice for the final format (C or Java) until the time of
deployment. And with a server that contains load balancing and failover,
Sapphire/Web is a complete package that should be strongly considered when
looking at an application server for the enterprise.
Pros: · Open approach to development (supporting both C
and Java), · Advanced load balancing and failover, · Native support for wide
range of databases
Cons: · Management tools are rough (difficult to get
used to)
3.
Evaluating Enterprise JavaBean Application Servers
Reference Architecture
EJB is a business component standard. The reason developers desire such a standard is so they can avoid locking themselves into one vendor's implementation. A primary element of the vision for EJB is to give developers the comfort of a single development paradigm with the flexibility to deploy different applications on top of different application server products.
At
deployment time, developers could choose which vendor's product to use based on
the particular characteristics of the application. Of course, taking advantage
of such flexibility requires making a comparative decision among alternative
products. There are many different EJB application server products. There are
often profound differences between two products. At a very detailed level, they
may seem to have little in common. However, making a decision among products
requires a common basis for comparison. Figure Eval-1 presents a reference
architecture that will serve as the basis for comparison throughout this
section.
Figure Eval-1 - Application Server
Reference Architecture
As
Figure Eval-1 shows, the reference architecture has two primary features: (1)
horizontal connectivity layers and (2) vertical services. At some level of
abstraction, all EJB application servers share this architecture. The client
connectivity layer provides the client connection management and request
dispatch mechanisms to service one or more different types of clients. The
business logic execution layer provides the interfaces necessary to execute
EJBs and other business components. The data source connectivity layer provides
the facilities to access data stored in databases, packaged applications, and
legacy applications.
In
addition to the relatively distinct responsibilities of each connectivity
layer, there are services that transcend all three layers. Distributed
application require end-to-end transaction management services: from client
demarcation, to application object propagation, to coordinated backend commit.
They also require end-to-end security: from client authentication, to access
control on business logic components, to database authentication. Managing the
efficient execution of an application server requires integrated management
across the connectivity layers: from the number of allowable client connections,
to the business logic available on each server, to the database connections
available.
Evaluation Parameters
In
evaluating alternative EJB application servers, the reference architecture
provides the points of comparison. For a particular application, developers can
compare that application's requirements to what different vendors offer at each
horizontal connectivity layer and for each vertical service.
Client Connectivity
There
are two important considerations for evaluating client connectivity: (1) does
the product provide connectivity to the necessary clients and (2) will it scale
to support the number of clients expected. The first consideration is easy to
evaluate because vendors make it clear what they support. For Java clients,
some products support RMI while others CORBA. Some support both. From the
developer's point of view, it should not matter much whether a product supports
Java RMI or Java CORBA clients, as long as it generates the appropriate client
stubs. In both cases, client developers simply call the stubs and the runtime
library takes care of the rest. If developers also want to support C++ clients,
CORBA support is a necessity.
Beyond
Java and C++ clients, there are Web and COM clients. Through Java servlets, all
EJB application servers can support Web clients. The servlet simply becomes the
Java client and brokers communication between browsers and the application
server. All products that support CORBA can support Web clients using Netscape
Enterprise Web Server because it includes a built-in ORB. Beyond these standard
mechanisms, some products may offer additional capabilities like frameworks for
managing browser client state. For COM clients, the situation is similar.
Through Java-COM or CORBA-COM bridging products, all EJB application servers
can support COM clients. However, this approach often requires purchasing a
third-party product and integrating it into the deployment architecture. Some
products may support COM directly.
After
verifying that a product supports the types of clients in the application, the
next major consideration is whether the product can support the number of
clients expected. There are three basic strategies to supplying this
scalability:
|
Protocol
efficiency. Suppose a client calls a remote method that returns a reference
to a collection of objects. As the client iterates through the collection, it
will generate a remote method call during each iteration. Such calls are
expensive. A more efficient approach is for the server to send a block of
objects to the client at the same time. There are several different means to
this end, but they can all yield improved performance in situations where
clients iterate through collections of remote objects. |
|
Dispatch
efficiency. When the application server receives a client request, it must
dispatch the resources necessary to fulfill the request. There are several
different resource management models. One is to spawn a new thread for each
request. Another is to maintain a pool of worker threads and assign an
incoming request to an available thread, queuing it if there are no available
threads. An even more complex model is to have a pool of running processes,
each of which has a pool of threads. The relative efficiency of these models
depends on the cost of thread startup, thread synchronization, and process
startup, all of which differ from OS to OS. |
|
Server
clustering. If a server's response time degrades as the number of client
requests increases, an obvious solution is to have more than one server. This
approach is called "clustering" and requires a mechanism for
distributing client requests across available servers. This mechanism can be
part of the directory server or a separate process. In either case, this load
balancing mechanism can use different algorithms for distributing requests.
The simplest is round-robin. More complex ones take into account the actual
system load of the available servers. |
The
necessity for the above mechanisms depends on client loads and server platform.
An application running on a four-processor Unix server with a hundred clients
performing simple operations over a dedicated 100Mb/sec network probably
doesn't require any of these optimizations. However, an application running on
eight four-processor Unix servers with ten thousand clients performing complex
operations over a heavily loaded 10MB/sec network would probably require all of
them.
Business Logic Execution
The
primary consideration for business logic execution is whether the product
executes the types of business logic required by the application. Given that
every product must run the business logic on the same platform using the same
VM or compilation technology, there is not much opportunity to optimize the
execution speed. As discussed in the previous chapter there are two types of
EJBs, Session Beans and Entity Beans. Entity Bean support in EJB application
servers is optional in the 1.0 version of the specification. Whether Entity
Bean support is important depends on the development style of the organization.
Organizations that like to assemble fine-grained autonomous objects into
large-grained services will want to use Entity Beans. Organizations that want
completely self-contained services should be happy with Session Beans alone.
Beyond
EJBs, developers may have existing business logic that they want to integrate
into the EJB application. This logic may include freestanding Java and C++
classes as well as CORBA and COM/DCOM objects. Some products support some or
all of these alternative business logic types.
Data Source Connectivity
There
are three important considerations for evaluating data source connectivity: (1)
does the product provide connectivity to the data sources developers want
access, (2) does it provide features to improve scalability of database access,
and (3) does it provide features that reduce the development effort required to
deploy data-aware applications. For bean-managed persistence, developers are
free to install their own JDBC drivers so they can access any data source for
which such a driver is available. For container-managed persistence, the
application server's container manages data access so it must explicitly
include support for each data source developers want to access.
After
verifying that a product supports the necessary data sources, the next major
consideration is whether the product has performance features that match the
application's data access pattern. There are three basic strategies to
improving data access performance:
|
Connection pooling. It is expensive to initiate a new database
connection. To avoid this startup cost, an application server can maintain a
number of open connections and then assign an incoming data request to an
available connection, queuing it if no connections are available. This
approach is highly efficient if an application accesses data sources
frequently. If the access is infrequent, the overhead of maintaining unused
connections may outweigh the time saved from connection startup. |
|
Request
multiplexing. The application server can package multiple small requests into
a single large request. This approach can reduce the overhead associated with
making a request, even with a live database connection. It is only beneficial
if the application makes many small data requests. |
|
Caching.
Making a call to a data source incurs at least the cost of a network call and
possibly the cost of a disk access. To avoid these costs, an application
server may cache data from the database. The first time the application
server requests the data, it incurs all network and disk costs. However,
there is almost no cost for subsequent accesses because the data resides in
the application server's own cache. There are many different types of caching
and caching strategies. The suitability of a particular approach depends on
the application. However, all caching depends on the application asking for
the same data more than once. If such repeated use rarely occurs, the
overhead of caching the data is wasted. |
The
last criterion for evaluating data source connectivity is ease-of-development.
EJB's primary innovation in this area is container-managed persistence. In this
model, the EJB delegates data access to the container, eliminating altogether
the need to write data access code. It is only available with Entity Beans.
When using container-managed persistence, there are important issues to
consider. Perhaps the most important is how the application server handles
object-relational mapping. In most cases, the container needs direction from
the developer on how to map relational to EJB objects. It may use a direct
object storage mechanism and not require object-relational mapping. It may
include its own object-relational mapping tool. It may integrate with
third-party object-relational tools. Direct object storage is probably easiest
for the developer, but the necessary data may reside in a relational database,
eliminating this option. An integrated mapping tool eliminates potential
product integration problems but may subtly lock the developer into the product
by generating non-portable mapping information. A third-party mapping tool
avoids lock-in, but may cause headaches in the integration process. Moreover,
the benefit of portable mapping information extends only to those application
server products supported by the mapping tool vendor.
In
some cases, an application server may not allow an object to have attributes
mapped to columns in different databases. This restriction could increase development
time by requiring developers to partition their persistent objects so each
includes only data from a single database. This problem could be very subtle.
An application server may actually allow mapping an object's attributes to
columns in different databases but then fail to support the two-phase commit
necessary to maintain the consistency of the two databases. So even though it
is possible to declare such mappings, they aren't truly viable in a
transactional application.
Transaction
All
EJB application servers are supposed to support the JTA and/or OTS client
transaction demarcation APIs. They are also supposed to support the JTS/OTS
standard for propagating client-demarcated transactions to the application
server objects that participate in the fulfillment of the client request. The
primary point of differentiation comes once a transaction context propagates
beyond the vendor's product. There are two issues: interoperability with other
middle tier JTS/OTS implementations and propagation of transactions to data
sources. The first issue is rather simple. Will the product interoperate with
other JTS/OTS implementations? Some vendors have tested their solutions to
verify interoperability. Other vendors have built their product to be
interoperable, but have not tested it. Some make no claims to interoperability.
Of course, interoperability is only important if developers plan to integrate
products from different vendors into a single application execution
environment.
The
more complex issue is the propagation of transactions to data sources. If a
transaction involves creating or modifying an object with persistent state, the
application server must propagate client commit and rollback directives to the
data sources that maintain the persistent state. The problem comes when a
transaction involves a single object with state maintained in more than one
data source or when a transaction involves multiple objects whose collective
state spans more than one data source. To preserve transaction semantics, the commit
or rollback must occur simultaneously for all data sources. The typical
approach is to have a two-phase commit. Different products have varying degrees
of support for two-phase commit, including:
|
No
support. In this case, there is no way to initiate a two-phase commit from
the application server. Therefore, developers must limit the data access of
the application so that each transaction involves only one data source. |
|
Transaction
resource. In this case, the application server supports an OTS or XA resource
interface, meaning that it can participate in, but not drive two-phase commit
transactions. However, if every data source also has an OTS or XA resource
interface and there is an external object transaction monitor (OTM) or
transaction process monitor (TPM), the application server can delegate the
coordination of the two-phase commit to this external monitor. |
|
Transaction
coordinator. In this case, the application server can coordinate two-phase
commits for OTS or XA resources. If it is an OTS coordinator, all the data
sources must have OTS resource interfaces. If it is an XA coordinator, all
the data sources must have XA resource interfaces. This feature is the
highest level of distributed transaction support available and is crucial in
highly heterogeneous database environments. |
It
is often hard to distinguish between transaction resource support and
transaction coordinator support from reading product specifications. Typically,
these specifications refer to support for the OTS or XA standard without
detailing the level of support. Resource support requires an external monitor
for two-phase commit transactions. Coordinator support does not.
Security
Application
servers offer a wide variety of security features. The necessity of a given
feature depends on the deployment topology and the application's inherent
security requirements. For example, an application that runs entirely behind a
corporate firewall and does not involve the execution of high-value functions
probably needs only standard user name and password authentication. An
application that runs outside the firewall definitely needs encryption of the
user name and password to prevent "packet sniffing" of these
credentials. An application that runs outside the firewall and involves the
execution of high-value functions like executing financial transactions or
committing to the manufacture of valuable items probably requires public-key
certificate authentication.
Some
applications may involve simply submitting instructions and receiving
confirmation. In most cases, the data exchanged is not terribly valuable. In
other cases, data like account balances, manufacturing schedules, and medical
information needs to remain confidential. In these cases, developers will want
an application server that provides encryption of the data. For such data,
encryption between client and server is always necessary. However, it may also
be necessary between two servers. Many applications may involve EJBs in one
server calling EJBs in another server. Unless both servers are in the same
secured physical facility, they must also encrypt sensitive data exchanges.
In
addition to providing authentication and encryption, application servers may
also include access controls. When a client attempts to access an EJB or invoke
a particular method, the application server must compare the user identity to
an access control list (ACL) specifying who may perform what operations. The
user identity is bound to the authentication credentials. The ACL is supplied
at deployment time. Some servers may choose to restrict access at the EJB
level. Others may choose to restrict access at the level of individual methods.
The EJB 1.0 specification itself requires method-level access control.
Management
The
point of EJB is to provide a standard model for deploying distributed
applications. Because distributed applications often have many components, they
pose a management challenge. This challenge has three main facets: deployment
configuration, runtime monitoring, and runtime management. When deploying EJBs,
a development tool creates the ejb-jar file. However, multiple application
servers may execute the same EJB. Therefore, developers have to manage the
distribution of the ejb-jar file and the configuration of its environment
properties component for each target server machine. Some products may include
tools for automating this process and updating servers to new versions of EJBs.
In many cases, client software updates will occur in parallel to EJB component
updates. To simplify this process, some products also provide tools for
automatically updating clients.
After
deployment, there are runtime management issues. These include monitoring and
management. Monitoring involves each server publishing information about its
status to a central console. Typical monitoring information includes system
statistics like CPU, memory, and I/O utilization as well as EJB-specific
satistics like number of client sessions, number of threads, and garbage
collection performance. Management involves dynamically changing execution
parameters and access control restrictions. Typical execution parameters
include number of threads in a pool, cache size, and number of connections in a
database pool. Some organizations prefer to centralize the management of all
resources in one place, including desktop clients, application servers,
database servers, etc. These organization should look for products that provide
Simple Network Management Protocol (SNMP) agents so administrators can perform
application server monitoring and configuration from standard consoles.
Conclusion
EJB
application servers are sophisticated pieces of software and differ
significantly in the types of connectivity they support and the quality of
services they offer. The optimal product will differ depending on application
requirements. In many cases, an application may see a significant performance
or quality of service boost by using a particular product, making it imperative
that developers attempt to choose the best EJB application server for a
particular job.