Pramati Server 2.5 and Pramati Studio 2.5
A server and a studio
by Rick Grehan

Pramati is a late entry in the Java application server arena. That delayed entry is the result of what Jay Raghavendra Pullur, the company's founder and CEO, describes as a "studied approach" to the Java application server marketplace. Because the company is based in India, it has been difficult for Pramati to be active in the U.S. market. According to Pullur, Pramati has bided its time, operating in what he describes as "stealth mode," building a powerful product base, waiting for the right time. That time has apparently come.

And what makes this the right time? According to Pullur, back in '98, when the company was in its infancy and the application server market was crowded, Pullur estimated there were as many as 50 application server companies. "Now," he says, "the number of players has reduced significantly. There are maybe a dozen players or less; and half of them are not doing well." Pramati obviously thinks that it can make a splash in the shallow and struggling waters of the application server marketplace.

Whether or not now is the right time remains to be seen. What can be said is that the Pramati Server is a remarkably robust offering for one so fresh to the field. And Pramati Server is made even more impressive by the accompanying Pramati Studio; a surprisingly complete development and deployment environment for Java Web and application components.

The Power of Nodes
Pramati Server's architecture is its distinguishing characteristic. The Pramati Server was built from the ground up as a distributed system. A server installation consists of one or more independent but cooperating execution components called "nodes." The nodes that make up a system are, as a group, referred to as "a cluster." A node provides either a Web server, an Enterprise JavaBean (EJB) container, or both (in which case it is referred to as a "compound node").

Figure 1. Studio and Server

Pramati documentation prides itself on the fact that the server's node structure is entirely transparent to applications. In fact, Pramati describes the set of nodes that comprise a system as being "self organizing." That designation refers to the fact that nodes can enter and exit a cluster in any sequence and at any time without affecting the cluster's performance. One node is arbitrarily designated as a master node (referred to as the "assumed master"), and that master coordinates alterations in the cluster. Should the master node exit the cluster, another node takes over its duties. All of this takes place without any administrator intervention.

Pramati's node architecture provides the underpinning for the system's load balancing and failover capabilities.

The system's load-balancing heart beats in its naming service. When an application makes a request to the naming service, a pluggable load-balancing algorithm informs the service which container (or which node) is to be used to satisfy the request. Pramati supports several built-in load-balancing algorithms: round robin, weighted round robin, and dynamic load factoring. Pramati has also made the API available so that developers can add custom load-balancing algorithms to the server.

Failover is as transparent as the system's node architecture. All calls to an EJB pass through a stub to the EJB's home object. The Pramati system inserts a transparent layer in that stub, so that calls to the EJB necessarily pass through that layer. Should the EJB fail at some point, the transparent failover layer detects the failure, and takes appropriate action. In almost all cases, that action will be to route future calls to a newly instantiated version of the bean (whose state, if necessary, has been invisibly initialized to the state of the deceased EJB).

System management is provided by the Server Management Console GUI, which allows control of the application server and message server. The Console also has a built-in deployment tool for hot deployment of EJB and Web components on both local and remote servers. (Also included is a Query Designer, which, although welcome, seems a bit out of place in a management tool.) Administrators can take the pulse of various system resources—currently deployed beans in the EJB container, currently deployed servlets and JavaServer Pages (JSP) in the Web container, the state of current transactions, and so on—all in real time.

