I now have a couple of months experience using PASOE. I see that Progress deserves a lot of credit for integrating its appserver technology into Apache Tomcat. Many of the new features of PASOE are available because of the Tomcat platform itself. I found a pretty good presentation of the benefits of PASOE as compared to "classic appserver": http://pugchallenge.org/downloads2015/433_Migrating_to_PASOE.pptx
As-of now, we don't see ourselves using the other new transports yet (REST, SOAP), and will probably stick with APSV for a year or two. Given that we will use APSV, I'm trying to determine if there is still a compelling reason to use PASOE instead of classic appserver, especially considering the additional cost. I've been focusing primarily on innovations that Progress has introduced into their own "MS-AGENT" in PASOE, rather than the many improvements they've realized as a result of using the tomcat platform.
Most of the "MS-AGENT" innovations can be found in the powerpoint presentation above, starting on page 15 ("Architecture: Multi-Session Agent"). They are as follows:
Faster and optimizes resources (Runs same ABL application and client load with less memory and CPU consumption)
Am I overlooking any other significant innovations in the "MS-AGENT" itself? Outside of the MS-AGENT, I can also identify some other general benefits that will be realized, even for legacy APSV-based applications:
This is the list of innovations that would impact our legacy APSV applications. There are some that are found inside the "MS-AGENT" and others that are outside (part of Tomcat, PDSOE, Progress OE Manager Webapp, etc).
It would be helpful to hear if I overlooked anything. We are in the process of trying to evaluate the cost/benefits of using PASOE instead of "classic appserver". I think PASOE is appealing, and has many features that classic appserver should have introduced by now - if Progress had continued to invest in it over the years. I think we've been using classic appserver for 15-20 years... for nostalgia sake I was recently reading the OE 9.1E docs for "classic appserver". It is very applicable today, even when using OE 11.6. (I think the OE 9.1E docs omit information about out some of the stuff about session-free/state-free, but other than that, they accurately reflect the "classic appserver" product as it works today.)
Well, what I find a very big plus is that an PAS instance can be created and maintained entirely from the CLI.
That said, I faced a customer situation where a trade in of the Classic AS licenses wasn't possible (due to the underlying contract) so PAS had to be purchased all over. With some licensed 850 users that was a bit hefty, so I didn't even suggest it to the customer. Even an upgrade would have set them back around €30k to 40k. So, no WEB transport, no better resources utilization. etc. :-(
Good point about the CLI. That probably comes in handy, especially if the instance is deployed without adminserver and is not managed via OEE/OEM.
Are there only the two variations of PASOE : production and development? I was thinking the other day that it might be nice to have another version of the production PASOE which would be limited to the APSV transport, without any of the other "bells and whistles". Perhaps Progress could make it available to existing classic appserver customers in a cost effective way. (So customers might finally get out of the classic appserver, which seems to be a pretty outdated technology, and hasn't seen any recent innovation.)
As you say, it is costly to move from the old appserver to the new. Progress seems to consider PASOE an entirely different product than classic appserver. But it accomplishes the same goals so it is hard to explain to management why we should need to "purchase all over again". In general we think of PASOE as an updated version of classic appserver and has the features that classic appserver might have today if it had been receiving a bit more TLC (ie. better resource utilization, multi-session threading, etc).
If you look beyond the differences introduced as a result of tomcat, it is surprising how similar classic and PASOE really are. For example, it was interesting to notice that even our "event procedures" (session startup, shutdown, connect) can be run unmodified, and they share the same set of calling parameters as the classic appserver.