Web Service Net Cobol

Fujitsu COBOL and Web Services

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


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 Fujitsu’s 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 Fujitsu’s 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 Fujitsu’s 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 Fujitsu’s 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 haven’t 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 Fujitsu’s 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 doesn’t 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 server’s 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.


http://www.gotcobol.com/


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.


http://msdnwww.microsoft.com/soapdownloads/


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. © Copyright 2001, Fujitsu Software, Inc

http://localhost/soap


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 we’ve 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 client’s 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 Fujitsu’s 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 Software’s 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. © Copyright 2001, Fujitsu Software, Inc

http://www.adtools.com/

http://www.adtools.com/preview/

http://msdnwww.microsoft.com/soapdownloads/

Web Service Net Cobol

Documents

Transcript of Web Service Net Cobol