Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Mastering Enterprise JavaBeans™ and the Java 2 Platform, Enterprise Edition - Roman E

..pdf
Скачиваний:
41
Добавлен:
24.05.2014
Размер:
6.28 Mб
Скачать

676 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Intelligent Load Balancing

A common deployment scenario involves a heterogeneous set of machines, all working together to provide an n-tier solution. Each machine may have different resources to offer, such as more memory or a greater number of processors. We’d like to leverage these resources as much as possible in our deployments.

The traditional way to service requests is to load-balance requests in an even, distributed fashion between machines, using a round-robin scheme. This method has the advantage of simplicity, and it works well for a homogenous set of application servers. But when heterogeneous resources are involved, even distribution does not make best use of the resources—intelligent load balancing does.

An intelligent active load-balancer tracks information about the load of each application server providing services. As a machine becomes bogged down, the load-balancer intelligently routes requests to other machines as needed. This maximizes your available resources.

Yet another option is weighted round-robin, which assigns weights to different machines based upon their capacity. This typically works better than an active load-sensitive balancer because it’s a much more lightweight implementation.

Secant and IBM are examples of vendors that provide these high-end loadbalancing schemes.

Stateless Transparent Fail-over

When your application server crashes, there should be a transparent re-routing of all requests to a different application server. The natural place to put this process is in intelligent client-side proxies, which intercept all network-related problems and retry methods on alternative application servers, or in the object request broker runtime. Transparent fail-over is fairly easy to implement if you restrict the client to invoke only on a stateless server, and assume that all transactional resource updates can be rolled back.

Clustering

A more advanced level of transparent fail-over is stateful transparent fail-over or clustering. With clustering, your application server is replicating conversational state across servers. If an application server crashes, another server can pick up the pieces since it has replicated state. If your application server supports clustering both for Web components (servlets, JSP scripts) as well as clustering

Go back to the first page for a quick link to buy this book online!

Making a Purchase Decision 677

for enterprise beans, then you can completely eliminate single points of failure from your deployment, ensuring uninterrupted business processes.

Clean Shutdown

What happens when you want to take down an application server for maintenance? Perhaps you want to reboot the machine the application server is installed on, upgrade the application server, or install software on the machine. But if you simply kill the process, any connected clients’ work would be lost, potentially resulting in financial errors or other catastrophes.

This leads to another area of value that EJB products can provide: a clean way to shut the application server down without having a gross impact on clients. For example, the EJB application server may simply have a routine that refuses connections from new clients, and allows for all existing clients to gracefully disconnect.

Real-time Deployment

Starting up and shutting down an EJB application server is usually a fairly heavyweight operation. If you’re debugging an EJB application, having to restart the EJB application server each time you regenerate your beans is a hassle. Having to shut down an application server in order to deploy new beans has an even greater impact, since that application server cannot service clients when it is down.

An enhanced value that some EJB products can provide above and beyond the EJB specification is a mechanism for deploying enterprise beans in real time. This means the ability to deploy and re-deploy beans without shutting down a running application server.

Distributed Transactions

In Chapter 10, we examined transactions in depth, and noted how multiple processes on different physical machines could participate in one large transaction. This is known as a distributed transaction, and it is a fairly heavyweight operation. It necessitates the use of the distributed two-phase commit protocol, a reliable but cumbersome dance that transaction participants must take part in for a distributed transaction to succeed.

If you require distributed transactions, make sure your EJB server supports them. For a two-phase commit transaction to work, you also need to have the same transaction service deployed on all participant machines, or have interoperable

Go back to the first page for a quick link to buy this book online!

678 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

transaction services (which don’t exist yet). Note that very few percent of deployed transactional systems actually employ distributed transactions today.

Existing Enterprise System Integration

Integration with existing enterprise information systems (such as ERP systems) will not be portable until EJB 2.0 and the EJB connector specification. With EJB connectors, the legacy vendor will ship a connector that runs in any application server product. But until then, you may want to look to your application server vendor for some help. Netscape’s application server, for instance, provides integration aid for both SAP and Peoplesoft ERP systems.

Asynchronous Messaging Support

Although neither EJB 1.0 nor EJB 1.1 support asynchronous messaging via the Java Message Service (JMS), asynchronous communications are still necessary for many scalable multi-tier deployments. With asynchronous messaging, you can subscribe to distributed messaging events, have guaranteed message delivery, and perform non-blocking operations. If your distributed system architecture requires asynchronous messaging, then that should be part of your selection criteria for choosing an application server product.

Integration with Bean Providers

Already there are a few bean providers spawning in the EJB marketplace, such as The Theory Center, recently aquired by BEA Systems, Inc. (www.beasys.com), and Xenosys (www.livebiz.com). These bean providers give you prebuilt components that you can customize and re-use in your own deployments, saving you development time.

If you plan on using a third-party bean provider’s product, you should ask your application server vendor if they have a partnership with that bean provider. If they don’t, then the beans will most likely not run in your vendor’s product due to portability issues.

Specialized Services

There are numerous other features that EJB vendors provide to differentiate their products. Some of these features do not impact your code at all. For instance,

Go back to the first page for a quick link to buy this book online!

Making a Purchase Decision 679

your bean code should always remain the same no matter what load-balancing scheme your application server uses. Other features may require explicit coding on your part, such as ERP integration. When choosing a product, ask yourself how much explicit coding you would need to write to a particular vendor’s proprietary API. The more of these APIs you use, the less portable your EJB code becomes.

Some examples of special features offered in EJB products are:

■■BEA’s WebLogic has an optimized mechanism for pooling and reusing sockets in their own custom RMI implementation.

