Workflow for Building Web Applications

Although it is possible to use AppLogic by specifying the application structure directly in the ADL language, the system was designed specifically to enable you to design, implement, integrate, deploy and operate distributed web applications visualy.

All of the abstractions defined in the AppLogic application model including virtual appliances, structures of appliances, composite appliances and whole applications are designed so that they are easy to visualize. Most operations on them are convenient to implement intuitively in a drag-and-drop graphical user interface. To help you take advantage of this, AppLogic defines a visual workflow for rapid design, construction and deployment of distributed applications using the application model and visual user interface.

In this section, we will discuss in more detail the basic steps supported by this workflow. Those steps include:

• creating the application
• creating a virtual appliance
• creating an assembly appliance
• adding an appliance class to a catalog
• packaging the whole application as an appliance

This topic also covers related issues such as change management and version control.

Creating an AppLogic application

AppLogic implements applications by combining a package descriptor, a singleton assembly named ' MAIN ', and an optional application catalog. Assuming that all required appliance classes already exist in one or more available catalogs, assembling the application consists of creating the interior of the MAIN assembly.

The MAIN assembly is different from other assemblies, because it has no terminals. The reason is that in AppLogic, terminals are used only for connections between appliances. To interact with the external IP network, the application needs to include one or more gateway appliances. The gateways are standard catalog appliances that isolate the rest of the application from the details and settings required for those interactions. As an added benefit, the gateways in AppLogic have built-in firewalls.

See more details in the Application Configurator.

In general, you start by deciding what services your application will provide to the network that defines the inputs of the application. Then, you create and configure an input gateway for each of those inputs. Theird, you decide what external services your application will need and configure a separate output appliance to access each of these services.

Once you have defined the inputs and outputs, it's time to create the application volumes, on which you can place the code, scripts, content and databases that are specific for your application. You can give each volume an appropriate name, and you can use an application volume with more than one appliance. For example, you can place all of your HTML files, static images, cgi scripts, and EJB packages in different directories of a single volume and later give this volume to all of your web servers and J2EE servers.

The next step is to assemble (or, modify) the infrastructure you need between the inputs and the outputs of the application using appliances and servers from the catalogs. In the process, you may decide that you need to build a new appliance or a server or customize an existing one to better fit your purpose.

The design of the new application is complete when the MAIN singleton is fully assembled and all subordinates included in it exist and are properly configured. As soon as this stage is achieved, the application is immediately ready for execution on a target hardware system.

Creating a virtual appliance

To create a new virtual appliance from scratch you open the AppLogic application editor and drag a blank appliance onto the canvas. This creates a new, automatically named singleton class and an instance of that class. You can now select the new instance and open the class editor to modify its class.

Step 1. Defining the boundary

In the class editor you define the new virtual appliance by specifying the elements that together form the boundary of the appliance. Those include:

• a class name
• a set of default execution attributes
• a set of default hardware resources (CPU, memory and bandwidth)
• a set of properties with their names, data types and default values
• a set of terminals, with their names and protocols
• a set of volumes

In addition, the class editr allows you to specify the size, color and other visual elements that define the appearance of instances of the new class within the application, and a few advanced parameters.

Step 2. Setting up the volumes

Using the application settings property sheet, you can create one or more named application volumes, which you can use to prepare the class volumes for the new appliance class. You do this by installing or copying on them the desired combination of operating system, add-on software packages and configuration data for the appliance and configuring each software package as required.

Step 3. Configuring the software

Once the various pieces of software are integrated to work together inside the appliance, you can bind the properties of the appliance to them. To achieve this, you instrument the appropriate configuration files and scripts using the AppLogic simple tagging language or one of the other methods described in the previous section.

The next step is to configure the software packages within the appliance to use the names of the terminals defined on the boundary of the appliance. If the appliance does not have multiple input terminals with the same protocol, the software within the appliance is usually configured to listen for incoming network sessions in the conventional way (e.g., by port number only).

For output terminals, you configure the appropriate software packages as if the name of the respective output terminal was the name of a remote network server, to which the package is expected to establish a communication session.

Step 4. Completing the appliance

Once you have configured the volumes and bound them to the properties and terminals of the appliance, you can attach them to the appliance by opening the instance settings property sheet on the instance and configure each volume placeholder with the name of the appropriate application volume.

You now have a fully functional singleton appliance that you can connect to other appliances, start and stop, test for functionality and performance and use inside your application. About the only thing you can not do is create multiple instances of your new appliance. To do this, you will need to convert the appliance to a catalog class.

See more details in the Infrastructure Editor->ClassEditor.

Adding an appliance class to a catalog

