It took me a while to get this done, not so much because of the code, but because the documentation that accompanies it is pretty extensive and I have been in the middle of some significant career changes.

This post is long primarily because I walk through the highlights of the what the code does and how this bolsters what I was saying in my earlier post.

Inside the zip file are 2 zip files and 3 PDF files:

• DynamicOpenClientJar.zip is the compiled version of the code. It contains a jar file, the input.xml, a batch file, and the Progress source code.
• DynamicOpenClientJar.pdf contains setup instructions to set it up and run it.
• DynamicOpenClientSrc.zip is the source code.
• DynamicOpenClientSrc.pdf contains the instructions that that tells you how to set the source code up to work with Eclipse.
• DynamicOpenClient.pdf is a detailed tour of the code and describes how it works.

This is Sample Code

Before you dig into the code and say "Wow!! This code sucks!!" it is important to understand that this is sample code. There are a lot of things about it that are ugly. Some of the object model needs serious refining. There are cleaner ways of doing the XML parsing and it is nowhere near as defensive as it should be. There are those who believe that bad code samples lead to bad code in production, but there is another line of thought that goes that if you don't recognize those bad examples, you should not be coding to start with. The point with this code is that it demonstrates concepts and that's what it was intended to do.

Code Limitations

For the sake of brevity, I have deliberately not covered stuff like supporting supporting ProDataSets and all of the different Progress data types. I have covered the most common ones and temp-tables. ProDataSets are really an extension of temp-tables and you can feel free to go and look at the code in a generated proxy to see how they work. I also stopped short of supporting the building of temp-tables from an input XML file. The extra code to do this did not seem like it would really add that much to the example. This code example also does not support persistent procedures because they are a lot more complicated than this code will allow.

Set it up and try it

Having said all of that, I wanted to spend some time in this post elaborating on the comments that I made in the earlier post about why Dynamic OpenClient is such a powerful technology, using the example code that I am presenting here. So I am going to assume for the rest of this article that you have at least set up and run the example and that you have the source code accessible to follow along.

How it Works

The Dynamic Open Client code takes an XML file and parses it for AppServer connection parameters, R-Code signatures and calls that need to be made to the Progress/OpenEdge R-Code files. The sequence diagram at right (click on it for a full-size image) shows the process.

Once the XML file has been parsed, the utility executes each of the calls and serializes the results of the call's execution to an internal XML document. Once all the calls have been executed and serialized, the results are written out to another XML file that is specified in the input.xml file. More information on the XML file's format is in the DynamicOpenClient.pdf file.

The Main Components

To understand how this utility works, you need to understand the core of the class model. So let me start by dividing the class model into its major areas.

You can pretty much ignore the com.tsg.common project. It contains an interface - INamedItem – used by a few classes that simply has a getName() method declaration. INamedItem is implemented by some of the classes in the com.tsg.dynamicopenclient project. This interface is specifically used for objects that may be stored in a com.tsg.common.collections.OrdinalList – a specialized list that is ordinal like an ArrayList, but expects uniquely named items in the list. OrdinalList is used for things like field lists and parameter lists where the fields need to be in a specific order, but the names have to be unique.

The com.tsg.dynamicopenclient project contains three packages:

• com.tsg.dynamicopenclient - This package contains the code that does most of the work;
• com.tsg.dynamicopenclient.data - This package contains the class hierarchy for parameter and other data element definitions;
• com.tsg.dynamicopenclient.valueholders - This package contains the class hierarchy for all the value holders that are used to contain the values of input and output parameters.

Data Types

One of the most important aspects of the communication between the OpenClient and the AppServer, is the mapping of data types from Java to Progress. To make sure that this is done consistently, there is a DataType enumeration in com.tsg.dynamicopenclient. If you have not worked with Java 5, enumerations may be a new concept to you and this one is particularly more so than others. An enumeration is a great way to deal with hard-coded constants and it is particularly useful where a map of constants is necessary. In this particular case we have to map an OpenClient numeric constant to a string representation of the data type, a Java class that can be used to map to that type and a valueholder class that can be used to contain the Java type. The following definition of the INTEGER data type demonstrates the mechanism:

