Web Service Net Cobol

Fujitsu COBOL and Web Services

Fujitsu Software
April 2001

Summary: This article presents the use of Fujitsu COBOL in creating Web Services. It
reviews the processes necessary to migrate from a procedural oriented paradigm to an
object-oriented one. Presented are the minimal steps necessary to convert to the object-
oriented environment. The creation of COM servers and clients is presented using the
COBOL language. Visual Basic COM client creation is also presented. The use of the
Microsoft SOAP Toolkit is explored as well as the changes necessary to the COM
clients to enable them for SOAP. We conclude with a discussion of .NET and the
advantages of beginning the migration to the new environment now as well as the overall
advantages of the .NET environment.

Contents:

Overview
COM Modules
Procedural Code Updates
Creating a COM Server
Accessing the COM Server
Fujitsu PowerCOBOL Client
Microsoft Visual Basic Client
The SOAP Toolkit
Using the SOAP Toolkit
Client updates
PowerCOBOL
Visual Basic
.NET
The Future of COBOL

Copyright 2001, Fujitsu Software, Inc Page 1


Overview

"Why is Microsoft interested in having so many languages target the .NET Framework?
Why bother with a language as old as COBOL?" The answer lies in recognizing that most
businesses do not have the luxury of rewriting their large code base every time they want
to extend the use of their existing applications.

By supporting the new Microsoft .NET Framework, Fujitsu Software is endorsing
Microsoft's philosophy that programmers want and need to be able to use the
programming language best suited to their application. With an estimated 70 percent of
production business applications written in COBOL, the answer to enhancing those
applications lies not in throwing out the COBOL, but in finding better ways to make it do
new things.

With that support, Fujitsu Software enhances the productivity of organizations that use
COBOL. Not only will COBOL programmers have access to a wide variety of new
technologies, including .NET class libraries and ASP.NET, they will be able to work
seamlessly with developers of code in other languages, such as C++ and Visual Basic.
Instead of having a development organization with a schism between COBOL
programmers and other programmers, the new environment allows programmers to
bridge the barriers using common interfaces and programming tools.

Web Services in the .NET environment provide the opportunity to expose programming
interfaces to the Web for use by clients to package in any way they see fit. A Web
service is programmable application logic accessible using standard Internet protocols.
1

This is a major distinction from more traditional programming models because it means
that organizations no longer have to worry about creating the entire application or user
interface. Web Services open up new opportunities for application deployment. Instead of
packaging business logic applications with wrappers that predetermine the Web
presentation style and content, companies can expose their business logic as a Web
Service to be customized for use by their customers.

This paper will describe how Web Services will be built with Fujitsus COBOL product
offering for .NET. Because .NET is not yet available, however, this paper will also
describe the steps that organizations can take to prepare their applications for use with
.NET. How is a clever developer to take advantage of these new technologies now? The
answer is in COM objects and the most recent version of the SOAP toolkit (version 2.0)
announced by Microsoft. The new version of the SOAP toolkit can be applied to COM
servers. Since Fujitsus current, released COBOL compiler product makes it easy to build
COM servers, it is now also possible to generate the SOAP descriptions necessary to
build a COBOL Web Service using Fujitsu COBOL. This is exciting because it gives
customers the ability to build Web Services using our currently available product and
gives them a tangible migration path toward the world that.NET has to offer.


1
A Platform for Web Services, Mary Kirtland, msdn news, Jan/Feb 2001

What is SOAP and what does it have to do with Web Services?

SOAP, Simple Object Access Protocol, is a protocol built on top of XML that supports
making what are effectively remote procedure calls across the Internet. The typical
transport mechanism for SOAP is over HTTP, but is not required to be. SOAP provides
the underpinnings for developing Web Services that are modules of functionality that can
be exposed on the Internet (or Intranet) to build up more complex functionality from a
variety of software service providers. One of the important advantages of .NET is that it
makes building Web Services very easy to do. With the SOAP toolkit, however,
customers that want to start making progress towards the application architecture
supported by .NET, or simply can't wait for .NET, can make progress today with
Fujitsus currently released COBOL compiler products and the Microsoft SOAP toolkit.

