Comment The Future of WebSpeed...

[Cecil]

After my little visit to Australia last week I attended a Progress Software presentation; "The Road to the Future". I got the general consensuses that WebSpeed is not going to be a retied, but at the same time no new development, apart from bug fixes.

However progress are going to release a improved Unified AppServer which is going to be multi-threaded/multi-session. But this does not apply to the WebSpeed Brokers/Agents (Doh.)

To take advantage of the NEW Unified AppServer, the recommendation was to change the architecture of your web development. Make the client Web Server calls using Javascript via Apache Tomcat. Tomcat then makes calls to the Unified AppServer using JAVA (eek).

So you could have a mix of both WebSpeed and Tomcat+AppServer (which is essentially the OpenEdge Rest Server) but that could just get messy. Or make the development leap and go exclusively Tomcat/OE Rest. If you are like me and don't know much about Tomcat this could be a big learning headache.

What's your opinion about moving away from WebSpeed to OpenEdge REST Server??

 

[mollyfud]

Someone reposted your question and an answer (of sorts) is available here : https://community.progress.com/technicalusers/f/26/t/9209.aspx

 

[Cecil]

I listen the video I and it does seams that the WebSpeed (_progress -web) will also be made multi-thread but not before AppServers (_proapsv) is released first.

Now since WebSpeed is essentially _progress in batch mode, will that mean all _progress instance be multi-threaded, GUI & CHUI? Or is there going to be a whole new exclusively developed executable for WebSpeed to make it multi-threaded? Time will tell.

 

[mollyfud]

Don't think about it as Multi-threaded as in you would be able to send multiple pieces of work down different threads and return together but my (poor) understanding is that instead of having a process for each "agent", there will be a thread for each agent/whatever they are called in the new world/AppServer.

 

[TomBascom]

Correct. The MT features of the new app server do NOT mean that 4GL clients will be in any way multi-threaded.

 

[Cecil]

Don't think about it as Multi-threaded as in you would be able to send multiple pieces of work down different threads and return together but my (poor) understanding is that instead of having a process for each "agent", there will be a thread for each agent/whatever they are called in the new world/AppServer.

I'm under the impression that AppServer side code will process faster because the underlying _proapsv executable was to become multi-threaded. Meaning the process can span across a multiple CPUs rather than just one CPU. Have I got it right?

 

[Cecil]

I think I'm getting myself confused between Multi-Threaded and Multi-Session. The the new Unified AppServer will fork a new ABL Session which will maintain context-state each time you reconnect to the AppServer. How would this be faster?

 

[TomBascom]

It won't be faster. At least not so far as any particular bit of 4gl running in the app server is concerned.

But connecting to the app server should have less overhead -- much like current statefull connections. So the overall impact may be that your application as a whole benefits.