INTEGER
  (Parameter.PRO_INTEGER, // Progress numeric constant
   Parameter.PRO_INTEGER_NAME, // Progress character constant
   "java.lang.Integer", // Java class to be used to map
   "com.tsg.dynamicopenclient.valueholders.IntegerValueHolder"), // Dynamic OpenClient valueholder

The DataType enumeration has several methods associated with it to retrieve a constant based on the string name of the data type or to obtain the Java class, value holder class or Progress data type constant. It also contains code that will instantiate an object of either the Java class to contain the data type or the value holder. This enumeration truly is at the core of the code.

Data Elements

The com.tsg.dynamicopenclient.data package contains a set of classes that define the behavior of data elements. A data element is any item that has a name and a datatype associated with it. Thus, fields and parameters are all data elements. Data elements only store the definition of the element. They do not store the value. The value is stored in a value holder. The abstract base DataElement class contains all the behavior for parsing parameter and field definition information from an XML node.

The Parameter class extends it by providing support for parameter modes (INPUT, INPUT-OUTPUT and OUTPUT) which are mapped in an enumeration called ParameterMode in com.tsg.dynamicopenclient.

The TempTableParameter class extends the Parameter class further by providing support for parsing temp-table definitions from the source code and supporting the construction of ProDataGraphMetaData objects that are used to build the ProDataGraph to transport temp-tables between AppServer and client.

Value Holders

The com.tsg.dynamicopenclient.valueholders package contains a set of classes and an interface that are used to standardize the way that data types are dealt with. Looking at the class model, the value holder hierarchy is to the right of the diagram. This hierarchy leverages the concept of generics that was introduced in Java 5.

The IValueHolder interface is the base of the hierarchy and the ValueHolder abstract class contains the generic behavior for value holders. These classes provide support for the Progress UNKNOWN value as well as reasonable default values that match the Progress defaults for its data types.

Value holders are used to set the value of input parameters and to contain the values of output parameters.

DynamicOpenClient Class

The DynamicOpenClient class in com.tsg.dynamicopenclient contains the main() method - the entry point to the utility. It starts out by parsing the parameters to determine where the XML file is that contains the signatures and input parameters for the calls. The input.xml file's structure is detailed in the DynamicOpenClient.pdf file that accompanies the source code. In essence, though, there are 4 types of nodes that are important:

• dynamicoc – This is the root node for the document and it contains an OutputFile attribute that has the name of the file that should be used for the results of the calls.
• appserver – This node contains the signature and call nodes and a set of attributes that define the connection parameters for the AppServer.
• signature – This node contains the signature of a call that will be executed against the AppServer. The signature node may contain a set of parameter nodes which will be all of the parameters for a procedure. These parameters must be specified in the order that they are specified in the ABL source code. If the parameter's DataType attribute is TABLE, the node will contain child nodes that are the field and indexes for the table.
• call – This node contains a list of calls that need to be executed against the AppServer. Each of them should refer (by means of the Procedure attribute) to a previously specified signature. call Nodes may contain subordinate parametervalue nodes that reference a parameter in the signature by name and specify the value to be used as the input value for that parameter.

The following code extract comes from the main() method.

//Extracted from main() method.
//

//Instantiate the CallManager
CallManager manager = CallManager.getInstance();

//Parse the XML file.
try {
	parse(fileName);
}
catch (Exception e) {
	System.out.println(e.getMessage());
	return;
}
.
.
.
Iterator<Call> iter = manager.iterator();
while (iter.hasNext()) {
	Call call = iter.next();  //Get the call
	call.executeCall();   //Execute the call
	outRoot.appendChild(call.serializeResults(outputDocument));
	iter.remove();
}
.
.
.
try {
	writeResults();  // Write the XML results file out to disk.
}
catch (Exception e) {
	System.out.println(e.getMessage());
	return;
}

Before doing anything else, the code instantiates the Singleton CallManager to hold onto all the data that will be parsed from the XML file.

