OpenEdge AppServer – Exposing Progress OpenEdge

The last 20 years of my life have ben spent working with Progress Software in one form or another. I started work with Progress (now OpenEdge) in 1989 in Progress version 4. I transitioned to it from MicroFocus COBOL after having cut my teeth programming in Basic and COBOL.

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.

4 thoughts on “OpenEdge AppServer – Exposing Progress OpenEdge”

  1. It was a pleasure to red your text! I agree with you specially on the Dynamics comments, as I was at the ICF Kick Start in the past 2001 and I see the product being forgotten too…
    Hope to talk to you soon!

  2. Hi, I am just learning some OpenEdge and trying to figure out how to send a call to an existing appserver on a remote server using VB .net. I’ve found a lot of articles talking about proxygen, but just can’t seem to find any that dumb it down enough for me to do it step by step. Seems like you know how to do this and was wondering if you had any references I could look at? Thank you!

    1. Not offhand. I have never thought very highly of Visual Basic as a programming language and have never really used it to build anything commercial-grade.

      I have used ProxyGen a couple of times to build proxies for OpenEdge connectivity, but I find keeping the code up to date to be a nuisance and so have built a dynamic client for Java that does the work for me. The code could be ported to .NET, but I have not had time to do that port, although I do have something coming up in the next few months that is likely to require it.

Come on... Argue with me about this...