Deploying Cloudscape Applications
Page 2 of 4

Deployment Issues

This section discusses deployment options and details.

Deployment Options

Cloudscape has two basic deployment environments: embedded and client/server.

Embedded Deployment Application Overview

In an embedded environment, Cloudscape runs in the same JVM as the application. Depending on the Cloudscape deployment license that you purchase, the application can be a single-user application or a multi-user application server. In the latter case, Cloudscape runs embedded in the user-provided server framework, and any client applications use user-provided connectivity or allow the application server to handle all database interaction.

Figure 3-1 Cloudscape embedded in a single-user Java application

Figure 3-2 Cloudscape embedded in a multi-user Java application server

When a Cloudscape database is embedded in a Java application, the database is dedicated to that single application. If you deploy more than one copy of the application, each application has its own copy of the database and Cloudscape software. A server framework can work in multi-threaded, multi-connection mode and can even connect to more than one database at a time, just like single-user applications. However, only server framework at a time can operate against Cloudscape.

Figure 3-1 and Figure 3-2 look different, but from the point of view of the Cloudscape application (the one accessing Cloudscape), they are the same: the Cloudscape software is "embedded" in the application, and the application has its own copy of the database.

The Cloudscape application accesses an embedded Cloudscape database through the JDBC API. To connect, an application makes a call to the local Cloudscape JDBC driver. Accessing the JDBC driver automatically starts the embedded Cloudscape software. The calling application is responsible for shutting down the embedded Cloudscape database software.

Client/Server Deployment Application Overview

Cloudconnector is a JDBC and HTTP server framework. Cloudscape itself runs embedded in the continually running framework, Cloudconnector. Client applications connect to Cloudconnector over the network. Cloudconnector allows Cloudscape to act as a database server that provides data to multiple client applications.

Figure 3-3 Remote client applications connecting to Cloudscape running as a database server. Cloudconnector supports both HTTP and direct JDBC access.

Multiple client applications access Cloudconnector over the network. Cloudconnector returns data to multiple client applications.

Only Cloudconnector drivers are embedded in the deployed application, not Cloudscape.

Using Cloudconnector, multiple applications can access the same database concurrently. Only one Cloudconnector can access a particular Cloudscape database.

RmiJdbc is a customized version of freeware software that provides JDBC connectivity in a way similar to that described for Cloudconnector. It does not provide HTTP services or SSL.

Synchronization Application Overview

Distributed Cloudscape synchronization systems consist of one or more central source databases and multiple target databases (which can be multiple-user application servers or single-user applications).

Target databases act just like Cloudscape databases in the embedded mode. That is, they start up the embedded Cloudscape when running, access or insert and change data when needed, then shut down Cloudscape when the application shuts down. The only addition is that occasionally the databases themselves connect via HTTP to the source database for synchronization purposes.

Source databases can, but do not necessarily, run in the Cloudconnector framework. Running them in Cloudconnector makes it easier to have a continuously running source.

When the source databases run in the Cloudconnector framework, additional client/server-style applications can connect to Cloudconnector.

Figure 3-4 A Cloudscape synchronization system. The source database typically runs in a server framework such as Cloudconnector.

Choosing a Deployment Option

  • If you want to deploy single-user applications with embedded databases, but you don't want users to worry about network connections or any administrative overhead, choose the embedded database deployment option.
  • If you want to provide all data services to remote clients and build your own framework, choose the embedded database deployment option for your multi-user application server.
  • If you need to share data between occasionally connected applications, choose the synchronization deployment scenario.
  • If you want more than one application to be able to connect to the same database at the same time in a traditional client/server environment or via servlets, choose the database server deployment option.

The deployment option you choose affects the connection and threading modes available to your application. See Deployment Options and Threading and Connection Modes.

NOTE: You must purchase the appropriate deployment license for your product.

Deploying Java Classes for Use as Java Data Types

Cloudscape's Java extensions allow you to use your application's classes within Cloudscape.

When used by the application, these classes constitute application-side logic. Application-side logic is application code executed by the application. Examples are:

  • presentation logic such as GUI code
  • JDBC calls to Cloudscape

