P
PhilF
Guest
[quote user="Robert Cohen"] have been trying for a while to find out what I tools and software I need in order to start developing in Webspeed, or what is Progress Developer studio vs. Progress Studio, What is need to create a REST service or some Java connection through the existing Tomcat service I have. I have found this quite difficult to find this information [/quote] Those are great questions, Robert. I'm not sure I have all the answers, but here are a few notes that might help. Possibly it's more than you want to know, in which case I apologize. 
Progress does not speak REST directly; you create code that responds to specific calls (typically with Progress Developer Studio for OpenEdge), and then deploy it on an AppServer -- either Classic or Pacific. The AppServer matches the incoming requests to the ABL methods. If you don't have PDSOE, I will mention that you can do this the hard way: A couple of years back I was having no luck deploying from PDSOE, so I took a working deployment and painstakingly modified it to meet my needs. (This includes making changes to certain zipped resources within the deployment.) Not recommended, but it was an emergency, and it worked. WepSpeed was once a separate product, but now it is bundled into the AppServers. If you have it, you can create WebSpeed code with "vi" or any other tool you choose. There are various ways that the web server can call your WebSpeed code, including CGI. (Note: The new Pacific / OpenEdge App Server includes both WebSpeed, and a working web server; no need for CGI scripts or anything like that.) I think it would be difficult to deploy a Progress REST service to an existing Tomcat installation without an AppServer; you would have to hook in something that runs Progress -- sort of building your own AppServer. But like many such things, it can probably be done if you are both clever and desperate enough. As for the two Studios: I have lost track of the older editions but Developer's Studio is the newer Eclipse-based product I thought I would check the web site to remind me of the details -- but these are completely missing from the Progress Products web page ( ) , Appropriate to the topic at hand, no? Not that you asked, but: There are also DIY alternatives, if you are limited in the resources you can purchase or deploy onto your system. For instance, Progress is powerful enough to listen to port 80 and to respond to web requests directly, but you lose all the advantages of working in a highly tested and stable multi-threaded web-server as your front end. you can create web pages or even handle REST requests. But your ABL program is single-threaded, and if it dies for any reason you are responsible for making sure it respawns. There is also sample code for interfacing OpenEdge to node.js. (See the PUG Challenge America conference site -- PUG Challenge Americas and search for node.js on the download sites for 2013 and 2014,) I played with the node4jprogress code some years ago as a way to have some live web-based dashboards at a site that had only a Progress Runtime License. Among other things, node.js handled request queueing; it was a cheap and effective alternative to an AppServer in this simple and low-activity environment. I hope that something here is helpful to you, -- Phil
Continue reading...
Progress does not speak REST directly; you create code that responds to specific calls (typically with Progress Developer Studio for OpenEdge), and then deploy it on an AppServer -- either Classic or Pacific. The AppServer matches the incoming requests to the ABL methods. If you don't have PDSOE, I will mention that you can do this the hard way: A couple of years back I was having no luck deploying from PDSOE, so I took a working deployment and painstakingly modified it to meet my needs. (This includes making changes to certain zipped resources within the deployment.) Not recommended, but it was an emergency, and it worked. WepSpeed was once a separate product, but now it is bundled into the AppServers. If you have it, you can create WebSpeed code with "vi" or any other tool you choose. There are various ways that the web server can call your WebSpeed code, including CGI. (Note: The new Pacific / OpenEdge App Server includes both WebSpeed, and a working web server; no need for CGI scripts or anything like that.) I think it would be difficult to deploy a Progress REST service to an existing Tomcat installation without an AppServer; you would have to hook in something that runs Progress -- sort of building your own AppServer. But like many such things, it can probably be done if you are both clever and desperate enough. As for the two Studios: I have lost track of the older editions but Developer's Studio is the newer Eclipse-based product I thought I would check the web site to remind me of the details -- but these are completely missing from the Progress Products web page ( ) , Appropriate to the topic at hand, no? Not that you asked, but: There are also DIY alternatives, if you are limited in the resources you can purchase or deploy onto your system. For instance, Progress is powerful enough to listen to port 80 and to respond to web requests directly, but you lose all the advantages of working in a highly tested and stable multi-threaded web-server as your front end. you can create web pages or even handle REST requests. But your ABL program is single-threaded, and if it dies for any reason you are responsible for making sure it respawns. There is also sample code for interfacing OpenEdge to node.js. (See the PUG Challenge America conference site -- PUG Challenge Americas and search for node.js on the download sites for 2013 and 2014,) I played with the node4jprogress code some years ago as a way to have some live web-based dashboards at a site that had only a Progress Runtime License. Among other things, node.js handled request queueing; it was a cheap and effective alternative to an AppServer in this simple and low-activity environment. I hope that something here is helpful to you, -- PhilContinue reading...