Introduction
Microsoft’s
.NET Framework not only enables the vision of companies
sharing Web Services but also establishes a whole new development
and execution environment for applications – whether
on or off the Web. With components winning awards even before
their full release, .NET is truly the latest and greatest
happening in the application development world. COBOL, on
the other hand, has been around almost from the beginning
of business applications on computers and is unlikely to
be mentioned by anyone talking about the “latest and
greatest”. Why, then, have Microsoft and Fujitsu Software
expended considerable effort in bringing these two technologies
together? Has it been possible to integrate the “old”
and “new” in a worthwhile manner? Does this combination
of COBOL and .NET have anything to offer you, and how easy
is it going to be for you to take advantage of those benefits?
This
paper aims to answer these questions for you firstly by
laying out why the .NET Framework is attractive to business
applications and COBOL programmers, and what COBOL has to
offer to .NET. It will then give you a feel for COBOL for
.NET by
showing you what it looks like in different .NET technologies
such as ASP.NET, Web Services and class sharing, explaining
how you might use COBOL in each of these areas. It will
give you an insight into what was done to make COBOL work
in the .NET environment and conclude by describing how you
can experience COBOL for .NET yourself.
Why COBOL for .NET
Makes Sense
To
understand why COBOL and .NET come together well, it is best
to start with what COBOL has to offer. The reasons that COBOL
runs over 70% of the world’s production business applications
are that it has always provided:
- Record-oriented
data structures
- Built-in
business-oriented data types: alphanumeric, alphanumeric-edited,
decimal, numeric-edited, and packed-decimal.
- Simple
control flow constructs
- Readable
and maintainable code
Although
often put down by speedy programmers, COBOL’s verbosity
has been a big part of it providing readable and maintainable
code. Maintainable code is a critical feature for business
applications that can have life spans of many decades. Consider
if you are in the position of committing your company’s
core business processes to a programming language – do
you want to select the “in” language of the moment
which history has shown will be “out” in 10 years’
time, or do you want to select a language that has a 40 year
track record, and which any programmer can understand?
Another
factor in favor of using COBOL for business logic, is that
COBOL programmers typically have a lot of experience in supporting
business needs. Their focus tends to be more on implementing
the business functions rather than getting into the latest
technology (just because it’s the latest).
However,
businesses still need to take advantage of the latest technology
as this can often give them their competitive advantage or
ensure that they aren’t disadvantaged relative to the
competition. This, if anything, has been COBOL’ s weakness
in the last decade – it has not always been able to take
advantage of the latest technologies as the interfaces or
architectures have not been accessible to COBOL.
The
.NET Framework changes all this. Web applications need a secure,
managed environment in which to operate. In providing this
Microsoft decided not just to create an environment that supported
a single programming language, but to create an environment
that was capable of supporting all programming languages,
and to extend it so that it could support console, Windows
GUI, and Web HTML styles of applications as well as the typically
interface-less Web services. Figure 1 gives an overview of
what the .NET Framework provides.
Figure 1. Application Language's Perspective of the .NET
Framework
This
figure shows how Visual Studio .NET provides a common development
environment for programming. Any language, such as COBOL,
which is enabled for that development environment, can be
developed with language-sensitive features including highlighting
of text, project building and debugging. Then the code is
compiled into a standard intermediate language called Microsoft
Intermediate Language (MSIL) that is executed by the Common
Language Run-time (CLR) in a secure, managed environment.
MSIL is platform independent and is compiled to native code
by the part of the run-time loading software.
One
big benefit of the common execution environment is that
its design is such that classes can be inherited from one
language to another. .NET includes several frameworks, or
libraries of classes, that any .NET language can use, including
COBOL.
The
net result is that .NET offers an environment in which you
develop in the language that makes most sense for the task.
Now it should be obvious how COBOL can benefit from being
a full player in the .NET framework. COBOL gets:
-
An award winning development environment (Visual Studio
.NET) that is designed for creating .NET applications.
-
The
ability to inherit the latest technologies from the framework
classes.
-
The
option to invoke code written in other languages in a
seamless manner, whenever that code provides useful functionality.
-
The
ability to support application needs wherever MSIL is
supported - such as in ASP.NET pages and Web services.
.NET benefits
too by gaining:
- The
language that is best for many business logic implementations
- The
ability to execute the valuable business logic contained
in around 200 billion lines of COBOL code worldwide (Gartner
Group estimate)
- The
business expertise of hundreds of thousands of COBOL programmers
Thus COBOL
and .NET make a strong partnership; one that is worth exploring
to see how you can exploit it to your company's advantage.
What
COBOL for . NET Looks Like
To show
you what COBOL looks like in the .NET Framework this paper
presents three examples of COBOL code in different .NET areas:
- Within
an ASP.NET page, illustrating the provision of dynamic Web
content using COBOL
- As
a Web Service, demonstrating how simple it can be to package
existing modules as Web services.
- Within
the GUI Framework, showing how COBOL can inherit from other
languages and how OO COBOL has been adapted to fit the object
oriented .NET architecture.
ASP.NET
(language="COBOL")
ASP.NET
is the Microsoft successor to Active Server Pages (ASP), which
were designed to deliver dynamic Web content. ASP faced a
number of weaknesses in the areas of performance and programmability,
and ASP.NET makes substantial improvements in those areas.
Instead of being interpreted like ASP, ASP.NET compiles pages
to native code. This change results in enormous performance
benefits, with only a one-time cost to compile the page when
it is first deployed. The other
important side effect of the design choice (to compile instead
of interpret) is that it opens the door for compiled languages
to provide code in ASP.NET pages.
Fujitsu
COBOL takes advantage of this important benefit by allowing
COBOL programmers to embed COBOL code in ASP.NET pages.
ASP.NET
Example 1
The following
is a sample ASP.NET page written using COBOL that displays
"Welcome to ASP.NET (now in COBOL!)" in increasing
font sizes:
<%@ page language="COBOL" %>
<script runat="server">
OBJECT.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 Font-Size PIC S9(9) COMP-5.
END OBJECT.
</script>
<% PERFORM VARYING Font-Size FROM 1 BY 1 UNTIL Font-Size > 7 %>
<font size="<%=Font-Size%>"> Welcome to ASP.NET (now in COBOL!) </font>
<br>
<% END-PERFORM. %>
The "<%@"
characters introduce the directive that allow us to set the
programming language for the page to COBOL. The <script>
block allows us to introduce COBOL code that declares the
FONT-SIZE variable and the characters "<%" allow
us to introduce inline COBOL code to loop over the HTML that
displays "Welcome to ASP.NET (now in COBOL!)"
ASP.NET
Example 2
ASP.NET
also makes programming interactive content much simpler by
exposing standard HTML elements as controls and allowing programmers
to create new controls. Web Forms is the name given to this
type of control in the .NET Framework. The sample below shows
the use of several Web Forms controls in an application that
displays the image of a piece of fruit based on the fruit
name selected in a drop-down box.
<html>
<head>
<script runat="server" language="COBOL"> [1]
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
PROPERTY Select-Value AS "Value"
PROPERTY Image-Src AS "Src"
PROPERTY Span-Value AS "InnerHtml"
CLASS String-Builder AS "System.Text.StringBuilder"
CLASS Sys-String AS "System.String"
CLASS Sys-Object AS "System.Object"
CLASS EventArgs AS "System.EventArgs".
OBJECT.
PROCEDURE DIVISION.
METHOD-ID. FruitList-Click.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 Image-File-Builder OBJECT REFERENCE String-Builder.
77 Image-File-Str OBJECT REFERENCE Sys-String.
77 VAL OBJECT REFERENCE Sys-String.
LINKAGE SECTION.
77 Event-Source OBJECT REFERENCE Sys-Object.
77 Event OBJECT REFERENCE EventArgs.
PROCEDURE DIVISION USING BY VALUE Event-Source Event.
SET Span-Value OF FruitName TO Select-Value OF FruitList [2]
INVOKE String-Builder "NEW"
USING BY VALUE "images/"
RETURNING Image-File-Builder
SET VAL TO Select-Value OF FruitList [3]
INVOKE Image-File-Builder "Append" [4]
USING BY VALUE VAL
RETURNING Image-File-Builder
INVOKE Image-File-Builder "Append"
USING BY VALUE ".jpg"
RETURNING Image-File-Builder
INVOKE Image-File-Builder "ToString"
RETURNING Image-File-Str [4]
SET Image_Src OF FruitImage TO Image-File-Str [5]
.
END METHOD FruitList-Click.
END OBJECT.
</script>
</head>
<body>
<form runat="server"> [6]
<font face="Verdana" size="6">
<b>Please Select A Fruit : </b>
<select id="FruitList" runat="server"> [7]
<option value="Orange">Orange</option>
<option value="Apple">Apple</option>
<option value="Mango">Mango</option>
<option value="Pear">Pear</option>
<option value="Banana">Banana</option>
</select>
<input type="submit" value="submit" runat="server" [8] OnServerClick="FruitList-Click"> [9]
<p>
<table>
<tr>
<td>
<img id="FruitImage" src="images\blank.gif" runat="server" />
</td> [10]
<td>
<font face="Verdana" size=8>
<span id="FruitName" runat="server"/> [11]
</font>
</td>
</tr>
</table>
</font>
</form>
</body>
</html>
The <form> tag block [6] surrounds the set of
Web Forms controls used in the page. The runat="server"
attribute [6] indicates to ASP.NET that the behavior
of the control is implemented using code running on the server.
This example has four Web Forms controls, whose names are
specified using the "id" attribute:
- A select
control called "FruitList" [7] that displays
the list of five fruits to choose from.
- An
unnamed input button [8]. The "OnServerClick"
attribute [9] specifies that the button has a programmed
event associated with clicking it. The value of the attribute
gives the name of the method that is the event handler-in
this case "FruitList-Click."
- An
image control called "FruitImage" [10]
that is used to display the image of the selected fruit.
- A span
control called "FruitName" [11] that displays
the name of the selected fruit alongside the image.
The <Script>block
[1] at the top of the ASP.NET page implements the "FruitList-Click"
event handler in COBOL for the input button control. The method
extracts the selected name from the "FruitList"
control [3], uses the StringBuilder class from the
.NET base framework to construct the path to an image file
of the fruit [4] to [4], and sets the appropriate
values for the "FruitImage" [5] and "FruitName"
[2] controls.
This technology
enhances the programmability of Web pages and helps to overcome
limitations of static HTML technology. With this technology
you can imagine constructing sophisticated Web systems, including
applications like electronic storefronts, inventory management
systems, shipping management, and other dynamic content applications.
Best of all, these applications can be programmed using COBOL,
the language your workforce is trained to use.
Web
Services: Programming the Web
While
ASP.NET allows programmers to package dynamic content onto
server-side Web pages, Web Services go a step further. They
provide the opportunity to expose programming interfaces to
the Web for use by clients to package in any way they see
fit. This allows businesses to truly componentize their product
offerings in ways that end-users can customize to suit their
own applications.
The following
is an example of a very simple Web Service written in COBOL:
<%@ WebService Language="COBOL" Class="SimpleService" %> [1]
CLASS-ID. SimpleService.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
CUSTOM-ATTRIBUTE WebMethod CLASS WebMethodAttribute. [2]
REPOSITORY.
CLASS WebMethodAttribute AS [3]
"System.Web.Services.WebMethodAtribute".
OBJECT.
PROCEDURE DIVISION.
METHOD-ID. AddMe CUSTOM-ATTRIBUTE IS WebMethod. [4]
DATA DIVISION.
LINKAGE SECTION.
01 Operand-1 PIC S9(9) COMP-5.
01 Operand-2 PIC S9(9) COMP-5.
01 RET PIC S9(9) COMP-5.
PROCEDURE DIVISION USING BY VALUE Operand-1 Operand-2
RETURNING RET.
COMPUTE RET = Operand-1 + Operand-2.
END METHOD AddMe.
END OBJECT.
END CLASS SimpleService.
The example
is just a COBOL class definition with a method called "AddMe"
that adds two numbers together. The "WebService"
directive [1] tells the .NET Framework that we want
to expose methods as Web Services and identifies the programming
language and class in which the methods are written. The CUSTOM-ATTRIBUTE
sentence [3] in the SPECIAL-NAMES paragraph defines
an attribute that is used to describe the method in metadata
when it is exposed to the Web. This attribute is associated
with the method in the CUSTOM-ATTRIBUTE clause of the METHOD-ID
paragraph [4].
As simple
as this seems, a number of technologies all have to work together
for Web Services to function. For example, SOAP is a protocol
that has been offered by Microsoft as a standard; it is used
for marshaling data using XML. SOAP is needed for clients
and servers to communicate their arguments and results in
a format that can ultimately be transmitted over HTTP. Microsoft
has also defined a Web Service Description Language (WSDL),
which describes the services being exposed and provides clients
the mechanism through which they can find those services.
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. For example, you may have many
customers who would benefit by knowing your inventory for
particular products. You can provide them with a Web Service
that gives them product numbers and the means to query inventory
levels. Because the .NET Framework handles the communication
protocols and the parameter matching, the process of making
such an interface available to your customers is much simpler
than if you attempted to do the same thing outside the .NET
Framework.
Frameworks
and Language Interoperability
The .NET
Framework SDK comes with frameworks that implement a wide
variety of operations, such as I/O, data type manipulation,
and graphical application development. Because Fujitsu COBOL
supports the .NET Framework, the language in which these libraries
are implemented is immaterial. COBOL programs can use these
features as if they were written in COBOL. The infrastructure
for this language interoperability is a common language runtime.
The previous
ASP.NET fruit list example has already demonstrated some of
the uses of .NET frameworks. The COBOL method "FruitList-Click"
was embedded in a class that inherited from classes in the
.NET frameworks. This allowed direct access to inherited properties.
The "StringBuilder" class is another example of
a class from the .NET base framework. The following sample
shows the use of the Win Forms framework that allows developers
to construct Win32-based GUI applications:
CLASS-ID. Hello INHERITS Form. [1]
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
PROPERTY Win-Text AS "Text"
CLASS Application AS "System.Windows.Forms.Application"
CLASS Form AS "System.Windows.Forms.Form". [2]
STATIC. [3]
PROCEDURE DIVISION.
METHOD-ID. Main.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 App-Obj USAGE OBJECT REFERENCE Form.
PROCEDURE DIVISION.
INVOKE Hello "NEW" RETURNING App-Obj
SET Win-Text OF App-Obj TO "Hello COBOL World!" [4]
INVOKE Application "Run" USING BY VALUE App-Obj [5]
.
END METHOD Main.
END STATIC.
END CLASS Hello.
This very
simple application brings up a frame window with the title "Hello
COBOL World!" It demonstrates inheritance from the Windows
Forms "Form" class [1]/[2] and use of
methods [5] and properties [4] in the Windows
Forms class library. Notice also the STATIC header that has
been introduced to define code that is instantiated only once
for a class, as opposed to OBJECTs that are instantiated once
per object. Elements in the STATIC definition correspond to
.NET fields and methods that have the static attribute, sometimes
referred to as "statics".
Migrating
COBOL Code to the .NET Framework
The .NET
Framework provides interoperability between code targeted
for the common language runtime, also known as managed code,
and existing native code and COM applications. This means
that developers can write new managed code that makes calls
to their existing code. In the case of existing COM applications,
this is as simple as using a type library import tool (TLBIMP)
that makes COM interfaces visible to managed code. For other
native code, you simply need to provide a COBOL prototype
declaration for the code you want to call. To call from native
code to managed code, developers can use a type library exporter
(TLBEXP) and an assembly registration tool (REGASM) to export
their managed code as COM objects.
You also
have the option of compiling your existing COBOL85 code with
the new compiler to run completely using the common language
runtime.
How
COBOL for .NET is Implemented
Microsoft's
.NET Framework is a rich and advanced object oriented environment
that introduces a true cross-platform, cross-language supporting
system - the Common Language Run-time. Bringing COBOL to this
environment has been a major undertaking that Fujitsu Software,
the only COBOL vendor to target the .NET Framework, has attacked
enthusiastically, realizing the benefits to be gained by COBOL
applications and programmers. The major developments have
been:
- Mapping
OO COBOL syntax and developing new COBOL syntax to support
.NET features
- Enhancing
the front end to the compiler to support the new syntax
and to package code and associated information in MSIL-compatible
ways
- Creating
a new back end to the compiler to generate MSIL code
- Adding
.NET options to the compiler driver
- Implementing
a CodeDOM (Code Document Object Module) provider that enables
the use of COBOL as an ASP.NET language
- Developing
pieces that enable COBOL to be fully supported by Visual
Studio .NET
- Writing
documentation that fits into the Visual Studio .NET information
presentation mechanism explaining how to use Fujitsu COBOL
for .NET
We expand
on some of these developments in the following topics.
Language
Extensions
The common
language runtime is based heavily on an object-oriented programming
model. This does not mean that all programs that run in the
environment have to be object-oriented, but object-oriented
language constructs are needed to use some features of the
environment.
The Fujitsu
COBOL implementation started with the OO extensions in the
proposed COBOL standard then added new syntax where it was
clear that the semantics of the .NET Framework and those in
the proposed standard were not compatible. For example, constructs
like delegates, custom attributes, and visibility attributes
had no existing representation in COBOL.
Code
Generation
The common
language runtime achieves its goals of interoperability, security,
and robustness by operating on MSIL instead of native code.
This means that compilers that target the environment have
to develop new code generators that generate MSIL instead
of native code. The common language runtime uses just-in-time
(JIT) compilation strategies to ultimately translate code
for the platform into fast native code.
Enhanced
interoperability also means that applications with code written
in different programming languages can also be seamlessly
debugged. This is an important productivity
benefit, particularly if you have been working with languages
that (unlike Fujitsu COBOL!) had no or cumbersome cross-language
debugging support.
ASP.NET
Support
In addition
to a new compiler, language-specific support was also required
for the new ASP.NET infrastructure. Because ASP.NET compiles
its pages, it has to be able to generate code to represent
the HTML and ASP.NET content in the language in which the
page is written. For example, the "Welcome to ASP.NET
(now in COBOL!)" ASP.NET sample shown earlier results
in generated code that includes the following fragment:
PERFORM VARYING FONT-SIZE FROM 1 BY 1 UNTIL FONT-SIZE > 7
INVOKE ASP_output "Write" USING BY VALUE " <font size="""
INVOKE ASP_output "Write" USING BY VALUE FONT-SIZE
INVOKE ASP_output "Write" USING BY VALUE
"""> Welcome to ASP.NET (now in COBOL!) </font> <br> "
END-PERFORM.
Getting
Started with COBOL for .NET
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 Microsoft .NET Framework is the latest step that demonstrates
that commitment.
This paper
has just given you a glimpse of the power that COBOL for .NET
opens up for COBOL applications and COBOL programmers. You
can fully research the benefits yourself by participating
in the COBOL for .NET beta program. To sign up, follow the
links from Fujitsu COBOL's home page at www.adtools.com
|
Reuse vs Rewrite
