1.2 Example XShell Applications

Enterprise-Wide Architectures

XShell allows you to model both data and applications as objects. A process-centric focus is well suited to enterprise-wide applications where dynamic interactions and independent activities take precedence over static data values. Consider the following simplified application architecture:

Figure 1-1. Simplified Application Architecture

This application uses both the client/server and peer-to-peer topologies. The various components - Database Server, Inventory, Warehouse, and Shipping - may be run on different machines across the network. The Inventory component obtains an Order Form from the Database Server. After Inventory determines that adequate stock is available to complete the order, it passes the Order Form to a peer, the Warehouse component. Warehouse completes the necessary packing lists for the warehouses and passes the Order Form to another peer, Shipping. Shipping receives the products, ships them out, and then returns the modified Order Form to the database via the Database Server. This scheme represents the natural flow of activity. The components (Inventory, Warehouse, and Shipping) interact with each other in a conceptually simple way that is appropriate for the jobs they are performing. XShell makes this type of application very easy to design, implement, and maintain.

Now, consider the following design which adheres strictly to the client/server topology:

Figure 1-2. Client/Server Architecture

In this implementation, Inventory must first obtain the Order Form from the Database Server, and then return it. Each succeeding component must do the same. Since the strict client/server architecture is more unnatural (for this application), the code will have to be written in a counter-intuitive way. This will make the design, implementation, and maintenance more difficult. In addition, the machine resources will not be optimized, since the Database Server will have to access the database three times, instead of just once. Yet, without XShell, this is the type of design that you would probably have to implement, unless you took it upon yourself to design and develop a substantial amount of complex networking code.

These kinds of issues become ever more important as an application grows in size and complexity. Consider the following application design:

Figure 1-3. Simplified Application Architecture

This architecture exemplifies a popular new business computing paradigm. In this paradigm, software objects are used to model business activities. The application might simply perform simulations. Simulations are useful for analyzing business activities and trends, performing projections, examining the flow of money and goods, and so forth. However, a system like this can also be used to control the enterprise. In many situations, a system begins as a simulation, and after different scenarios are tested, the optimal design grows into the production system.

The example application, shown above, includes the order processing cycle from the first example. Now, however, three copies of the Shipping component can be activated during busier times. When the shipping requirements slacken, the extra Shipping components can be taken off-line to free up machine resources for other activities. XShell makes this type of functionality extremely easy to implement.

The system also includes Manufacturing and Purchasing components, along with another Database Server to support them. Several messages are passed between the components to coordinate activities and to carry on the business of the overall system. Inventory tells Manufacturing to produce additional inventory for specific items. Manufacturing tells Purchasing when new materials need to be purchased. These kinds of coordinated activities can easily be implemented with very little code. In addition, it is easy to change the architecture. You could add an Accounting component or cause Purchasing to interact directly with Inventory. Machines and application components can easily be brought on-line or taken off-line, and components can be run on alternate machines. As the enterprise's requirements change, an XShell application can quickly evolve to fill those requirements.

It is worth taking a closer look at one aspect of this application. Notice that the Shipping component maintains connections with Database Server 1, Warehouse, and Manufacturing. With XShell, you can create a new Shipping component by simply copying an existing Shipping component. All of the connections can optionally be preserved in the new Shipping component, even if it is reconstructed on a different machine:

Figure 1-4. Copying the Shipping Component

Any XShell object can easily be copied like this, regardless of the complexity of its internal structure or connections. It is also possible to simply instantiate a new Shipping component and allow it to establish its own connections.

It is interesting to note that some objects are transient, such as Shipping, and other objects are persistent, such as the Database Server. Transient objects start in the same state each time they are initiated. Persistent objects start in the state they were in when they handled their last commit command. The Database Server might be brought down during maintenance, but generally it will be available at all times for other components to access. The user will want the Database Server to restart in the state it was in when the it was closed for maintenance. XShell supports these kinds of requirements. XShell's ability to keep some components around, while others come and go, allows a system to "expand and contract" as necessary to handle fluctuating loads and machine down time.

Once the connections are established between any two components, for example between a new Shipping component and the Database Server, all interactions appear to be local, no matter where the components are actually running. This simplifies the design so that components in an "expanding and contracting" application don't have to be rewritten for different configurations.

Computationally-Intense Tasks

The kind of application described above lies at one extreme of the architectural spectrum for distributed applications. At the opposite extreme, there is a breed of applications that perform a single computationally-intense task. These applications must process very large amounts of data, or perform a very large number of calculations on a given data set, within reasonable time frames. These applications have often been run on supercomputers in the past. XShell provides full support for a cost-effective alternative that allows you to easily unite the power of a set of servers and workstations.

