Products Similar to Progress AppServers

Question

I work in Progress ABL and use what we call AppServers. Application Servers, processes that can talk to a Progress database and run business logic on the on a server and then send a response back to the client.

These come in 4 modes but I'm most accustomed to state-reset which is an appserver that preserves state throughout the connection and state-free which is a fire and forget mode.

This product is highly proprietary with compatibility with other clients such as .net.

My question is, are there any solutions out there that are pure .NET that do the same thing. I'm not talking about doing ASP.net or web services as they address a different problem. I want something that can run code that can connect to a database and transmit back responses without writing my own system.

Example of running code on an AppServer.

define variable handleToAppServer as handle no-undo. define variable charResponse as character no-undo.

run 'AppServerProcedure.p' on server hAppServer (output charResponse).

Answer 1

To be honest, I am not sure I understand what the actual problem is.

If you are concerned about having a client application being able to connect to a seperate DB server, this is actually the norm, not the exception. Just use any JDBC/ODBC bridge and you may have your code executed on the client with just the data being moved to and from the network.

If you want your logic to be executed on the remote server (your example with the procedure invocation on a named AppServer would suggest the latter) then the basics are the same, i.e. use ODBC to connect to the DB server, and move most of your logic to Stored Procedures.

(I think that what you are looking for goes by the name "stored procedure" in most modern RDBMS: i.e. complete code units, either functions or procedures, that are run exclusively on the DB server itself. They can be invoked remotely by clients, but use memory and computing resource on the DB server).

This is, again, a pretty standard architectural choice when working with DBs. Progress ABL/4GL has a mixed-paradigm model that may muddle your perspective a bit (if memory serves, APPServers are processes that run as some sort of headless "super-clients" and there is no concept of "stored procedure", i.e. code run inside the DB itself, except possibly triggers).

Answer 2

I'm a longtime ABL developer and I think this is an excellent question. I also use C#, I like and respect both platforms. But, I've never really understood how a C# developer would do what the OP describes and seems so simple in P4GL.

The above response from p.marino assumes that you can do what you want to do with SP's. That is often the case, sure, but us ABL developers are used to doing things far beyond what you can achieve with SQL.

So, if I want to write business logic in C# and have it execute remotely, but not as a SQL SP, what are my options? .NET Remoting, Web Services, or .NET Enterprise Services maybe? I don't think any of those are as straightforward as ABL AppServers, and none of them with the possible exception of WS seems to have a lot of traction.

(Lest I sound like a P4GL fanboy, their GUI totally blows, their tools are disgusting, and the licence fees are rather exorbitant. I'd write GUI in C# or Swing over P4GL anyday. But remote business logic... I'm not so sure).

Answer 3

Progress app servers are like db & ui neutral containers for logic. They run on their own rather than as a part of Oracle or as a part of SQL Server or whatever and they don't care if the client is .NET, Java, WS or a green screen. They don't require a db connection but they can connect if that is the appropriate thing for them to be doing.

The original questioner doesn't seem to want most of these features and, from the sounds of things, would probably be satisfied with stored procedures in the db of choice.

There is one other feature that might matter to the original question -- the real reason why Progress programmers like app servers is probably because it gives them a single programming language to work with. If you start using stored procedures you will need use a different language than the one that you code your UI in. And each target db will have its own language and quirks thereof to work through.

(Progress triggers run on the client, not inside the context of the server. So they aren't very stored procedure like.)