Architecture of distributed and Web applications

How it works

In a distributed or Web application that uses Java and EJB Server together, a Java client accesses the EJB Server, which in turn accesses a database.

About the distributed architecture

In the distributed architecture, the client is a Java application rather than an applet. The application and Java VM need to be installed on the user’s machine and the application files made accessible to the Java VM.

About the Web architecture

A Web application is a variation on the distributed architecture where the client is a Java applet hosted in a Web browser.

About the Web client The browser handles communication with a Web server via the HTTP protocol. The Web page that contains the applet and the applet itself are downloaded via HTTP. The applet then runs in the Web browser but bypasses the Web connection and communicates directly with the EJB Server. Connecting directly to EJB Server enables persistent connections with the client and avoids the problems with stateless HTTP.

A major advantage of the Web architecture is that the client applet is downloaded when the Web page is requested. You don’t have to worry about deployment to individual users.

The main disadvantage of the Web architecture is that an applet must be downloaded each time it is run, and unless it is marked as trusted, cannot provide full application services, such as accessing other files, running other programs, or making native calls.

EJB Server as Web server EJB Server can fill the role of Web server using the HTTP protocol, as well as provide support for IIOP connections that invoke the services of the EJB Server transaction server.

Creating a distributed or Web application

The general procedure for using PowerJ to create a distributed or Web Java application that uses EJB Server is:

  1. Decide what functionality will be encapsulated in an EJB Server component. Typically, the component implements business logic that analyzes data, performs computations, or retrieves and processes data from the database.

  2. In PowerJ, write the code for the component. In addition to implementing the component’s business logic, you may also call EJB Server methods to take advantage of transactions and other EJB Server performance features (information about these features follows).

  3. In PowerJ or the Adaptive Server plug-in to Sybase Central, define connection caches to manage pools of connections to the remote databases that your component connects to.

  4. In PowerJ, set the deployment options for your component, including transaction management, instance pooling, and timeout settings.

  5. In PowerJ, deploy the component to EJB Server. This automatically creates CORBA skeletons for your component, and optionally adds a proxy to the PowerJ component palette.

  6. In PowerJ, create the client, which can be a Java application or applet. Add the proxy object and PowerJ InitialContext object to your client, and you can access your component’s methods as easily as if the component were available locally. The InitialContext object takes care of connecting to your EJB Server component and initializing the proxy.

    Information about building client applications and applets is in “Building a Java client for a distributed or Web application”.