Consider a Biological Monitoring System that compares composite images taken by a LANDSAT satellite. An application of this type might be used to monitor the health of crops, the state of forestation, or the state of other biological (or geological) resources. Images from two different years, such as 1980 and 1990, are filtered and smoothed. Then, calculations are performed to highlight the differences between the images. Since a LANDSAT uses seven different spectral bands (mostly in infrared), hundreds of megabytes are required to store each image. In addition, many algorithms must be run on the data. This may take hours on a single workstation.

With XShell, it is easy to set up a scheme whereby a single machine acts as a Image Processing Client, and spawns servers on all currently available machines. The client breaks up the image data into manageable pieces, and passes each piece to a server for evaluation. This is done in an asynchronous manner, so that the client can continue about its business as soon as it has sent the data out to one server. After the client has sent out enough data to use up the available machine resources, it can wait for the servers to begin returning the processed data. By simply waiting (instead of constantly checking to see if any servers are finished), the client frees up machine cycles on its own machine. A simple XShell event handler mechanism can be used to wake up the client whenever a particular server has completed its task. The client can then accept the processed data, and send out the next piece of raw data to the server. Thus, all machines are kept optimally loaded throughout the run, regardless of the performance characteristics of any particular machine. XShell makes it very easy to send and receive the data, to spawn processes throughout the network, to keep track of available machines, and to install the event handlers needed for this application.

Figure 1-5. Biological Monitoring System

With XShell, it is easy to set up a scheme whereby a single machine acts as a Image Processing Client, and spawns servers on all currently available machines. The client breaks up the image data into manageable pieces, and passes each piece to a server for evaluation. This is done in an asynchronous manner, so that the client can continue about its business as soon as it has sent the data out to one server. After the client has sent out enough data to use up the available machine resources, it can wait for the servers to begin returning the processed data. By simply waiting (instead of constantly checking to see if any servers are finished), the client frees up machine cycles on its own machine. A simple XShell event handler mechanism can be used to wake up the client whenever a particular server has completed its task. The client can then accept the processed data, and send out the next piece of raw data to the server. Thus, all machines are kept optimally loaded throughout the run, regardless of the performance characteristics of any particular machine. XShell makes it very easy to send and receive the data, to spawn processes throughout the network, to keep track of available machines, and to install the event handlers needed for this application.

In general, the form in which you use data is not necessarily the form in which you would like to store that data. The Biological Monitoring System is one example of this: the LANDSAT image stored in the database is decomposed and distributed for processing, and then recomposed when it is returned to the database. An even more illustrative example is an aerodynamic design application. In this application, the data that describes an airframe (i.e., the body, fuselage, wings, tail, and landing gear of an airplane) is stored in a database as a coherent entity. However, it may be advantageous to break up that airframe entity into heterogeneous pieces, and distribute those pieces to nodes across the network for assessment. At each node, a computational fluid dynamics program calculates the effects of lift, stress, drag, and so forth. The results are then collected, and the overall airframe design can be evaluated.

XShell's object-oriented approach makes it easy to break up complex objects into subcomponents and to distribute those subcomponents for processing. An XShell object can be streamable. That is, it has the ability to send itself out over the network, and to reconstruct itself at the destination node. Since a complex XShell object can be modeled as a collection of smaller objects (to an arbitrary number of levels), it is easy to divide up and distribute complex pieces of data for distributed parallel processing.

XShell also makes it easy to replicate an object many times, and to perform a large set of computations on each instance of the object. Consider the following Securities Analysis Application:

Figure 1-6. Securities Analysis Application

In this application, a Security Profile is replicated and sent out to several Value Prediction Model servers. Each server determines the value of the security under a very large number of scenarios. It does this using the Monte Carlo method (whereby the scenarios are generated using random numbers to reflect possible market conditions, price fluctuations, and so forth). The results are aggregated back, and the most probable outcome is determined.

This type of application is also easy to build with XShell. Objects, such as the Security Profile and the Value Prediction Model server, can be instantiated an arbitrary number of times. Several instances of the server could be started on a single machine, or each machine could run a single copy. It is possible to dynamically specify the number of servers at run time, as well as the machines on which they will be executed. This allows you to easily manage your compute resources in the most effective manner.

All of the architectures described above can be mixed and matched in any combination. Any level of nesting can also be accommodated. For example, a CAD application could call a Review/Markup utility, which could call a Printer Server, which could call Font Database Server, and so forth. The flexibility afforded by XShell allows you to take full advantage of object-oriented technology to model and control events in the real world.

Section 1.3 is here.

Return to Table of Contents

Return to Corporate Backgrounder