Cobol web development/hosting resources [closed]
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this questionI'm employed at a fairly big company here in Germany and got the job to create the main website for it which will feature:
- Static contents; Information and Presentations
- An employee area (around 6000 employees) featuring various things from calendars, job descriptions, some sort of gr开发者_如何学Gooups
- Too many other dynamic things I can't list here
I have decided to use COBOL for the job, it may be very underrated but it is a very powerful language, especially for business apps and, as my co-workers say, web (2.0) development too.
I also need to use COBOL because all the backend and transactions system of the company is programmed in it (some small parts were programmed in LISP too, I don't know exactly why). I also have received an API that makes it possible to use COBOL with MySQL easily.
This is a big project and it will probably take more than 2 months programming it.
- What do I have to expect when building a huge web app in COBOL?
- Are there web frameworks for COBOL available? Some sort of MVC?
- Are there any good resources for practical web-development with COBOL?
Thanks in advance
What do I have to expect when building a huge web app in COBOL?
It will take a long time. Frameworks like Django, Ruby on Rails or CodeIgniter are designed specifically to create web sites in very little time.
Most of these frameworks can build working dynamic content web sites in 20 minutes. COBOL cannot. Unless you can type really quickly, you'll probably have very little workable code in the time you could learn and build a site with any more modern tool.
Are there web frameworks for COBOL available? Some sort of MVC?
Asking this question now indicates that the choice of using COBOL is a really, really bad idea.
The usual strategy is to chose the framework first. After making the framework choice, we endure the language required to leverage that framework.
However, there's always http://www.coboloncogs.org/HOME.HTM
Are there any good resources for practical web-development with COBOL?
http://search.barnesandnoble.com/COBOL-Programming-Using-the-NET-Framework/Ronald-D-Reeves/e/9780130668431
Practical web development is done with web-specific frameworks. Any of the dozens of Python web frameworks, Ruby on Rails, any of the PHP frameworks, any of the Java frameworks. They're highly specialized to build web sites quickly and cheaply.
COBOL is not highly specialized for this. Nor (outside the i-Series) does anyone seriously consider COBOL for web development.
Your best hope would be to use as many external libraries as possible and write as little COBOL as possible. You have to make heavy use of the COBOL to C features of OpenCOBOL to work with the C-language API's and -- in effect -- build your site in C with a COBOL wrapper.
Please, please, please do not use COBOL for this. Anyone who has to support the site in the future will thank you for choosing a more... modern tool.
I recommend that you use a web framework to write the front-end, such as PHP, ASP.NET MVC, etc. Then create an API (or a separate process with some sort of an interface, if required) that will allow that tool to talk to your COBOL back-end. This will allow you to use the web framework on the front end - where it will shine - while allowing you to leverage your company's significant investment in COBOL.
Having posted the OpenCOBOL sample for CGI and AJAX, I'd just like to add, go for it. COBOL can do frontends.
>>SOURCE FORMAT IS FIXED
******************************************************************
* Author: Brian Tiffin, Francois Hiniger
* Date: 30-Aug-2008
* Purpose: Display the CGI environment space
* Tectonics: cobc -x cgienv.cob
* Move cgienv to the cgi-bin directory as cgienv.cgi
* browse http://localhost/cgi-bin/cgienv.cgi or cgienvform.html
******************************************************************
identification division.
program-id. cgienv.
environment division.
input-output section.
file-control.
select webinput assign to KEYBOARD.
data division.
file section.
fd webinput.
01 postchunk pic x(1024).
working-storage section.
78 name-count value 34.
01 newline pic x value x'0a'.
01 name-index pic 99 usage comp-5.
01 value-string pic x(256).
01 environment-names.
02 name-strings.
03 filler pic x(20) value 'AUTH_TYPE'.
03 filler pic x(20) value 'CONTENT_LENGTH'.
03 filler pic x(20) value 'CONTENT_TYPE'.
03 filler pic x(20) value 'DOCUMENT_ROOT'.
03 filler pic x(20) value 'GATEWAY_INTERFACE'.
03 filler pic x(20) value 'HTTP_ACCEPT'.
03 filler pic x(20) value 'HTTP_ACCEPT_CHARSET'.
03 filler pic x(20) value 'HTTP_ACCEPT_ENCODING'.
03 filler pic x(20) value 'HTTP_ACCEPT_LANGUAGE'.
03 filler pic x(20) value 'HTTP_COOKIE'.
03 filler pic x(20) value 'HTTP_CONNECTION'.
03 filler pic x(20) value 'HTTP_HOST'.
03 filler pic x(20) value 'HTTP_REFERER'.
03 filler pic x(20) value 'HTTP_USER_AGENT'.
03 filler pic x(20) value 'LIB_PATH'.
03 filler pic x(20) value 'PATH'.
03 filler pic x(20) value 'PATH_INFO'.
03 filler pic x(20) value 'PATH_TRANSLATED'.
03 filler pic x(20) value 'QUERY_STRING'.
03 filler pic x(20) value 'REMOTE_ADDR'.
03 filler pic x(20) value 'REMOTE_HOST'.
03 filler pic x(20) value 'REMOTE_IDENT'.
03 filler pic x(20) value 'REMOTE_PORT'.
03 filler pic x(20) value 'REQUEST_METHOD'.
03 filler pic x(20) value 'REQUEST_URI'.
03 filler pic x(20) value 'SCRIPT_FILENAME'.
03 filler pic x(20) value 'SCRIPT_NAME'.
03 filler pic x(20) value 'SERVER_ADDR'.
03 filler pic x(20) value 'SERVER_ADMIN'.
03 filler pic x(20) value 'SERVER_NAME'.
03 filler pic x(20) value 'SERVER_PORT'.
03 filler pic x(20) value 'SERVER_PROTOCOL'.
03 filler pic x(20) value 'SERVER_SIGNATURE'.
03 filler pic x(20) value 'SERVER_SOFTWARE'.
02 filler redefines name-strings.
03 name-string pic x(20) occurs name-count times.
procedure division.
* Always send out the Content-type before any other IO
display
"Content-type: text/html"
newline
end-display.
display
"<html><body>"
end-display.
display
"<h3>CGI environment with OpenCOBOL</h3>"
end-display.
display
'<a href="/cgienvform.html">To cgienvform.html</a>'
"<p><table>"
end-display.
* Accept and display some of the known CGI environment values
perform varying name-index from 1 by 1
until name-index > name-count
accept value-string from environment
name-string(name-index)
end-accept
display
"<tr><td>"
name-string(name-index)
": </td><td>"
function trim (value-string trailing)
"</td></tr>"
end-display
if (name-string(name-index) = "REQUEST_METHOD")
and (value-string = "POST")
open input webinput
read webinput
at end move spaces to postchunk
end-read
close webinput
display
'<tr><td align="right">'
"First chunk of POST:</td><td>"
postchunk(1:72)
"</td></tr>"
end-display
end-if
end-perform.
display "</table></p></body></html>" end-display.
goback.
And here is a form that adds a little AJAX to the mix.
<html>
<head>
<title>Simple Ajax Example</title>
<script language="Javascript">
function xmlhttpPost(strURL) {
var xmlHttpReq = false;
var self = this;
// Mozilla/Safari
if (window.XMLHttpRequest) {
self.xmlHttpReq = new XMLHttpRequest();
}
// IE
else if (window.ActiveXObject) {
self.xmlHttpReq = new ActiveXObject("Microsoft.XMLHTTP");
}
self.xmlHttpReq.open('POST', strURL, true);
self.xmlHttpReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
self.xmlHttpReq.onreadystatechange = function() {
if (self.xmlHttpReq.readyState == 4) {
updatepage(self.xmlHttpReq.responseText);
}
}
self.xmlHttpReq.send(getquerystring());
}
function getquerystring() {
var form = document.forms['f1'];
var word = form.word.value;
qstr = 'w=' + escape(word); // NOTE: no '?' before querystring
return qstr;
}
function updatepage(str){
document.getElementById("result").innerHTML = str;
}
</script>
</head>
<body>
<form name="f1">
<p>word: <input name="word" type="text">
<input value="Go" type="button" onclick='javascript:xmlhttpPost("/cgi-bin/cgienv.cgi")'></p>
<div id="result"></div>
</form>
</body>
</html>
And just adding, when I tested this for the OpenCOBOL FAQ it was with a WebKit browser embedded in COBOL, leveraging the Vala WebKit bindings. Works the charm. COBOL controlling the browser that processes the CGI.
The initial reaction most people have to developing a web application in COBOL is very negative!
In general, I agree, and recommend not using COBOL for front end web development simply because there are other tools that come with a lot of pre-packaged support for building this sort of application. Support generally comes through library add-ons and pre-built interfaces to web services. The implementation language itself is less important.
As one example, Ruby on Rails is an application framework based on the MVC model using Ruby (language) to "glue" it all together. A fair bit of your development effort evaporates as long as you stick to the Rails framework. However, break the framework and it might very well break you. I see using frameworks such as Ruby on Rails ideal for new development where you control everything from the ground up.
Your situation may be somewhat different. If I have understood correctly, you have a base of COBOL applications and a mySQL database that need to be integrated into a new web application. The Rails framework may or may not be particularly useful in this context. It all depends on how you "meet in the middle". It is a fairly common industry practice to use strong web-enabled tools to front-end web applications with COBOL based back ends. Making the two come together is a fairly platform specific art form.
The same comments apply to any other web application framework and tool set. I just used Ruby on Rails as an example. Bottom line is that not many people (me among them) have given much thought to fronting a web application using COBOL.
Not withstanding the above, I noticed that you are using openCobol in your shop. This could make building a COBOL only solution a reasonable prospect. Unlike many COBOL implementations, openCobol comes "web ready" and has a database independent abstract layer so getting at your mySQL database should be quite painless. Web readiness is partly a consequence of openCobol using the C Application Binary Interface (ABI). The C ABI should greatly facilitate working in a mixed language environment and makes interacting with a CGI (Common Gateway Interface) pretty much trivial; as can be seen from this example.
OpenCobol makes building a web application feasible, but is it practical? As noted earlier, unless there is a documented web application framework in place to draw upon, you will end up doing a lot of it yourself. I think you may have already come to this conclusion when posting your question. As far as I can tell, developing such a framework is also feasible but does not yet exist. If you go forward with this project, maybe you could contribute toward developing a web application framework for openCobol.
I found the "Cobol on Cogs" reference in the accepted answer a little unfair, you asked a serious question and deserved a completely serious answer. This type of reference probably reflects a bit of "red necked" closed mindedness toward COBOL (Yes, I'm ready for and expecting down votes on this one).
If you HAVE to use Cobol because you need to integrate with some legacy COBOL APIs, how about you use Cobol to expose the data via some RESTful (or similar) API. Then write your web app in something modern like Django (which is very nice). The Python web app could then easily access the necessary data via the RESTful API you are providing in Cobol.
That would allow you to use the right tool for each job: A modern web app framework for the web app and some Cobol code to expose data to which you only have a Cobol API.
Microfocus provide a product called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
They also have another product "COBOL.Net" which provides an interpreter to .NET IL for COBOL programs.
Because this is on the .NET platform, you can mix-and-match with C# etc.
This allows you the best of both worlds. You keep the existing COBOL back-end but can develop the web application with modern tools e.g. ASP / MVC / Struts / JSP. And you chain the two together with a web service.
加载中,请稍侯......
精彩评论