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.