When these same classes are used by Cloudscape, they constitute database-side logic and are called user-defined Java data types. Database-side logic is application code executed within the Cloudscape system in the context of an SQL-J statement or expression. Examples are:

  • the class definition for stored objects
  • database-side methods executed within SQL-J statements, including those that make JDBC calls back to Cloudscape and synchronization-enabled methods known as work units

To summarize, Java data types are user-defined classes from your application used by Cloudscape.

Java data types must be available to the JVM in which Cloudscape is running. This means that you must deploy those classes used by Cloudscape (and add them to class path) so that the Cloudscape software can use them.

Java Data Type Deployment, Embedded Environment

In the most basic scenario--an embedded environment--you do not have to deploy your classes separately. Since Cloudscape and your application share the same JVM, they both access needed classes from the same user class path.

Figure 3-5 In an embedded environment, both your application and Cloudscape run in the same JVM and load classes from the same source.

In an embedded environment, it is also possible to store application logic in the database. In this situation, both the application and Cloudscape can load classes from the database, or Cloudscape only. Storing classes thus potentially simplifies setting the class path for the user.

Synchronization users can upgrade application logic remotely by including stored classes in a publication.

For more information, see Loading Classes from a Database.

Java Data Type Deployment, Client/Server Environment

In a client/server environment, you must deploy those classes needed by Cloudscape on the server. Cloudscape cannot access the classes directly from the same class path as the application, because it is running in a different JVM (and most likely on a different machine). Usually, it is easiest to deploy your entire application on the server, but not necessary. You only have to deploy those classes that are used within the context of SQL-J statements--Java data types. It is also possible to store Java data types within a database. (See Loading Classes from a Database.) This can simplify administration.

Figure 3-6 In a client/server environment, both Cloudscape and the remote applications must have their own copies of application classes. (Cloudscape can also load classes from the database.)

Deployment Cheat Sheets

NOTE: You must purchase the appropriate deployment license for your product.

Deploying Cloudscape in an Embedded Environment

You can "embed" Cloudscape in any Java application (single- or multi-user) by deploying the following package:

Figure 3-7 Deploying an application, embedded Cloudscape software, and the database. Storing the application in the database and setting properties as database-wide properties simplify deployment.

Embedded Systems and Properties

  • Are any system-wide properties being set that could be set as database-wide properties? Database-wide properties are stored in the database and are simpler for deployment. System-wide parameters are probably easier for development.
  • Are any properties being set in the cloudscape.properties file? Database-wide properties are stored in the database and are simpler for deployment. Some properties can only be set on a system-wide bases. If so, deploy the entire system directory along with the properties file. Deploy only those databases that you wish to include. Setting properties programmatically may simplify this step--you won't have to worry about deploying the system directory/properties file.

Before deploying your application, read Recommended Practice.

NOTE: Extra steps are required for deploying an application and an embedded database on read-only media. See Creating Cloudscape Databases for Read-Only Use.

Deploying Client/Server Applications

On the server, you deploy:

  • the Cloudscape jar file (cloudscape.jar)
  • additional server framework classes
  • Java data types
  • the database

On the client, you deploy:

  • the Cloudscape client jar file (client.jar)
  • additional server framework client classes
  • the application's libraries

Figure 3-8 Deploying a client/server system when using Cloudconnector

For more information about client/server systems, see the Cloudscape Server and Administration Guide.

Deploying Cloudsync Systems

On the server, you deploy:

  • The Cloudsync jar file (cloudsync.jar)
  • additional server framework classes, if desired
  • Java data types
  • the source database

Figure 3-9 Deploying a source database when using Cloudconnector

On the occasionally connected targets, you deploy:

  • the Cloudsync jar file (cloudsync.jar)
  • the application's libraries

    You have the option of storing these libraries in the database. (See Loading Classes from a Database.)

  • a target database

Figure 3-10 Deploying an application, embedded Cloudscape target software, and a target database.

For more information about synchronization, see the Cloudscape Synchronization Guide.

NOTE: For localized databases, you may need to deploy message libraries. See Messages Libraries.