JavaEnterprise JavaA Grid for Every Application

A Grid for Every Application content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.


What can I tell you about the attributes of the perfect application for a Grid environment? Or, should you be asking about the perfect Grid environment for your application? As much as you would like these two questions to lead you to the same answer, they rarely, if ever, do. In this article, I will discuss what I like to call the Application Grid—the perfect Grid setup for your application. I am staying away from the term “virtualization” because it is too abstract, and means different things to different people.

Round and Square

Putting your application on the Grid is like trying to fit a round peg in a square hole. Anyone who tells you otherwise is sugarcoating the truth!

Figure 1: The ultimate Dilemma

Why is this so? Your application is flexible, adaptable, simple to grasp, manageable, and most importantly—controllable by you! If your application, for example, requires access to a database, it is as simple as using O/JDBC to connect to a remote database. You don’t really need to worry about where in your code you connect to the database, how you manage the connection, and so forth. You can connect at the beginning of your application, use the connection while your application is running, and close the connection before you exit. You don’t really need to close the connection, do you? How many times you said to yourself, “it’s okay—the connection will timeout eventually!”

The best part is that the handful of developers who wrote the application know exactly what to do or, more importantly, not to do to make the application work. The best analogy I can give you is the classic TV antenna scenario that existed before you got cable TV. You knew, for each channel for a given time, where to point those rabbit ears to get the best reception. The reception might have not been perfect, but you had some control. Let me ask you a question: What do you do now when your cable or satellite TV reception is not good? Do you call the cable company and ask them to move the satellite until your reception clears up?

Finishing Each Other’s Sentences

Deploying applications in a distributed environment, and Grid, the most distributed of them all, is like trying to finish someone else’s sentence without knowing who that person was or when they finished speaking! Not that easy, is it?

Why is this so? Well, it’s simple; because it is in a distributed environment and by definition, you may not and most likely, do not have instant accessibility and control over all the distributed pieces. If one part finishes (an event occurs), you don’t really know so until the notification of that event (a message) reaches you. If you never receive the message, you don’t know whether the message was lost, or that event never took place. To make matters worse, in a Grid environment, you have a heterogeneous infrastructure [1] in which you may have old servers, new blades, different types of OSes, and so forth. What ends up happening most of the time is that an application that was written for a single-CPU environment gets distributed, and all of a sudden you have tons of bugs and issues to deal with. The infrastructure did not introduce these bugs into your application; it simply made them more apparent and visible. I don’t claim that I have a solution to this problem; nonetheless, it needs to be stated. This is a problem that exists; I am simply stating the facts.


I wanted to start this section with the following [radical] claim:

“There exists a Grid environment and setup for every application; it’s just a matter of finding the configuration that best fits your needs.”

How is this so? “Grid-enabling” is simply done by adding a layer of management and provisioning to your application. This is something you have to and you do today; all grid-enabling does is to automate the process. Again, I wanted to draw an analogy with the EAI era. You picked any application and qualified it as an EAI project. Very few applications did not qualify for some sort of an EAI-type project. With Grid, it is the same story. Given proper management and virtualization environment, you could Grid-enable any application. The trick is that the infrastructure must be adaptive and allow a range of configuration and optimization options.

Application Qualification

Each application behaves differently on the Grid; some applications may benefit more than others, but what all applications have in common is the amount of effort that it takes for Grid-enablement: none-trivial! There is no pill you can swallow; there is no magic wand; there are only guidelines and best practices. The goal is to look for patterns in the infrastructure and in the application to guide you in this process. Below is a list of checkmarks or application attributes that you can refer to determine the applicability of a Grid solution.

Table 1: Grid-enabling application checklist

Attribute Importance Reason
The application has distinguishable and discrete work units High Think of the classic SOA model. You need to be able to specify when one unit of work starts and when it finishes.
The application is composed of repetitive work units


(traditionally high)

This is a workflow model of a Grid. You can parallelize at the workflow level as opposed to work-unit level.
The application requires external components Medium Database, various system access needs, and so forth. This will be a balancing act between the security and flexibility of the Grid infrastructure.
The application has SLA requirements High This is almost given. Any application requires a certain level of SLA; the Grid must be able to accommodate this per application.
The application needs or requires scalability Low This is a surprising one to most. Your application may be one client and service, and that is all. The reason that this application may be considered for the Grid may be to meet SLA, or other requirements.
The application requires management automation


(traditionally low)

This is the primary and the most important reason why an application should be considered for the Grid.

I want you to pay special attention to the following two attributes:

“The application requires management automation”


“The application is composed of [discrete] work units”

I am proposing a different perspective regarding what applications are applicable for the Grid. Even though the traditional Massively Parallelizable Application (MPP) is one candidate, I want you to start looking for applications that require management automation or applications that have discrete units of work; in other words, applications that have certainty when a unit of work starts and when it ends. Grid is perfect for these common applications, although they have not been the focal point due to the inflexibility of existing Grid infrastructures.

After all, what I are actually talking about is the promise of virtualization. (In the opening paraagraph, I said I was not going to refer to virtualization) A grid infrastructure has the ability to provide your application a level of management and provisioning—and in turn reduce manpower and resource required to maintain your application.

The xFactor Factor

As mentioned in a previous article, “Messaging and the Grid, the Perfect Marriage,” the xFactor product is composed of a software stack (see Figure 2).

Figure 2: The xFactor Software Stack

This layered approach allows an application to take advantage of both the data plane (Messaging layer) and the compute plane (Grid layer). The Data Plane is the area where less repetitive applications would normally exist; this is the classic EAI application where two distributed processes are communicating thru a message bus. Depending on the subscription, an application may receive a number of messages that it needs to process and respond to.

The xFactor allows for this application to be “upgraded” one layer to the Compute Plane and take advantage of the services provided by the Grid, but still have the advantage of the message bus. Traditionally, to be considered for Grid-enabling, applications had to conform to a set of rules; one key rule requires repetitive work units (Table 1). xFactor allows applications to take advantage of the Grid layer but still have the advantage of the Messaging layer; it is a powerful tool that practically eliminates the need for repetitive work units.


There are many pre-conceived notions of “what is Grid-enable-able?” In this article, Ichose a different approach to the question of Grid-enabling applications and offered some advice. Furthermore, I characterized how the xFactor product allows one to Reconfigure Your Thoughts® per se, and start thinking about Grid and applications suited for Grid, differently.

About the Author

Art Sedighi is the CTO and founder of SoftModule. SoftModule is a startup company with engineering and development offices in Boston and Tel-Aviv and a sales and management office in New York. He is also the Chief Architect for SoftModule’s xFactor product that has risen from a current need in the market to manage excessive demands of computing power at a lower cost.

Before SoftModule, Mr. Sedighi held a Senior Consulting Engineer position at DataSynapse, where he designed and implemented Grid and Distributed Computing fabrics for the Fortune 500. Before DataSynapse, Mr. Sedighi spent a number of years at TIBCO Software, where he implemented high-speed messaging solutions for organizations such as the New York Stock Exchange, UBS, Credit Suisse, US Department of Energy, US Department of Defense, and many others. Mr. Sedighi received his BS in Electrical Engineering and MS in Computer Science, both from Rensselaer Polytechnic Institute.

[1] Please see my previously published article, titled “Grids, Clusters, Virtualized Environment, and All of That.”

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories