Deploying Applications

Developing with the SDK > Introducing the SDK > Deploying Applications

Deploying Applications

JViews Diagrammer offers a set of components, classes and APIs making it possible to build all sorts of graphical displays. The core Graphics Framework provides interactive vector-graphics primitives that will have their own life cycle and can be displayed in a variety of containers, including Swing or servlets. With Cascading Style Sheets (CSS) and SDM, the creation of such graphic objects is automated and sophisticated displays are built more easily. Most of the work needed to create specific visual representations is the same, whether you decide to deploy your application with rich or thin-client technologies. What is really important is to make sure that:

You can control the integration of your visual components with the right containers.
You have the kind of interactions you need for the application.
You have the ability to package and deploy your work efficiently.

This section summarizes the main characteristics and tips of each deployment strategy.

Java AWT/Swing Application

This is the most traditional way to deploy JViews applications. All graphical styles and interactions are available, and there are very few limitations. Traditionally, applications are deployed using the IlvDiagrammer class (derived from a JComponent) or classes of the ilog.views.diagrammer.application package. Note that the IlvDiagrammerApplication class (derived from JApplet) is a top-level container that allows you to create either applications, applets, or Java WebStart applications.

See Writing an Application in Using the Designer.

Java Applets

Basically, an applet is a Java application (a rich client) running inside a Web browser. The main noticeable differences between applets and applications are the following:

Applets do not have the same kind of top-level container (like a JFrame, for example). Your Java code is not responsible for creating the main window, and your applets have to live within the limits of the provided ContentPane.
The code of the applet is usually invoked by a Web page downloaded from a remote Web site and executed on demand.
Unless your application is signed or your Java security policy has been extended, your applets have limited access to local resources, such as files, printers, and so on. This requires particular attention for dealing with security exceptions.
Most of the time applet classes and resources need to be packaged as JAR files and need to have a very clean access to their data, such as images or resource files.

Like other Java programs, a JViews application needs some particular attention to packaging and use as an applet. If possible, we recommend you use the IlvDiagrammerApplication class, which is already able to manage applets or applications. Most samples available in the JViews Diagrammer distribution are packaged so they can work transparently as applets or applications. If you decide to use lower-level containers, such as IlvDiagrammer, you will need to take more care in the integration with the top-level containers.

Creating an Applet

The IlvDiagrammer instance and its associated beans can be used in applets in exactly the same way as in Swing applications. The only limitations are the restricted permissions in applets, for example, it is not possible to save data files from an applet.

The IlvDiagrammerApplication class extends the Swing JApplet class, so it can be used directly in an HTML applet tag. You can pass the command-line parameters as applet parameters: the names of the parameters are the same, without the "-" prefix.

For an example of an applet application, see the Applet sample, which is available in the directory <installdir>/jviews-diagrammer81/codefragments/applet.

Java WebStart

A Java WebStart (JWS) application can be seen as an applet running outside a browser. It allows you to have rich applications automatically downloaded, with great user experience. Except for careful packaging and for the same security issues mentioned for applets, there are no particular limitations for creating JWS applications with JViews Diagrammer.

Web Deployment

Creating applications for the Web is substantially different from the rich-client approach. It implies that most of the work is done on a remote server which sends ready-to-use images and scripts to a Web client (understand an Internet browser). There are many variants but the main idea is to receive and process HTTP requests on a server and, in return, to produce the right image to be sent back to the browser. Even if there are many architectural differences, the following aspects can be shared between rich and thin clients:

Styling: responsible for transforming data into graphics, the styling rules can be the same for rich and thin-client applications. For example, CSS files, symbols and Designer projects can be used for both scenarios.
Data model and connection with a data source: are the same and can benefit from the same code for both deployment strategies.
Graphical content: usually displayed in the background of a panel or as parts of a dynamic symbol; graphical objects can be reused in both cases.

The main differences reside in the way the application behaves and how it is packaged. Thin clients are usually driven by transactions and only partially support rich interactions. JViews Diagrammer thin clients are based on the JavaServer Faces (JSF) and DHTML technologies. Web pages containing visual components are created as (JSP) pages. The JSF-based components (also known as JViews Diagrammer Faces) provide the following services:

Display graphical content managed by Diagrammer classes and APIs. Data connection and styling are preserved.
Provide interactive views and overviews.
Manage local interactions, such as pan, zoom, selection, popup menus.
Minimize roundtrips when possible.
Extensions can be written for extending both server-side and client-side components.

The use of these JSF and DHTML components is described in Building Web Applications.

Eclipse/RCP

It is possible to deploy graphic components created with JViews Diagrammer as Eclipse or RCP (Eclipse Rich Client Platform) plugins. As with the thin client approach, graphical contents, styling, and connections to data sources can be reused under Eclipse. The main challenge is to integrate graphical panels and manage interactions with the Eclipse framework. Since Eclipse 3.0, making Swing-based code work within an Eclipse application is possible with the SWT-AWT bridge. Located in the org.eclipse.swt.awt package, this bridge offers a very simple interface between Eclipse and Swing widgets. Once a Swing container has been created inside an SWT widget, all AWT/Java2D primitives can be invoked. Note that this bridge only works with JDK 1.5 and higher. In the samples directory, you will find examples of such integration. The source code is provided, so you can make the integration package evolve with your own requirements.

JViews Diagrammer also provides its own bridge, IlvSwingControl, to display diagrams and dashboards inside Eclipse or RCP. For details, see Using JViews Diagrammer in SWT Applications.

PREVIOUS NEXT