The main() method calls the static parse() method with the name of the XML file to be parsed. This method parses the XML document and iterates through the four element nodes mentioned above. It also sets up a DOM document that will be used as the output document for the results of the calls.

For each element, it instantiates an object of the appropriate class and passes it the XML node that needs to be instantiated. This object is then added to the CallManager where it will be retrieved later.

//Extracted from parse() method.
//
Node elementNode = null;
while((elementNode = iterator.nextNode()) != null) { // Loop through elements

	// Handle root node.
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.INPUT_ROOT_NODE.toString())) { 	

		// Setup the output file.
		String attrValue = XMLStrings.getAttribute(elementNode, XMLStrings.OUTPUT_FILE_ATTR.toString());
		if (attrValue != null) {
			outputFileName = attrValue;
		}
	}

	// Handle appserver node
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.APPSERVER_NODE.toString()) ) {
		manager.setAppServerConnection(new AppServerConnection(elementNode));
	}

	// Handle signature node
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.SIGNATURE_NODE.toString()) ) {
		manager.setSignature(new Signature(elementNode));
	}

 	// Handle call node
	if (elementNode.getNodeName().equalsIgnoreCase(XMLStrings.CALL_NODE.toString()) ) {
		manager.addCall(new Call(elementNode)); 
 	}
}

The CallManager implements the Iterable interface for the Call class. Back in the main() method, the next thing we do is iterate through all of the Call objects in the CallManager and we execute the call. This is where the real work happens and a description of it is below. When execution is complete, the parameter values will have been stored in the Call object and a call to serializeResults() will return an XML node that can be appended to the output document. The Call object is then deleted from the list of calls to free up the memory that any temp-tables will occupy.

Once all the calls have been executed, a call is made to writeResults() which writes the output XML document to disk.

Executing the Call

A call is actually executed by a call to executeCall() on the Call object. The executeCall() method simply builds a parameter array, calls the runProcedure() method on the AppServerConnection object, builds the output parameter value set and handles any exceptions. The thing that makes this client dynamic is the code in buildParamArray() and buildOutputValues().

buildParamArray()

In order to make a call to the AppServer, the OpenClient needs a procedure name to call and a parameter array (com.progress.openABL.javaproxy.ParamArray) for the call. The parameter array needs to contain a full description of each parameter as well as the value to be set for the parameter. The Call object has a procedure name and it has the values of the input parameters. The name of the procedure maps to a Signature object which can be obtained from the CallManager and it contains the definitions of all of the parameters that are needed for the call. Thus, buildParamArray() obtains the Signature object and builds a ParamArray object with each of the parameter definitions in the Signature object. As it attempts to add each parameter to the ParamArray, it obtains a IValueHolder object to contain the parameter's input or output parameter value. It then checks for a corresponding input value in the Call object. If it finds a corresponding value it sets the input value in the ParamArray from this value. This is how the Call information in the XML file can specify the parameter values by name in any order and only specify the ones that have values associated with them.

//Extracted from buildParamArray() method.
//

CallManager manager = CallManager.getInstance();
Signature sig = manager.getSignature(getProcedureName()); //Get the signature for this call
if (sig == null) {
	throw new DynamicOpenClientException(...);
}
ParamArray params = new ParamArray(sig.getParameterCount()); //Instantiate a ParamArray object

int idx = 0;

