Although it is possible to use CA 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 visually.
All of the abstractions defined in the 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 take advantage of this, CA AppLogic® defines a visual work flow 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 work flow. Those steps include:
This topic also covers related issues such as change management and version control.
CA 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 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. 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 have built-in firewalls.
See more details in the Application Configurator.
Note: Creating an application is an interactive process. You can create a new application from scratch or copy an existing application and modify it to fit your needs.
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 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.
Important: The first time you start an application after adding one or more new appliances to it, CA AppLogic® will automatically instantiate all class volumes for these appliances. Depending on how large those volumes are, the process may take between 2 and 10 minutes, or even more.
Once a singleton appliance is ready, you can drag it to a catalog 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.
Note: In the process of creating a new catalog class, CA AppLogic® converts the named application volumes provided as class volumes of the new class into instantiable class volumes and removes them from the list of application volumes.
It is often much easier to create a new appliance by starting from an existing catalog appliance and modifying it as needed. CA AppLogic® supports this through an operation named class branching.
To create a new appliance from an existing appliance
A new singleton appliance within your application is created. This appliance is a copy of the original class, with all its volumes, properties, terminals, and so on. 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.
To create an assembly appliance, drag a blank assembly onto the canvas.
A singleton composite class with an automatically generated name and an instance of that class is created.
Edit the Class
To edit the new class, select the newly created instance and open the class editor on it, the same way as you do this for regular appliances.
Note: 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.
To Create the Interior of an Assembly
The Infrastructure Editor steps in the assembly and displays an empty canvas with a few pseudo-objects that represent the terminals you have defined on the boundary of the assembly.
Note: Within the interior, the inputs of the assembly behave as outputs - you can connect an input to exactly one input of a subordinate appliance. The outputs of the assembly behave as inputs - multiple outputs of various subordinates may be connected to one output 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 assembly to a property of a subordinate, simply open the instance settings dialog on that subordinate, click 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.
It is important to know that you don't have to wait until your application is fully elaborated before you can run it. CA 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 discover your appliance is not working correctly, but still want to start the application to test another part of the infrastructure, simply disable the automatic start of the misbehaving appliance by preventing it to start when the application is started.
Note: Once an appliance is started, you can log onto it using SSH and do anything that you would typically do with a server.
Considering that your application is a hierarchical structure of appliances, and is fully contained in the MAIN assembly, you can complete the process and define a boundary for the application. This allows another user to set up and start a new instance of the application without having to understand how it operates.
To achieve this, you simply have to decide what properties 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, name and password of the admin account, and tuning parameters, such as various cache sizes, queue lengths, and timeouts.
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, and set up the hardware resources and execution attributes for the whole application.
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.
CA AppLogic® enables a simple and effective approach to change management in distributed web applications by using existing technology that is well understood and proven. 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.
|
Copyright © 2012 CA.
All rights reserved.
|
|