■■Oracle’s Oracle 8i EJB Application Server runs on Oracle’s own JVM, which adds enhanced garbage collection and native compilation.

■■IBM’s WebSphere application server adds systems management integration to professional monitoring tools, such as Tivoli and Computer Associates monitoring tools. IBM also has a well-defined migration path for CICS customers to move to EJB.

As you can see, the emergence of these services becomes one of the chief advantages of EJB as a competitive playing field that encourages vendors to provide unique qualities of service.

Non-Technical Criteria

There are a host of non-technical criteria that you should consider as well, such as:

Reputable vendor. Does the vendor have a brand name and a history of distributed transaction processing systems? How large is the firm? How many years have they been in operation?

High-quality technical support available after hours. If a crisis situation ensues in the middle of the night, will your vendor be available to resolve problems?

Verifiable customer success stories. Look for large, well-known (ideally Fortune 500) companies implementing solutions with the vendor’s product. Don’t hesitate to ask tough questions to get beyond the marketing hype.

Training and consulting services available. The company should have their own internal training and consulting services or should have partnerships with other firms to provide those services to you. Be sure that the vendor’s training/consulting department is adequately staffed to provide the care you need, and that the vendor is not overburdened with other projects.

Free evaluation copy. Any deserving vendor should let you evaluate their product free-of-charge for either a limited time period, or as a stripped-down product version. Otherwise, rule that vendor out immediately.

Go back to the first page for a quick link to buy this book online!

680 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Summary

In this appendix, you’ve surveyed the criteria for making an EJB application server purchase decision. The EJB specifications (as well as the products that implement it) are evolving rapidly. The features offered in the marketplace are likely to change over time. For the latest information about EJB products and news, check out the following resources:

Online white papers. Some research firms offer white paper reviews they have performed on EJB products. See the book’s accompanying Web site for links to these white papers.

The Sun Microsystems Web site. The EJB homepage has an EJB Directory of current EJB products with links to vendor information. This directory is likely to evolve greatly over time. For a link to this, see the book’s accompanying Web site at www.wiley.com/compbooks/roman.

Magazine article reviews. Some Java-based, printed magazines offer comparisons of EJB products as well. Examples here include Java Report, Java Developer’s Journal, and JavaPro.

Third-party Web sites. Examples here include www.develop.com, www.jc100

.com, and www.builder.com. See the book’s accompanying Web site for links to these and other sites.

Go back to the first page for a quick link to buy this book online!

A P P E N D I XF

EJB Quick Reference Guide

his appendix is a quick reference for programmers to use during EJB develop- Tment. In the first section of this appendix, you’ll find diagrams illustrating what’s really going on in an EJB system. These diagrams were taken directly from the EJB specification; I’ve condensed the diagrams and commented them to clarify their meaning. You’ll also find summaries and explanations of each method in

the EJB architecture, as well as a transaction reference.

681

Go back to the first page for a quick link to buy this book online!

682 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Session Bean Diagrams

EJB object does not exist

No client reference to EJB object

client releases reference

client calls

home.create(...)

container crash or client timeout

handle.getEJBObject()

EJB object exists

No client reference to EJB object

client releases reference

if a client calls a method, a NoSuchObject exception will be thrown

EJB object does not exist Client holds reference to EJB object

client calls ejbObject.remove() client calls home.remove(...), system exception in bean, bean timeout,

or container crash

EJB object exists

Client holds reference to EJB object

client can call business methods

Figure F.1 The client’s view of a session bean object lifecycle.

Go back to the first page for a quick link to buy this book online!

EJB Quick Reference Guide 683

Stateless Session Bean Diagrams

Container decided it needs more instances in the pool to service clients

bean instance does not exist

 

 

 

 

 

 

1: Class.newInstance()

 

ejbRemove()

Container decided it

2: setSessionContext()

 

 

 

doesn't need so many

 

 

 

3: ejbCreate()

 

 

 

instances anymore

 

 

 

 

 

 

 

 

 

 

 

 

Business Method

pool of equivalent method-ready instances

Any client calls a business method on any EJB object

Figure F.2 The lifecycle of a stateless session bean. Each method call shown is an invocation from the container to the bean instance.

Go back to the first page for a quick link to buy this book online!

684 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Client

 

Container

 

Bean Instance

 

Database

 

 

 

 

 

 

 

beanClass.newInstance()

setSessionContext()

ejbCreate()

Adding a new instance to the pool

home.create()

return new EJB object

Servicing a create method

ejbObject.businessMethod(args)

businessMethod(args)

read or update data

register resource manager with transaction

Servicing a business method

ejbObject.remove() or home.remove(...)

Servicing a remove method

ejbRemove()

Removing an instance from the pool

Figure F.3 Sequence diagram for stateless session beans. For simplicity, the Container object represents all container subsystems, including EJB objects, home objects, transaction services, and so on.

Go back to the first page for a quick link to buy this book online!

EJB Quick Reference Guide 685

Stateful Session Bean Diagrams

Client called

create(...) on the

bean instance does not

home interface

exist

1:Class.newInstance() ejbRemove()

2:setSessionContext()

3:ejbCreate(...)

Business Method

 

ready

 

 

 

Client called remove() on the EJB object

or

client times out

Client times out

ejbPassivate()

ejbActivate()

Container's limit of instantiated beans is reached, so it must swap your bean out

passive

Client called a business method

on the EJB object

Client called a method on a passivated bean, so container must swap your bean back in

Figure F.4 The lifecycle of a stateful session bean (does not implement javax.ejb

.SessionSynchronization). Each method call shown is an invocation from the container to the bean instance.

Go back to the first page for a quick link to buy this book online!