Studio
Pramati Studio is a complete IDE for the creation, debugging, and deployment of Java applications, Web components, and EJBs. It includes an integrated version of Pramati Server (version 2.5; though without some of the bells and whistles—like the Management Console), providing developers with a complete playground for testing their Java components in an actual application server runtime environment. In addition, Studio provides the CloudScape embedded database, as well as the CloudView GUI database client application. In short, you have everything you need to build and run Java components. (Programmers interested in trying out Studio—and, because of its inclusion in Studio, Pramati Server—can download a 30-day trial edition of Pramati Studio 2.5 from Pramati's Web site at www.pramati.com.)

Pramati Studio's Express Development mode provides rapid application development (RAD) features by keeping a project target ready to deploy at all times. Studio understands, for example, that when you've added a method to an EJB, the EJB's interface definitions need to be modified, that files must be recompiled, that deployment descriptors must be rewritten, and so on. To the extent that it can, Studio automates all of the changes that must be made. Add that method to that EJB, and when you choose to recompile the source, Studio will rewrite interface definitions, recompile all the source, rebuild deployment descriptors, and repackage the archive file—ready to redeploy. (The same is true of Web components. Make a change to a JSP page and all the work necessary to make the new JSP page deployable is done automatically.)

Pramati Studio's desk is, in the simple sense, a project space; a physical view of the project (see Figure 1). A developer sees the desk as an expandable and collapsable tree, consisting of folders (branches) and target components (leaves). However, the desk goes beyond simply mapping physical files to logical components. For example, in the event that multiple EJBs share a following class, a desk can easily be configured so that the multiple EJBs reference the class's originating Java source file. And, if the source for the class is altered and the class rebuilt, all EJBs that depend on the class are resynchronized, so that the changes appear in the EJB modules. In addition, a developer's desk can be saved in an easily ported archive. This is particularly handy if a developer wants to move his entire project structure from one system to another. A developer can save the desk to an archive, move it to another machine, unpack it, and be confident that he or she has not forgotten this source component or that configuration file.

Finally, Studio's built-in debugger easily handles all Java server components. In addition, the debugger copes well with an executing program's transition from one component type to another. Debug a JSP page, and if the page calls into an EJB, the debugger will transition into the EJB. (Even better, you can debug the JSP page in its JSP form—you are not forced to debug the JSP page in its servlet incarnation.) This ability to step from one component to another is not limited to a single machine; in the previous case, even if the JSP page were on one machine and the EJB on another, the debugger deals with the transition as easily as if the application were on a single machine.

Standard Yet Special
Pramati Server's support of the J2EE standards is about as complete as you could hope for. The server's EJB container supports EJB 1.1 (and will probably have EJB 2.0 support by the time you read this). Other standards it supports include JSP 1.1 and Servlet 2.2, JMS 1.0.2, JTA 1.0, JDBC 2.0, JAAS 1.0, and JavaMail 1.1.

While fully bedecked with standards, Pramati Server nonetheless provides several performance-boosting features. The system sports the standard database and connection pooling as well as caching of entity bean instances. Pramati Server also provides a cache of prepared SQL statements (precompiled SQL that does not have to pass through an interpretation phase). Another performance enhancement is derived from Pramati's "pseudo-RMI" layer. This speeds the communication between EJBs on the same EJB container by bypassing the need to use network resources (for example, TCP IP connections) when one EJB calls another in the same container.

Currently, only an Enterprise version of Pramati Server exists. The cost is $8,000 per CPU. Pramati expects that sometime in the future (I was told two to three months at the time of this writing) a "smaller" and lower-priced standard edition would be available; such an edition would likely include only the JSP and EJB portions of the server. Pramati Studio is priced at $995 per seat. This price includes Studio's integrated application server, as well as the CloudScape database and CloudView client tool.

The Pramati Server can run on Windows NT, Solaris, and RedHat Linux; all require either JDK 1.2.2 or JDK 1.3. Database support includes Oracle 8i, Informix 7.3.0, and CloudScape. (Check with Pramati for information on other database support.) Pramati Studio requires JDK 1.3 (or JDK 1.2.2 with JPDA), and at least 64 MB of RAM (though 128 MB is recommended). It's not large, taking only 30 MB of disk space.

Future versions of Pramati will provide an EJB designer as well as an incorporated UML wizard. The EJB designer will be available in the 3.0 release of the server (which should be out by the time you read this). Preview information for the 3.0 version of Pramati Studio also touts its support for the EJB 2.0 standard. It will be interesting to see if this late entry in the application space is strong enough to muscle other better-established offerings out of the ring.

About the Author
Rick Grehan is a technical evangelist with Compuware/NuMega. Rick was a senior editor at BYTE magazine (where he wrote the JavaTalk column) and at Computer Design magazine. He can be reached at .