Moving away from Persistent Procedures

A common approach is to use small facade procedures as the thing one runs directly on the AppServer.  The facade procedure then runs main procedures, internal procedures, accesses IPs of already reunning library procedures from session startup and so on as required to perform the task.

One of the key questions here is to ask yourself why these IPs are bundled into the larger PP.  If it is simply a case of bundling a bunch of vaguely related utilities in  a single package, then to access them across the AppServer you will typically want to unbundle them, unless they are part of a library routine that is started with the session.  If they are intimately connected parts of a whole, i.e., like methods of some object, then you need to think about your architecture and decide on what side of the AppServer boundary this "object" should exist.  Depending on purpose and your architecture, it may be that it belongs on the client side with adaptations to obtain data via the AppServer or it may belong on the server with a facade to access it remotely.  If the latter, you may want to be looking at Sonic or Fuse in addition to AppServer since that allows you to publish long running processes as a service.

Note too that in 11.0 or 11.1 we are supposed to get AppServers with "portable" context, i.e., the ability for an AppServer session to save context in an in-memory database and have a later AppServer call retrieve that context via a session ID.  You can do that today by storing context in a database, but the coming feature should provide better performance and a lighter weight implementation.

The approach you mention is what I was leaning towards with the small facade procedures. The procedures and their current state of having many bundled IP's in them was a case of "good intentions gone bad". Sonic is something I have been reading up on lately and may be the path we follow but that is TBD at this point. Thanks for the reply as I will be following your advice!!

Hi Brad,

It is good to know you are moving to GUI for .NET and a state free AppServer. If you do not have any state stored in the persistent procedure then it would be best to create a single running instance of the persistent procedures on each agent at startup and manage access to it through a global handle (or other mechanism). This is a typical singleton pattern. The key is making sure the internal procedures do not depend on any state information from block 0.

On the OpenEdge roadmap is implementing a singleton pattern for procedures so you would not have to worry about getting the singleton procedure up and running on each agent. We would do that automatically which also means that all singleton procedures would not be run until needed.

-Shelley

On the OpenEdge roadmap is implementing a singleton pattern for procedures so you would not have to worry about getting the singleton procedure up and running on each agent

Hi Shelley, I hope OO language enhancements like dynamic property access and object serialization to be able to pass (parameter) objects between AppServer and client are higher prioritized on the roadmap.

A typical "singleton" pattern for persistent procedures is based on GLOBAL SHARED variables which serves well in many frameworks (including the Progerss supported Dynamics).

In addition to all the great advice you've already received, check out the documents related to the OERA & OERI as well as the AutoEdge sample which illustrates exactly what you're trying to achieve.  All this stuff can be found here : http://communities.progress.com/pcom/community/psdn/openedge/architecture

mikefe schrieb:
On the OpenEdge roadmap is implementing a singleton pattern for procedures so you would not have to worry about getting the singleton procedure up and running on each agent
Hi Shelley, I hope OO language enhancements like dynamic property access and object serialization to be able to pass (parameter) objects between AppServer and client are higher prioritized on the roadmap.

How could I forget about Interface inheritance.

Dynamic properties and interface inheritance are planned for 11.0. It does not look like single run procedures or OO serialization will make 11.0.

-Shelley

You might want to check out http://www.cintegrity.com/content/ESB-Application-Architecture for some ideas about using ESB in the context of a single application.  Might be one or two other ideas of interest over there too.

But, don't take AutoEdge as a model for how you should do your application.  Look at it, discuss it, think about how you want to do it, talk to us about it.  It is training material, not a model for a production system.

Dynamic properties and interface inheritance are planned for 11.0. It does not look like single run procedures or OO serialization will make 11.0.

Can't wait for the beta

Looks like I have some reading and code review to do. I have actually read some of the documents related to OREA, at Cintegrity, installed AutoEdge etc. Lots of information to look at. The more I read about Sonic the more interested I have become as well although management is looking more for lipstick and I want to at least get a infrastructure however robust or not it may be at this point in place that we can build upon and more easy refactor in the future as needed. Since this module/application is one of the smaller ones currently it makes sense to me to lay some solid foundation and build based on it. I would love to see the ability to instantiate a class on the appserver without the use of a helper.p.

I discussed some of the responses with some of the development team members and the question was ask: In the real world, an n-tier environment using Appserver, Sonic, Fuse etc...where the UI is completely dumb to the data BE's/Services are in place do you, anytime you need to poll the DB whether that is to marshall a dataset, TT or even a logical value based on a find on record do you make a call to the server side via AppServer or Sonic everytime? Or are there cases where you may do a DB lookup because you need to get a single value or set a logical value for further processing and this is done in the Business Enity client-side. Some where questioning why go to the server for every request and I could not provide a good answer??

It really does depend on the nature & type of your client.  There are models where if the client has the ability to cache or store data locally (such as an OpenEdge client using an MVP model) then whenever possible you service the call client-side first out of it's cached data, only making server requests when the requested data isn't available client-side.  But if you're in a stateless model where the client is not capable of storing any form of data locally, then of course that data has to come from someplace, and that place is the server.  Just in the same way that many browser based applications work, even if your using ajax or whatever to mask the fact and to avoid refreshing whole screens, your ultimately still making calls to a server to get data.

Caching is an art in itself and where to cache is its own question.  Caching strategies depend a lot on the type of data.  Something static, like a table of state or province codes, is a good candidate for caching because it hardly ever changes.  But, it can be sensible to cache more dyncamic data as well, depending on the structure.  For example, suppose you have one server which handles order processing and one that handles inventory.  The OP server is going to need information on stocking levels, so one approach is to build a cache in response to need, update that cache locally with provisional allocations, then have some strategy that refreshes the cache from the IC server periodically.  E.g., the OP server might send a message to the IC at the completion of the order which does the actual allocation of inventory in IC.  The IC server might then respond, sysncrhonously or, better, asynchronously, with a message to update the cache, thus keeping it in sync.  But, if you have three OP servers, this strategy falls apart because each has no idea what the other is doing, so you either need to get your availability from the IC server directly or you need to create a cache server for the purpose.  Which is better will depend on issues like the physical distribution of the servers, e.g., are there any slow connections.

In a couple of days I will be posting a talk I just presented to the WaPUG on OERA with some practical suggestions about how to think about layer design and layer communication.  That might help.

The talk is now available here http://www.cintegrity.com/content/OERA-20%0B-I-concept-now-what-do-I-do