// Iterate through all the parameters in the signature.
for (Parameter param : sig) { 

	// Instantiate an IValueHolder for this data type.
	IValueHolder<?> valueHolder = DataType.getValueHolder(param.getDataType());
	paramValues.add(valueHolder); // Put the value holder into the paramValues list.

	// If we can find a parameter value that was set for this call,
	// set the value of the IValueHolder to the input value.
	if (inputValues.containsKey(param.getName())) { 
		valueHolder.setObject(inputValues.get(param.getName()));
	}

Now that the data we need is available (ie, the parameter type information and input values have been set), we can go about setting the values, but we need to treat the TABLE and TABLE-HANDLE types differently from the the other data types. The reason is that they need a ProDataGraph and its metadata. The code for setting the values is therefore as follows:

Object value = null;
switch(param.getDataType()) {
	case TABLE:
	case TABLE_HANDLE:
		TempTableParameter ttParam = (TempTableParameter) param;
		ProDataGraphValueHolder graphHolder = (ProDataGraphValueHolder) valueHolder;
		ProDataGraphMetaData metaData = null;
		switch(param.getMode()) {
			case OUTPUT:
				// For a table we need the table structure. TABLE_HANDLE needs null.
				if (param.getDataType() == DataType.TABLE) {
					metaData = ttParam.getProDataGraphMetaData();
				}
				break;
			default:
				value = graphHolder.getProDataGraph();
				metaData = graphHolder.getProDataGraph().getMetaData();
				break;
		}

		// Add a parameter to the ParamArray with the appropriate value.
		params.addParameter(idx, value, ttParam.getMode().getModeCode(),
			ttParam.getDataType().getTypeCode(),
			ttParam.getExtent(),
			metaData);
		break;
	default:
		// Now get the object from the IValueHolder that has the value in it.
		value = valueHolder.get(); 

		// Add a parameter to the ParamArray with the appropriate value.
		params.addParameter(idx, value, param.getMode().getModeCode(),
			param.getDataType().getTypeCode(),
			param.getExtent(),
			(ProDataGraphMetaData) null);
		break;
}

The outer switch in this code handles the difference between TABLE, TABLE-HANDLE and other parameters. So skip the first cases and look at the default case (the last 11 lines of this code block from the word "default:" on. All this code does is grab the object that is in ValueHolder and assign it to the value variable. It then adds a parameter specifying the ordinal position (idx), the value, the parameter mode (INPUT, OUTPUT or INPUT-OUTPUT), the Progress DataType Code from the DataType, the extent and a null for the ProDataGraphMetaData.

The TABLE and TABLE-HANDLE cases are slightly more complicated. For a TABLE or TABLE-HANDLE if the parameter is either an INPUT or INPUT-OUTPUT parameter, the value has to be set to the ProDataGraph that will be used to contain the return value. The ProDataGraphMetaData needs to be specified to supply the table structure. In the case of an OUTPUT parameter, a TABLE parameter requires ProDataGraphMetaData but null in the value parameter and in the case of a TABLE-HANDLE, both the metadata and the value need to be null. In both cases, the Parameter object will have been specialized as a TempTableParameter object so that it could build the temp-table structure.

Once the parameters have all been added to the ParamArray, it is returned to the caller (executeCall) and is now ready to invoke the call.

runProcedure()

The runProcedure() method call is run on the AppServerConnection object that is contained in the CallManager. The AppServerConnection class performs 2 functions:

1. It stores the AppServer connection parameter values; and
2. It executes calls against the AppServer.

The first thing runProcedure() does is call obtainAppObject(). The OpenAppObject class provides access to AppServer connections from the connection pool and supports all communication with the AppServer. The obtainAppObject() call instantiates a Connection object and then an OpenAppObject if they have not already been instantiated. This establishes the connection to the AppServer.

Once the connection is established, the runProc() method on the OpenAppObject is run with the ParamArray that was passed in and any exceptions are thrown back to the caller. If this code completes successfully, the AppServer call has succeeded.

buildOutputValues()

After the call has completed, executeCall() calls buildOutputValues() with the ParamArray that was used in runProcedure(). 

//Extracted from buildOutputValues()
//
returnValue = params.getProcReturnString();
if (returnValue == null) {
	returnValue = "null/Unknown (?)";
}
int idx = 0;
for (Parameter param : sig) { // Loop through each parameter in the signature.
	switch (param.getMode()) { // Check the parameter mode.
		case INPUT_OUTPUT:
		case OUTPUT:

			// Get the value of the parameter from the paramArray.
			Object outputValue = params.getOutputParameter(idx); 

			// Set the value of the parameter in our internal array to be the result
			paramValues.get(idx).setObject(outputValue);
	}
	idx++;
}

The buildOutputValues() method does 2 things:

1. It obtains the value of the RETURN-VALUE string from Progress; and
2. It loops through all OUTPUT or INPUT-OUTPUT parameters and sets the value in the IValueHolder from the value in the ParamArray.

The output parameter values are thus available to the Call object for serialization. 

Why this is so powerful 

That is the crux of the code in the Dynamic OpenClient Sample Utility. It's not really that complicated and although this is a crude example, it does show the relative ease with which one can build a client that invokes calls for which all signature information is obtained at runtime.

If you work through the associated document that contains a description of running the utility, you will notice how easy it is to edit the ABL code and change temp-table structures or any other signature related information, modify the corresponding signature in the XML file and re-run the utility without changing the Java code.

If you go ahead and automate the generation of the XML signatures into a post-compile operation and post it on a web-server or some other centralized resource, there is never a need to change the Java code unless you discover a bug in it or Progress adds a data type.

There's another interesting side effect to this. It would not take much effort beyond this to build an automated mechanism for dynamic WSDL generation so that you dynamically expose any ABL procedure as a WebService. Taking it further, exposing it as an EJB or J2EE container or a JMS endpoint would be fairly simple too and would mean very little would ever need to be changed in the plumbing between the client and the server. You see, as far as I am concerned, everything related to ProxyGen is plumbing that should never require a recompile unless the underpinnings change. ProxyGen forces that each time a temp-table definition is changed.

Hopefully this example is useful. I am planning a .NET equivalent later on.

In order for the OpenClient to be able to connect to the AppServer, make a call and return the output parameters, there is a certain amount of code that you need on the client (Java or .NET) that wraps the OpenClient library. In an effort to simplify the process of writing that code, OpenEdge includes a utility called "ProxyGen" that parses the OpenEdge ABL code and generates a proxy class that wraps all of the code needed and exposes it as a simple method call. Once you have generated the proxy, you simply include the generated class in your code (either as a .jar or a .NET assembly, or even directly as source code) and you can make whatever call you need.

The problem with ProxyGen is that you have to regenerate the proxy and potentially rebuild the client each time the ABL procedure changes its signature. That would be okay if the ProDataset and Temp-Table definitions were not part of the signature, but they are and adding a field to a temp-table should not cause a proxy to break.

"Hang on, Bruce," I can hear you say, "Why is the signature of the temp-table not a change to the signature to the API?" I'm not saying that it isn't, but I am saying that it is far more difficult to avoid making this mistake. Here's why:

Typically, temp-tables that form part of the in-memory data model are defined in include files and then used in procedures and classes as in the attached diagram.

Let's assume that Procedure1.p and Procedure2.p are deployed to the AppServer and that Procedure1.p accepts the temp-table as an input parameter and Procedure2.p uses it as an input-output parameter.

As a result of a necessary change to the in-memory data model, a field or two are added to the temp-table definition for the purposes of the Class1.cls and Class2.cls.  As part of the build, the code is recompiled and the new code deployment to the AppServer is completed successfully. Note that there has been no planned change to the Procedure1.p and Procedure2.p.

The problem that we now face is that the proxies that were generated for the Procedure1.p and Procedure2.p are now invalid. The temp-table definition is no longer correct and a run-time error will now occur for the client when these procedures are called.

Another problem with proxies is the complexity associated with unit-testing and verifying each individual proxy. Each time a proxy is changed, each of the unit tests for each call in the proxy has to be rerun and retested. There is no way to generically test them to verify the Java/.NET code.

In one of the more recent versions of OpenClient, the API that the OpenClient uses is documented so that it is now possible to dynamically construct the proxy calls at run-time. The overarching benefit in this lies in the ability to now define the temp-table definitions on the fly. The Java/.NET code can now define the temp-table dynamically at run-time so that if a change is made to the definition, the client can deal with the change with no impact on the OpenClient source code.

This functionality is, in fact, so powerful that the entire signature, including all parameter definitions, can be discovered and defined at run-time.

This concept becomes even more interesting as you consider using it for WebServices. ProxyGen can generate the WSDL for a procedure that is to be exposed as a WebService, although it suffers from the same issues if the signature changes. The dynamic OpenClient API makes it possible to dynamically generate the WSDL at run-time from the procedure. Obviously there are overheads associated with auto-discovering a procedure's signature. It makes sense, therefore, to build out this functionality so that the signature discovery is done as seldom as possible.

In a future article I will provide some code samples that show you how to use the Dynamic OpenClient.

UPDATE: I have subsequently made this code sample available. You can refer to it here.

I was introduced to Progress while I was working for a small software house in South Africa, R-Data. R-Data had split from a company called Independent Software (no relationship to Independent Software in the USA as far as I know) and we re-developed the local government financial system in Progress to provide significantly greater functionality. When we finally rolled out the initial release of the product sometime in late 1990, we were using Progress version 6. I was involved in implementations of this system at several local governments throughout South Africa and also at the Ministry of Works in Malawi on a World Bank development project.

As I sit back and reflect on those days now, the thing that strikes me is that R-Data was based in Cape Town, several thousand miles from Malawi and a long way away from most of its South African customers. Despite this we were able to maintain these systems by means of 2400 baud modems with no on-site technical staff. Progress was just so solid and reliable that we had no problems with it.

Through the rest of the 1990s I did several consulting jobs using Progress and finally, in 1997, I went to work full time for a company that had an interesting problem to deal with. They had satellite offices all around South Africa and a centralized data center. The best network connection they could get for the remote offices was a 64K diginet line. Progress, now in version 8, had released the first version of the Progress AppServer. We decided to see if we could improve the application's performance using the AppServer. After some work re-architecting the way that we called procedures from the application, we rolled out the changes using the AppServer in late 1997.

I remember getting a phone call from one of the users the next morning. She had just performed an operation that had previously had a 30 – 45 second latency and was convinced something was wrong because the operation completed in less than a second. That has to be one of my favorite triumphs. The lady was ecstatic when I told her that I had fixed the problem she had been complaining about. The company that I was working for was able to save itself the cost of upgrading its diginet lines – at that time a very expensive operation in South Africa.

In 1998 I presented our experience at a Progress User Conference in London. Progress released version 9 shortly thereafter and I very quickly realized that the AppServer could be used in conjunction with Java. In 1999 Progress held a user conference in Boston where they showed the any-any-any model. Progress was going to become open. You could connect any client on any platform to any database using a Progress AppServer to handle your business logic. This was a really good idea. The preceding 10 years had taught me that Progress was an outstanding platform for writing the business logic that controlled your application and ensured your data integrity. I was sold. 

Then I was offered a job at Progress Software Corporation in the United States and my family and I moved to the US at the end of 1999. The AppServer and its future seemed to be something that I was going to be tied to.

Within 2 weeks of moving to the US, I went to the VP of development at Progress and told him that I believed Progress needed to forget about its focus on the client and concentrate on improving and growing the AppServer that could be used to build the best business applications in the world. Progress needed to provide tools and support to help Java and (then) VB developers to build applications based on the OpenEdge AppServer. I was shot down in flames. Who was this upstart anyway?

Over the next 7 years I worked at Progress on several efforts in their tools development group to help improve the process of building strong business applications. A framework called Progress Dynamics was released. While it held great promise on the business side, the user interface was based on Progress and was clunky. The ideas were revolutionary – store the UI definition in a repository and you could render it for any platform – client-server, the web, a mobile device, etc. Unfortunately the product was not well marketed and explained. Initial releases had significant performance problems that were improved later, but it tried to do too much. I still believe that Dynamics had a strong potential future, but it needed better vision to see it through.

Of course, Dynamics was not the only initiative. Progress then decided to use Eclipse to build their equivalent of the JDT – the PDT – for developing Progress applications. The PDT was (and is) sold as OpenEdge Architect and while it does a good job of helping you build Progress code, it does little or nothing to help you build applications that use the AppServer.

Eclipse has recognized that the JDT is not enough for Java. You need an Eclipse for Java EE to build enterprise class applications and in the same way that Java EE provides Glassfish as its application server, so the Progress AppServer needs its own set of tools around it so that application development against an AppServer is not that complex.

In 2006 Progress embarked on a project to integrate the .NET user interface into the Progress execution environment to provide an improved user interface for Progress. Progress would host the .NET CLR and the user interface would be able to interact directly with Progress objects. At the user conference later that year I presented a preview of what were looking to build in conjunction with the lead architect on the project – a lady for whom I have immense respect.

The problem, though, with hosting the CLR is that Progress takes on the responsibility of keeping up with what Microsoft is doing and it ties itself to Microsoft platforms. Moreover, no matter how much Progress tries to hide the internals of .NET from its customers, exposing the .NET UI forces those customers to learn something about .NET and its control mechanism.

Progress does not have the budget to spend on UI development that Microsoft does. It does not have the open source community to build out the Rich Client Platform the way that Eclipse does. It also does not have the authority to drive the industry's UI direction that either Java or .NET do. At the time that I became involved in the .NET integration project, I was of the opinion that Progress should concentrate its resources on exposing the business logic components to Microsoft and Java objects inside the Progress execution environment and let developers choose which of these it wanted to use to build the front-ends to their applications. Ideally, a set of extensions to the Progress OpenClient that would allow easier AppServer-based development.

In terms of development effort from Progress' point of view, the OpenEdge AppServer is all but forgotten. Like WebSpeed before it, Progress has done little to improve and enhance this product so that it can be used in a large, scalable environment. There has been little done to its basic functionality since the last major changes to support a state-free operating mode for WebServices and I believe the release of that was in around 2004.

After I left Progress in July 2006, I joined a company that is using the OpenEdge AppServer in a reasonable sized configuration. I would not call it a big installation, but it is big enough to demonstrate the successes and flaws of the OpenEdge AppServer. In this environment I was forced to contend with communication with the AppServer from a Progress, Java and .NET source. I have learned a lot about the OpenEdge AppServer in this process.

Although the technology is maligned by many for its lack of scalability, I have found that it provides acceptable performance if the application is properly designed to leverage the AppServer. It also provides a very simple way to expose Progress code to other technologies and the communication between Java or .NET and the AppServer is solid – solid enough to build  a commercial application with. 

In one of the later versions of OpenEdge 10 (I believe it was 10.0B ), Progress introduced the dynamic OpenClient which does away with the need for a tool called "Proxygen". Proxygen requires the generation of a Java/.NET class that is incorporated into your Java/.NET code as a library in order to access the remote 4GL/ABL procedure. With the dynamic OpenClient this is no longer necessary and if you build a truly dynamic client, the AppServer becomes an easily accessible tool for deploying business applications.

As a result of the dynamic OpenClient, I am now able to make use of the OpenEdge AppServer and can expose it to Java, .NET, JSP, ASP.NET,  OpenESB and PHP. These are just the technologies that I am using right now. Moreover, I can get at the OpenEdge AppServer from Eclipse, Eclipse RCP applications, Eclipse eRCP and Eclipse RAP. This gives me the portability to move my user interface to virtually any modern desktop and I can avoid having to be tied into Microsoft Vista. Heck, one of the applications I have built runs on my Mac. 

What's interesting is that the tools that I have built for myself to be able to do this have ended up being plugins to Eclipse or add-ins to Visual Studio. There are not a lot of them, but they greatly simplify my ability to build applications based on the Progress AppServer – the technology that Progress saw as its strategic direction in 1999.

Ten years later, it seems that Progress has never realized that vision. The thing that Progress developers need to do is build better business applications. Their focus is the business logic. The business logic runs on an AppServer. Developing, testing and deploying code for the AppServer is still really hard for a Progress developer to do – much harder than it is for a Java developer building business logic to run on Glassfish. True, any client on any platform can talk to any database through the Progress AppServer, but the technology to do it is still in its infancy ten years later.