COBOL Server

Hi Ahmet,

Enterprise Server is a Micro Focus product that can be used to deploy native COBOL web services using SOAP. ES is part of the Visual COBOL and COBOL Server 2.2 product and can be used if you have an SOA license.

The other two servers that you mention, Tomcat and IIS can also both be used for managed COBOL deployment.

The Visual COBOL for Eclipse product can generate COBOL applications as Java classes that can then run under Tomcat. There is a tutorial that covers deploying these in a JSP environment at community.microfocus.com/.../24039.visual-cobol-2-2-jsp-web-services-tutorial.aspx.

Likewise, the Visual COBOL for Visual Studio product can generate COBOL applications as .NET assembilies supporting templates for both ASP.NET Web Services (SOAP) or WCF Web Services that can be RESTful.

There are samples for the .NET support as part of the Samples Browser that is installed with Visual COBOL. Please look under the catagory for WCF.

Thanks.

To add to Chris' answer: There can't be a "native COBOL app server" in the general sense. COBOL is an ISO standard language with many implementations on different platforms, generally with vendor-specific extensions as well. No application server is going to host binaries generated from COBOL sources on all those platforms and implementations. What Chris describes are application servers for various flavors of Micro Focus COBOL.

Even then, none of those servers is "specifically for COBOL" in any useful sense. IIS (for .NET COBOL) and Tomcat, Glassfish, etc (for JVM COBOL) are obviously used with programs written in several languages. Even Enterprise Server is used with PL/I and on occasion other languages. The same can be said for non-Micro Focus application servers traditionally used to host COBOL applications, such as CICS.

Chris mentioned that you can create RESTful web services under IIS using COBOL and the .NET framework. Similar capabilities are available for JBM COBOL. Enterprise Server does not currently provide a RESTful web service feature.

Micro Focus does provide another option for running native Visual COBOL programs on IIS and Apache: Xcentrisity Business Information Server.  This web server was originally part of the Liant RM/COBOL product suite (acquired by Micro Focus in 2008), and has since been enhanced to support both AcuCOBOL Extend and native code Visual COBOL (managed .NET code is experimental).  It is available as a Visual COBOL add-pack in both x86 and x64 versions, and, while it exists largely to facilitate migrations from RM/COBOL and Extend to Visual COBOL, it might serve your requirements (weak pun intended).

On Windows platforms, Xcentrisity BIS installs into Internet Information Server 6 or later (v7 or later is, of course, strongly recommended), receives HTML, XML, and JSON requests from user agents, and spins up both short-lived and long-lived COBOL programs to process those requests. It performs session management so the targeted COBOL programs can be stateful, or stateless.  Requests can take the form of HTML POSTs, SOAP, POX (plain old XML), JSON, or just about any text format.  The request is converted to XML and is made available to the native code COBOL program in a file or in memory (for direct access) or via the XML Extensions toolkit; the latter option can decode the request payload and disassemble it into named working storage fields in the program. The XML Extensions can also transform the request in any number of ways using XSLT stylesheets -- sample stylesheets are provided for SOAP decoding/encoding and JSON is also popular. The XML Extensions are by far the easiest way to get the data into the COBOL program.

On output, the process is reversed: the COBOL program can write the desired XML/JSON directly to the response file, send it in memory, or it can use the XML Extensions to assembly an XML response from working storage, and then transform it using XSLT into SOAP, POX, or JSON. Once that's done, XBIS uses IIS or Apache to send the response to the user agent, and the COBOL program decides if it will wait for another request from the same user (stateful or stateless), or if the next request will spin up a new program.

Schematically, the COBOL program does this:

CALL B_ReadRequest...
     * Check return code, may indicate session abandoned, server restart pending, etc.
XML IMPORT TEXT...
     * Data now in working storage
     * Process the data in working storage
XML EXPORT TEXT...
     * Data now available to XBIS
CALL B_WriteResponse...

The program can then STOP RUN or repeat to process another request from the same user agent (enforced with cookies).  The session can also be forced to end with a parameter on the B_WriteResponse.  

Regarding REST, I do believe that recent Windows/IIS versions for Visual COBOL supports REST (I believe the major impediment was being able to set custom return codes under the COBOL program's control) -- but I'd have to do some investigation to be sure.

Here is a data sheet for the Extend version of XBIS, which is a subset of the Visual COBOL version: http://www.microfocus.com/assets/xcentrisity_tcm6-3589.pdf.

An overview and tutorial for the Extend version is here: http://supportline.microfocus.com/Documentation/books/ACU/900/XCentricity BIS Tutorial.pdf.

Again, the Visual COBOL version is functionally identical and the product includes this tutorial.

My company's application has been using Xcentrisity BIS (the RM/COBOL variant) for over a decade with great success.  Not only do we use it in a 'direct to browser' mode for the application's user interface, we also use BIS in a variety of web services situations, both SOAP and REST.  We are presently in the midst of an automated user interface conversion project which will get us further along the road to using REST architecture.

REST is not a specification, but rather an architectural style.  In it simplest form, URIs are used to identify resources, and the HTTP verbs (PUT, GET, UPDATE, DELETE) are used to implement CRUD (Create, Read, Update, Delete).  It is not unusual to see URL-encoded payloads, but XML payloads are also used and are becoming more common.  If all this sounds familiar, it is because the World Wide Web uses the REST architecture.

Perhaps you would like to describe a bit more what your goal is, so that the experts here can provide a more specific recommendation.

Tom Morrison
Hill Country Software