The OpenEdge Hive

"Transformation" has become an increasing popular topic among Progress' Application Partners and end user customers with responsibility for their own legacy applications. This blog will be an on-going discussion of topics related to transformation including, but not limited to, different types of transformation, transformation strategies, transformation tools, and anything else which might help a company with a legacy ABL application decide how and what to modernize.

This category will be used to discuss principles of building UI components, sample UI component code, and helper classes for ABL UI.

It may be necessary or appropriate for us to subdivide this are according to the UI technology since contributions might deal with a variety of technologies.

This category will be used to discuss principles of building UI service components, sample UI service component code, and helper classes for UI services.

UI services are components which run on the server and provide an interface between clients and the business logic layer. They contain no UI themselves. It is likely that some will be specific to a given UI and will serve to isolate the business logic layer from the specifics of the particular UI. Some may be UI independent.

This category will be used to discuss principles of building enterprise service components, sample enterprise service component code, and helper classes for enterprise services.

This category will be used to discuss principles of building business logic components, sample business logic component code, and helper classes for business logic.

This category will be used to discuss principles of building data access components, sample data access component code, and helper classes for data access.

For initial background reading, consult OERA Strategies: Object-Oriented or Not?

Bruce Gruenbaum:
Let me start out by saying that this is service that hitherto has not worked as well for me in OpenEdge as it does in Java/.NET. In a nutshell, it is a service that is responsible for receiving exceptions that have been caught somewhere. The Exception Handling Service receives the exception, logs it to an exception log and then looks for a class that has been designed to process the exception in some way. The trick is to have a standard way of processing all exceptions so that the user never experiences a Java/C#/OpenEdge exception/error condition that has not been handled.

Bruce Gruenbaum:
The Auditing Service logs access and changes to data and stores away the state of the data at the time that an event took place. It is subtly different from logging in that logging is about keeping track of the fact that things happened whereas auditing is about keeping track of exactly what happened.

Thomas Mercer-Hursh:

Bruce Gruenbaum:
The Caching Service is responsible for storing data that may be referred to at a future point in time by this physical session and thereby reduce processing time. Caching with OpenEdge is simply a store of data. In muti-threaded environments, the cache can be self cleaning based on a LRU algorithm or something similar.

Thomas Mercer-Hursh:

Bruce Gruenbaum:
The Context Management Service is designed to keep track of data that is needed to reestablish a logical session's context on subsequent interactions with a target. People will argue whether context should be stored on the client or the server or both. In my experience, a framework has to provide support for all three options - client, server and both. If one views a set of interactions with a set of targets as a set conversations, context management is about determining where you last left off in the conversation with a specific target.

Thomas Mercer-Hursh:

Bruce Gruenbaum:
Session Management and Context Management are closely related but subtly different. A client may have many connections to several different targets. Each of those connections may be termed a session and its lifetime is the duration of the connection. That is a physical session. Many times though, the client makes repeated connections to a target and often to more than one target at a time. It may often be possible to reduce the amount of processing time involved by reusing an authentication token. Thus a logical session may span many connections to many different targets. The Session Manager is responsible of tracking data that is related to the logical session.