How can users build COBOL Web Services using the SOAP toolkit?

The latest version of Fujitsu COBOL (version 6) makes building COM servers much
easier. The SOAP toolkit supports generation of SOAP schema descriptions using type
libraries that exist in COM servers. SOAP schema descriptions are what allow you to
publish your Web Service on a web server and support proxy code that converts native
data to its SOAP representation. To build Web Services today, users can generate a COM
server, run a tool called the WSDL generator on the COM server to generate the SOAP
schema definition, and then publish this description on their web server. This process will
be reviewed in this paper.

Can users build Web Service clients in Fujitsu COBOL?

Yes! In addition to building Web Services, the SOAP toolkit also supports a COM
interface for building a SOAP client. Creating the client is quite simple: you instantiate a
SOAP client, point it to a URL that contains the service's schema description and then
make calls to the interface. This can all be done using either of Fujitsus latest COBOL
compilers. This process will be reviewed in this paper.

Building towards an application architecture of Web Services will require some
adaptation of your existing applications, e.g., modularization of presentation and business
logic layers may be required as well as building OO classes that provide the necessary
interfaces to their code. Fujitsu COBOL provides significant and very tangible support
for developing Web Services, but it is not a silver bullet. For customers that havent
begun working with SOAP and building COBOL COM servers, preparation and training
are required to ensure success. The key is that you can begin now with our latest product
and make tangible progress that can be deployed before .NET comes to market.



We will review the steps necessary to initially migrate the procedural based code to a
basic object-oriented structure. The next step will be to create a COM object and finally
to migrate the COM object, using the SOAP Toolkit, to a Web Service. A Fujitsu
PowerCOBOL client (PowerCOBOL is a GUI-building tool that is part of the Fujitsu
COBOL compiler suite) and then a Microsoft Visual Basic client will present processes
for accessing both the COM object and Web Service. In both instances only the
differences necessary to enable the Web Service will be highlighted. Finally, the
implementation of this same Web Service using a preview version of Fujitsus COBOL
compiler for .NET will be shown. Our example application requests an area code as input
and returns the state where the area code is located.

COM Modules

COM modules are the initial step in moving towards Web Services. The COM
environment and .NET, however, are based upon object-oriented principles. What this
means to the COBOL programmer is they are required to update some of their
existing procedural code to expose object-oriented interfaces.

Our example begins with a procedural based program that accesses an ISAM file and
returns a record. We will first convert the procedural program to an object-oriented
program. This program will then be registered as a COM server and called by first a
PowerCOBOL program and then a Visual Basic program.

Procedural Code Updates

The original source code is presented below.



The program opens a data file, prompts for input from the screen, searches the data file
and then displays an error message or the data returned from the file.

There are several changes that must be made to the source code to transform it into an
OO COBOL module. These changes can be divided into two categories:

1. Changing a COBOL program description into a class with a method (or several
methods) and
2. Substituting UI functionality with parameterization of the methods created. This
also typically involves converting error codes and error behaviors into exceptions
that object-oriented methods can raise to signal their callers.

Several new identifiers will be added to the source module, while a few will be changed
to reflect a new name. The following describes changes in these two categories in
greater detail with respect to our example.

1) Changing from program to class:
a) CLASS-ID. Programs are introduced with the reserved word PROGRAM-ID,
while OO COBOL classes are introduced with the reserved word CLASS-ID. The



source line in the program should be updated to read: CLASS-ID. {name}
INHERITS FJBASE, where {name} is the name of the COBOL program. For
our example we will name our class AREACODE.

All Fujitsu OO COBOL classes typically inherit from the FJBASE base class.
FJBASE represents the root of the Fujitsu COBOL inheritance hierarchy and is
responsible for implementing features related to lifetime management of objects.
(If your inheritance hierarchy is more than one level deep, classes that reside
deeper in the hierarchy would typically inherit from FJBASE indirectly by
inheriting from a class that itself inherits from FJBASE.)

b) A REPOSITORY statement has been added to the CONFIGURATION
SECTION. A Repository is used to list any outside classes this class may refer to.

c) The reference to class FJBASE has been added under the Repository.
This is the base class for all Fujitsu OOCOBOL applications and contains the
basic functions required for OO. Additionally we have added CLASS
COMEXCP to be used as a reference back to the exception class *COM-
EXCEPTION. This is a special class defined for COM to report errors back to the
callers of methods in our class.

d) An OBJECT statement has been added after the REPOSITORY section.
This defines the start of methods and data that are associated with instances of this
class that are created when the FJBASE class NEW method is invoked. (The
NEW object is what is invoked when clients instantiate a new object in
whatever client programming language is used.)

e) A PROCEDURE DIVISION for the object must be added. This signals the
beginning of methods defined for the object.

f) We also need to insert a METHOD-ID statement and name the new method. We
will use the name GETSTATECODE. You can think of a method as being
similar to a COBOL entry point. A class can have multiple methods and each
must have a unique name.

+Tip
When naming Methods, try to use a naming convention. It doesnt
matter what format you use as long as you are consistent.

g) An ENVIRONMENT DIVISION has been added for the Object.
h) Finally, we need to add three lines to the end of the program:
END METHOD GETSTATECODE. Ends the method definition.
END OBJECT. Ends the object definition.
END CLASS AREACODE. Ends the class (program) definition.

2) Substituting parameterization for UI:



a) We must update the DATA DIVISION. There are several changes that must be
made to the DATA DIVISION due the change in definition of this module to a
called module. The first change will be to update the WORKING-STORAGE
SECTION. We will add object references and error handling variables for the
module. Our new WORKING-STORAGE SECTION will now appear as thus:

b) The next step is to add a LINKAGE SECTION.
The LINKAGE SECTION will be used to pass parameters to and from the DLL
to the calling module. For our example we will add the following LINKAGE
SECTION

c) Update the original Procedure Division statement to the following:
PROCEDURE DIVISION USING INAREACODE
RETURNING OUTSTATECODE
RAISING COMEXCP.

d) We modified the source code to contain the following error handling routine

e) Next, we modified the source to not utilize any UI, but rather to utilize the above
error routine. For purposes of demonstration the file access routines remained in
the source module.



After applying the updates mentioned, the source module now appears as follows:



Copyright 2001, Fujitsu Software, Inc Pa

ge 9
If your existing procedural code has been designed such that the User Interface (UI),
business logic, file access, and error handling routines are separate distinct modules then
some of the above steps may not even be required as your COBOL programs may already
reflect them. In our example this was not the case. Our sample contained UI, error
handling, as well as file access routines all in one program. It was necessary therefore to
perform some additional changes to the source module. Other issues that you may
encounter in migrating to OO interfaces is the issue of managing resources and object
instances. Since OO classes can be instantiated multiple times, you must ensure that your
COBOL program is capable of dealing with multiple instances.

It should also be noted that not all of your procedural code would need to be updated to
an OO paradigm. Only those modules that would actually be COM modules and perform
as gateways into an application would require this conversion. In our example the file
access routines could be removed and a new COBOL source module created. The code in
the file access routine would not be required to be OO as it would be a called module
and could remain in its procedural form.

Creating a COM Server

The module we have just created will become a COM server. A COM server is a program
that expects to be instantiated and controlled by another program. The newly created
DLL must be registered as a COM object via the REGSVR32.EXE, as noted by
Microsoft, from within the Fujitsu COBOL development environment. This process will
not be reviewed in detail here.

Accessing the COM Server

We now have the COM server ready to go. For our example we will access the server
using a Fujitsu PowerCOBOL client first and then a Microsoft Visual Basic client. In
both examples we will provide overviews of the process.

Fujitsu PowerCOBOL Client

The Fujitsu PowerCOBOL client will present a Windows graphical user interface (GUI)
screen as presented below.

The user will enter in the area code and then
press the return key. The application will

then call the COM server to access the data file and return the state identifier.

! FYI
The Fujitsu PowerCOBOL coding will be kept to a minimum. For
further information on using PowerCOBOL please contact Fujitsu
Software at http://www.adtools.com.

The code necessary to enable the functionality is executed based on an event occurring.
Our example will utilize two events, Open and Return. The Open event will occur when
the form or application is initially opened. The Return event occurs when the return key
is pressed in the Area Code entry field.

The WORKING-STORAGE SECTION for the application contains an identifier to the
AREACODE COM module and makes the reference available for public use throughout
the PowerCOBOL application by identifying it as a GLOBAL variable. The code for the
WORKING STORAGE SECTION is presented below:

The code necessary to enable the Open event is presented below:

The code in the WORKING-STORAGE SECTION creates a reference to the AreaCode
COM module that is called the COM servers PROGID.

The PROCEURE DIVISION contains a single line of source to instantiate the
AREACODE COM module and makes it available to the application using the name
AREACODE-OBJ. Because the AREACODE-OBJ was created as a GLOBAL variable it
is now accessible by any module within the PowerCOBOL application.



The Return event contains the following code:

The source code is first creating a DECLARATIVES section to handle error processing.
This routine will only be utilized should an exception occur during the call to the COM
module. Next, several fields are initialized with spaces and then the area code entered is
moved from the screen to the IN-AREACODE variable that will be passed to the COM
module. The COM module that we instantiated when the form was opened,
AREACODE-OBJ, is then invoked. When the processing returns, the state code is moved
to the display field on the form using the statement
.

As we can see, with minor exceptions, the original procedural based source code has been
converted to an object-oriented source module and then made available for use as a COM
server.
Next we will see how to access the COBOL COM module using a Visual Basic client.

Microsoft Visual Basic Client

! FYI
The Visual Basic coding will be kept to a minimum. The intent is to
demonstrate how to create and access COBOL COM objects.



In Visual Basic, you can create the same UI shown for the PowerCOBOL client in the
last section. This is done by creating a new project, using the Standard EXE template, and
creating the following form. Our form looks like the following:

Before we can add code that makes use of the COBOL COM server, we have to add a
reference to the COM server within Visual Basic. The name of the COM server is
specified when building the COM server using Fujitsu COBOL. In our case, the
description defined for the COM server was Area Code to Postal State Code converter.

! FYI
We will not review how to add a reference in Visual Basic in this
paper. For information consult the Visual Basic documentation.

The coding we will do will be short and to the point. Error checking will be kept to a
minimum. The code for the example follows:



As you will quickly see the same steps we accomplished in the PowerCOBOL
example are completed here as well. The horizontal line for clarity separates each of
the following areas:

First we create a reference to the AreaCode COM module.
Next when the form is loaded (the COBOL equivalent was an OPEN event)
the instantiation of the object occurs.
When the return key is pressed the event occurs to access the COM module
and return the state code. The error handling routine is specified last.

The basic flow of the process is the same whether we are coding in COBOL or in
Visual Basic. The only changes are in terminology and syntax. Since we are able to
access the COM module via either COBOL or Visual Basic, we also could have used
C++ or any other COM-enabled language. The question arises then Why would I
want to use SOAP since I can access my COM clients anyway?. The answer is
accessibility. COM provides for client/server or in-house access. DCOM (Distributed
COM)_can be used for distributed access of COM servers, but DCOM uses
proprietary protocols for communication. SOAP will permit our applications to be
accessed via the Web and be available to our clients who may be located throughout
the world.



The SOAP Toolkit

The SOAP Toolkit provides the infrastructure for developers to expose and utilize Web
Services. With a few exceptions that are detailed in the toolkit, it complies with the
SOAP version 1.1 specifications. It includes the Remote Object Proxy Engine (ROPE), a
Service Description and Code Generation wizard and code that provides ASP and ISAPI
implementations of SOAP listeners.

The SOAP Toolkit is able to expose the functionality of a given COM object as a Web
Service. Utilizing the WSDL Generator, the developer determines how much of the COM
object to expose. The exposure can be the entire COM object or a small sub-section.

! FYI
The current version of the SOAP Toolkit can be downloaded from
Microsoft. See http://msdn.microsoft.com/soap/.

Download and install the Toolkit per the instructions noted.



Using the SOAP Toolkit

This section will walk through the process of using the SOAP Toolkit utilizing an
existing COBOL COM object and executing the wizard in the WSDLGenerator tool. The
first step is to determine what name you would like to give to your service.

! FYI
For detailed instructions on using the SOAP Toolkit refer to the Users
Guide which accompanies the Toolkit.

For our example we will use AREACODE. The next step is to specify the existing COM
object you would like to enable as a Web Service. The wizard comes with a browse
button currently labeled Select COM object. It is best to utilize the browse button, as
entering in directory information is not only tedious but also prone to errors. We will
utilize the AREACODE.DLL object.

After the wizard has located the COM module, it will be parsed and the methods
available within the COM module will be displayed. To select a specific method simply
click in the checkbox next to it, or to select all the methods within the module click the
checkbox next to the DLL. Notice when you select a specific method, the DLL also
becomes checked. If you select the DLL then all the methods will become checked. It is a
good idea to verify your selection before proceeding.

,Hot!
Within the current version of the toolkit is a notice concerning data
types. If you select a method that uses a data-type not supported by the
SOAP Toolkit, the questionable type will have the data type
???????? in the WSDL file. You MUST update the data type to a
supported data type before the WSDL file is used.

The SOAP listener information must next be specified. The first item to specify is the
URI for the listener. This should be a virtual directory specified within IIS. Our example
will be located on the local host within a directory called SOAP. Our entry for this field
will be http://localhost/soap. For the remaining portion of the page we utilized the
defaults of an ISAPI listener type and an XSD Schema namespace of 2001.

The Toolkit will generate two files, a WSDL and WSML file. The location for these two
files is specified in the next screen. Once again the screen has a browse button labeled
Select. Utilize the button to locate the directory where the files should be created. This is
merely a working directory for these files can be placed in. For our example we used the
source directory of the COM server.

When you click the next button the toolkit will generate the files and save them to the
locations specified. It is up to you to copy the generated files to the appropriate web
server.



The WSDL file that is generated by the wizard is a schema that describes key information
about the web service. It is written in XML and identifies the services provided by the
server and the set of operations within each service that the server supports.

! FYI
For specific details on the WSDL file refer to the User Guide supplied
with the Toolkit.



The second file that is produced is the Web Services Meta Language, WSML, file. The
WSML file provides information that maps the operations of a service (as described in
the WSDL file) to specific methods in the COM object. The WSML file also determines
which COM objects to load to service the request for each operation. Here is the WSML
file generated from our example:

The Web Service has been created. In our example we generated the WSDL and WSML
files into the web server directory so no further operation on them is necessary. The next
step is to update the clients we previously created to utilize the new SOAP objects.

Client updates

The majority of the programming has already been completed. The changes necessary to
utilize the SOAP object are relatively minor. We will begin by reviewing the
PowerCOBOL client first.

PowerCOBOL

The updates necessary for the PowerCOBOL client are in two areas, the WORKING-
STORAGE SECTION and the opened event for the form. The WORKING-STORAGE
SECTION has to be updated to reference a SOAPCLIENT via the addition of a
SOAPCLIENT identifier as specified below.



The OPEN event for the form has the majority of changes. As can be seen in the
following illustration the URI and ProgID variables have been updated to reflect calls to
the SOAP client object supplied by the SOAP Toolkit. The URI now contains the URL of
the location where the WSDL file is located. The ProgID contains a reference to the
Microsoft SOAP client.

The invocation of the object within the PROCEDURE DIVISION has been updated to
reflect the use of SOAP as well. Notice the addition of the SoapClient prior to the
CREATE-OBJECT syntax. Also notice the instantiation of the AREACODE-OBJ has
been moved to a separate sentence and is being initialized via the mssoapinit procedure.
These are the only changes necessary to the existing PowerCOBOL client in order to
enable SOAP technology. The business logic of the existing COM module has not been
changed and no further coding is required. The changes weve made can be referred to as
driving instructions to enable the communications protocols to locate the module
necessary to fulfill the request. The advantage though is now the directions provide a
complete roadmap, whether that module is located within your existing infrastructure or
in your clients infrastructure across the country or around the world.



Visual Basic

As with the PowerCOBOL client, the Visual Basic client has some minor changes related
to where the object is that it is attempting to use.

Setting the pointer variable has been updated to reflect the use of a SoapClient. The
Form_Load event has also been updated to reflect this change. Notice the addition of a
call statement to the WSDL file. If you remember, the WSDL file is the XML interface
between the client and the server mapping out how the service is called and how
interactions occur.

No other changes are necessary to the code.



.NET

When .NET becomes available the processes we just reviewed with regard to the SOAP
toolkit will no longer be necessary. Eventually, users will also have the option of
compiling their existing code with Fujitsus COBOL compiler for .NET to execute using
the Common Language Runtime. The code we created for the COM server would be
converted to the example on the following page.

A substantial savings in time and effort will be achievable using the .NET environment.
In the current environment, prior to making any updates, a COM module must first be
unregistered, the modifications to the module made, the module registered and the web
site returned to active. .NET supports XCOPY deployment, which means that COM
style registration is not necessary and versioning is handled much more seamlessly. No
longer will it be necessary to perform the steps mentioned or create installation wrappers
to supply to your users. When a modification is necessary a company will be able to copy
in the new module thus enhancing their Web Services without disturbing their existing
environment and their users will realize the results of the modifications when they next
utilize the Web Service. Also, the SOAP Toolkit will not be required to create the
necessary XML files as these files will be created automatically by ASP.NET
infrastructure that can directly read interface information from executables compiled for
the Common Language Runtime.

Converting COBOL programs into Web Services is the perfect way to utilize the
strengths of COBOL and retain large investments in the development of business logic.
The majority of processing that will occur in a Web Service will be batch oriented with
no user interface. COBOL is ideally suited for processing orders, completing inventory
updates, payroll or tax calculations or other heavy-duty number crunching processes.
Utilizing COBOL code as Web Services will also enable a company to take advantage of
their most valuable asset, employees with the business knowledge to enable the new
applications. Your personnel have been maintaining the business logic in your systems
for years. Rewriting the systems into other languages has been proven to be costly and
ineffective. Instead of changing the language of the systems, change the environment in
which the system operates in with .NET. .NET will enable you to maintain your current
investment in systems and personnel yet expand into the new global environment, faster
and



cheaper.





The Future of COBOL

The long-term benefits of integration with the Microsoft .NET Framework are that
COBOL will more easily adapt to new technologies. New frameworks that are developed
for the .NET Framework (in any programming language) immediately become accessible
to COBOL programmers. Fujitsu Software has always been committed to ensuring that
COBOL programmers have the tools they need to develop applications using the latest
technologies. Support for the .NET Framework lends assurances to that commitment.

Just because Web Services are discussed in the context of .NET, you should not assume
that you must wait for the Microsoft .NET Framework or Microsoft Visual Studio.NET
to build, deploy, or consume Web Services. Web Services are a very general model for
building applications and can be implemented for any operating system that supports
communication over the Internet. Fujitsu Software and Microsoft both have the products
available today to enable you begin your journey towards .NET. Fujitsu Softwares
current product suite of COBOL tools is available now. For more information, see Fujitsu
Software at http://www.adtools.com. Also available from Fujitsu Software is a
Technology Preview of the forthcoming COBOL compiler for .NET. The Technology
Preview can be downloaded from the http://www.adtools.com/preview/.

! FYI
The Technology Preview is just that, a preview. The samples provided
with the preview will work as designed. The Preview is intended to be
an early look at the technology to be offered and does not contain a
fully functional system.

Microsoft has the SOAP Toolkit available for distribution as well. The current version of
the SOAP Toolkit can be downloaded from http://msdn.microsoft.com/soap/.

.NET is an exciting and bold leap forward in the creation of software. Begin the journey
now with Fujitsu Software and Microsoft.


Web Service Net Cobol

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Service Net Cobol

Uploaded by

Copyright:

Available Formats

Fujitsu COBOL and Web Services

Fujitsu COBOL and Web Services

You might also like