In another forum I read the following by David Cleary, when discussing APSV
>> It is the same protocol we created for Classic AppServer that assumes a persistent socket connection between client and server. We have a feature in our backlog to create a truly stateless APSV transport
My impression is that APSV over HTTP was a convenient way to facilitate the migration of openclient applications from "classic" appserver to "PASOE".
But I'm wondering if the "APSV" transport has any merit for any other reason. I.E. now that everything rides over the tomcat server anyway, couldn't Progress simply change the proxy assemblies and API's so that they don't use "APSV" anymore under the hood? Couldn't the openclient applications use proxy assemblies that spoke with the server via SOAP or REST instead, but had a similar external API? Does the legacy APSV transport have some special functionality or performance benefits? Can't the same thing be accomplished with open technologies like SOAP or REST that are also built on HTTP?
IMHO APSV is just a means to an end. Our apps have been talking that protocol for twenty years but my proxies are an abstraction above that - and don't care one way or the other about the APSV transport unless there is a bug or a performance problem.
I'm wondering if it actually makes sense for Progress to continue with their proprietary APSV. There are alternatives. It wasn't long ago when everyone was hyper-fixated on SOAP, then on REST, and now I'm hearing a lot about GRPC (https://stackoverflow.com/questions/43682366/how-is-grpc-different-from-rest ). These are open source options and well-understood in the wider world of software development. I often wonder why Progress OpenEdge would invest in a proprietary solution like the APSV transport, when open-source techniques are readily available. Now that Progress has moved to an open-source platform like tomcat, then why not use an open-source alternative to APSV as well?
If someone outside the OE community were to ask an OE developer why the PASOE applications use APSV over HTTP then most of us wouldn't know what to say other than that it is legacy baggage that was left over from "classic". Perhaps we just need to give that a different spin. Perhaps the Progress APSV transport giving us a 3x performance improvement as compared to SOAP/XML or REST/JSON.