Once a singleton appliance is ready, you can drag it onto one of the available catalogs to create a catalog class, from which multiple instances can be created. The act of dragging the appliance onto the catalog converts it into an identically named catalog class, includes that class in the package of the desired catalog, and deletes the instance used to create and edit the new appliance.

Creating a virtual appliance from an existing one

It is often much easier to create a new appliance by starting from an existing catalog appliance and modifying it as needed. AppLogic supports this through an operation called class branching.

To start creating a new appliance from an existing one, simply drag on the canvas an instance of the class you wish to start from and select "Branch Class" from the context menu. This will create a new singleton appliance within your application, which is a copy of the original class, with all it's volumes, properties, terminals, etc. The instance, whose class you are branching, will be modified accordingly.

You can now proceed to modify the appliance as if it was created from scratch. When you are done, you may want to convert the new appliance to a catalog class, so that you can use it in many places within the application or in other applications.

Creating a composite appliance (assembly)

To create an assembly appliance, you simply drag a blank assembly onto the editor canvas. This creates a singleton composite class with an automatically generated name and an instance of that class.

You can now edit the new class by selecting the newly created instance and opening the class editor on it, the same way as you do this for regular appliances. The class editor allows you to modify the name of the new class and define its boundary including hardware resources, execution attributes, properties, terminals and volumes.

Unlike a simple virtual appliance, where the functionality is determined by the operation of the software installed and configured on the class volumes, the operation of an assembly is defined by a set of interconnected and configured appliance instances that, together, form the interior of the assembly.

You create the interior of the new assembly by selecting the assembly instance and choosing "Edit Interior" from the context menu. Once you do this, the AppLogic editor will "step-in" into the selected assembly and will display an empty canvas with a few "pseudo-objects" that represent the terminals you have defined on the boundary of the assembly. You can now assemble the functionality you need by dragging subordinate appliances from the catalogs, configuring them and connecting them with each other and with the terminals of the assembly.

All properties and volumes of the assembly must be redirected to the properties and volumes of one or more of its subordinates. To redirect a property of the asseembly to a property of a subordinate, simply open the instance settings dialog on that subordinate, choose the right property and select the name of the assembly property to be redirected in the place of a value setting. Redirecting volumes works the same way.

See more details in the Infrastructure Editor->Assemblies Class editor.

Improving your application interactively

It is important to note that you don't have to wait until your application is fully elaborated before you can run it. AppLogic can start any subset of your application, being it a single virtual appliance, an incomplete structure of virtual appliances, a finished application subsystem such as a database cluster or a web tier or an application that is not completely configured.

Naturally, if you try to start an appliance which is work in progress, there is no guarantee that it will boot successfully or that it will do what you expect it to do when booted. If you find that one of your appliances is in such a sorry shape, but still want to start the application in order to test another part of the infrastructure, simply disable the automatic start of the misbehaving appliance by preventing it to start when the app is started.

Packaging the entire application as an appliance

Considering that your application is a hierarchical structure of appliances, and is fully contained in the MAIN assembly, it makes sense to complete the process and define a boundary for the application, so that someone else can set up and start a new instance of it without having to understand how it operates.

To achieve this, you simply have to decide what properties and/or volumes you would like to make available for modification at the time a copy of the application is being deployed. For example, you may want to define properties that would allow you to set up externally visible IP addresses and other network settings for the gateways, the DNS names that need to be registered, things like the name and password of the admin account, as well as tuning parameters such as various cache sizes, queue lenghts, timeouts, etc.

Adding properties and volumes on the boundary of the application is as easy as adding them on the boundary of any other assembly: you simply create each property using the class editor on the MAIN singleton and then redirect it to one or more properties of subordinate appliances as described above.

Once this is done, you (or someone else) can use the Application Settings editor to view and edit the values of those properties, attach volumes, as well as set up the hardware resources and execution attributes for the whole application.

See more details in the Application Configurator.

Change management and version control

One of the problems that is difficult to handle with existing systems today is the ability to capture and manage the full set of configuration and other changes that may affect a running application. As a result, it is often impossible to roll back to a 'last known good' state of the application.

The problem becomes especially acute when the application is large enough to require multiple people to administer, tune and troubleshoot the system. The typical approach to solving this problem today is to introduce restrictive processes and complex change management systems, which often make the situation worse by adding complexity.

AppLogic enables a simple and effective approach to change management in distributed web applications by using existing technology that is well understood and proven. In AppLogic, the complete structure and configuration of the application is stored in a collection of text files (the ADL descriptors) and binary files (the virtual volumes).

This makes it possible to use an existing version control system both for version control of distributed applications during design and development and for change management in the later stages of application delivery and deployment.

-- VladM - 25 May 2006