Simon Guest
Microsoft Corporation

February 2005

Applies to:

    Microsoft .NET Framework 1.1
    Microsoft Visual Studio .NET 2003
    NEON Systems ServiceBuilder 3.5.0

Summary:  This article shows how SLI (Screen Logic Integration) can be used to expose Web services from host (mainframe) -based applications. Specifically, this walkthrough covers how NEON Systems ServiceBuilder, an integration tool designed to expose mainframe functionality, can create a Web service for an airline flight information system. (19 printed pages)

Contents

Web Services Integration with Host Systems
Introducing NEON Systems ServiceBuilder 3.5
What Is ServiceBuilder?
What Is FEPI?
Contoso: The Travel Agency
Contoso's Flight Information Application
Generating a Web Service Using ServiceBuilder
Creating a ServiceBuilder Project in Visual Studio .NET 2003
Recording the Host Session
Mapping Recorded Screens and Fields
Generating the Output
Testing Using the Starter Projects
Generating and Consuming a Web Service
Conclusion
About the Author

Web Services Integration with Host Systems

It remains a fact that host systems (mainframes) still play a significant role in many enterprises. Many of these systems run business-critical applications, without which many organizations would simply not function.

While this is the case, it is also recognized that many of these systems are becoming aged, less flexible and difficult to maintain. This applies not only to the underlying hardware and software, but also to the skills and knowledge required to maintain these systems.

For organizations that face this today, migration of applications off the mainframe is one approach. Many vendors and SIs (System Integrators) specialize in this, with organizations such as the Mainframe Migration alliance (http://www.mainframemigration.org) leading the way.

Migration however can sometimes be a long process—especially for some complex applications. In addition to migrating, organizations with investments in host systems may have a desire to expose mainframe applications and data to other systems—for example, to access this information before migration is complete, or where migration is not an option. Exposing Web services from these applications provides the best way of achieving interoperability with other systems.

So, how does an organization go about exposing Web services from an existing mainframe application? In general there are four ways of integrating Web services with Host systems:

• Direct Data Access
• Asynchronous Access (Message Queue)
• BLI (Business Logic Integration)
• SLI (Screen Logic Integration)

Direct Data Access is where a data provider, such as those provided with Microsoft's Host Integration Server that access vital host sources, including IBM DB2 databases and VSAM host file systems are used to run SQL queries against the database on the mainframe. Using a façade, these queries and the results can then be exposed using Web services. With the correct driver, this is fairly easy to setup. A Web service accepts the incoming call; the parameters are verified and passed to a query. Providing the performance is acceptable, the results of the query can be returned in the Web service response.

Asynchronous Access is offered by host systems that support message queues (for example, IBM MQ Series). Using a façade and the required drivers for the message queue, operations can be exposed using Web services. A good example of this approach is using Host Integration Server's MSMQ-MQSeries Bridge feature as a façade to a Web service which writes to an MSMQ queue and a host application that uses MQSeries. It is now possible to access IBM MQ Series and other asynchronous message queues through libraries either provided by IBM or third parties.

BLI (Business Logic Integration) is the process of calling host systems through callable interfaces. Most of the newly developed IBM mainframe and midrange applications contain business logic that is separated from the presented screens. Bypassing these screens allows these interfaces to be called directly. A Web services façade can then be used to expose these interfaces. This is functionality exposed through Microsoft Host Integration Server (HIS) 2004. A sample showing this approach is covered in a later article.

SLI (Screen Logic Integration) is the process of calling host systems through screen logic. This is where a sequence of screens are recorded, mapped to a function and then "played back" to the host in order to re-execute the function automatically. During the 1990's companies and organizations invested in this type of technology to take traditional green screen applications to HTML representations. As we move into the era of Web services, we now see technology that can take these green screens into objects and services. For the purpose of this article we will be looking at this SLI option. Here we will investigate a sample mainframe based application and see how NEON Systems ServiceBuilder can be used to integrate and expose Web services using this approach.

Introducing NEON Systems ServiceBuilder 3.5

NEON Systems, Inc. (NASDAQ: NEON) is a provider of enterprise-class mainframe integration solutions, delivering a unified mainframe integration platform to support requirements for modern Service-Oriented Architectures (SOA) and emerging Event-Driven Architectures (EDA). NEON's Shadow technology reduces the complexity of mainframe integration to enable organizations with significant commitments in mainframe systems to streamline incumbent technologies and lower total cost of ownership.

What Is ServiceBuilder?

ServiceBuilder is an integration tool designed to expose mainframe and mid-range functionality as .NET, Java, and Web services. A specific transaction, or number of transactions, can be exposed from the host platform as a component or Web service.

ServiceBuilder offers two development environments to choose from: 1) A stand-alone developer, 2) Visual Studio .NET version fully-integrated with ServiceBuilder. The development process varies depending on the type of legacy application(s) being exposed as components or Web services. In the case of SLI integration, the ServiceBuilder developer is used to record the screen workflow into an XML repository, identify input/outputs for the desired component/Web service inside of a visual environment, and then generate the specific target(s) desired. The recording and playing back of these screens is performed using the FEPI interface.

What Is FEPI?

The CICS Front End Programming Interface (FEPI) is an integral part of CICS. FEPI provides access, by means of simulated terminals, to CICS and Information Management Systems (IMS) applications available through a communications network. FEPI enables you to write CICS application programs that access other CICS or IMS applications. FEPI is best suited for older CICS and IMS systems that do not conform to allow DPL, OTMA, or 3270 Bridge / Linkable Bridge access.

FEPI is used as an API to access CICS and IMS transactions by ServiceBuilder, and allows access to applications that do not utilize BMS maps such as Natural and CA-IDEAL. While FEPI does simulate screen scraping, all processing is done inside of CICS on the mainframe, allowing this approach to achieve some performance gain over typical emulation solutions.

Contoso: The Travel Agency

To show Screen Logic Integration (SLI) in action using NEON Systems ServiceBuilder, we will use a fictitious use case, based on a company called Contoso.

Contoso, a major airline ticketing agency serving many international airports, runs several applications on IBM MVS host systems. Over the past years these have been very reliable, but the agency is now looking to move towards a service oriented approach using Web services. Contoso feels that this new strategy will allow them to be more agile, and as a result more competitive with new products and services.

One of Contoso's core applications is a flight lookup and details system. This currently allows their operators to look up flight details—either in person or via their telephone booking system. This mainframe application is delivered to each user by using a terminal emulator that runs within Microsoft Windows.

Contoso wishes to adopt a services-based strategy, such that flight details can be retrieved through a common Web services based interface. They plan to consume this Web service in other services, and possibly develop a Windows based smart client application for their operators.

Contoso's Flight Information Application

Through a terminal emulator accessing a 3270 session on the mainframe, the flight information application works as follows: First, the operator is shown a list of options as seen in Figure 1.

Figure 1.   The Flight Information Menu

As shown, the options are to add a flight, get flight details, modify a flight or remove a flight. To lookup the details for a flight, the operator enters menu item 2 and presses enter.

The next screen now asks the operator for the company name and flight number, as shown in Figure 2.

Figure 2.   Entering the Company Name and Flight

Here, the operator enters the two digit code to represent the airline followed by a three digit flight number—AA 110 as shown. Upon pressing enter, the flight details for this corresponding entry are displayed:

Figure 3.   Returning the Details for the Flight

The flight details screen lists the company name, flight number, origin, destination, frequency, fare, aircraft, departure time and arrival time. Taking this set of screens, the IT department in Contoso creates a design for a Web service that will work with the host application:

Figure 4.   Web service Design for the Service

As shown in Figure 4, the plan is to create a Web service that will accept two inputs—an airline company code and a flight number. Although the mainframe screen returns 9 fields of data, it has been decided that the return from the desired Web service should return only three specific pieces of information: the origin, destination and the fare. Both the origin and destination will be returned as the three letter airport codes for each (for example, SEA for Seattle).

Let's now investigate how this can be built using NEON Systems ServiceBuilder 3.5.

Generating a Web Service Using ServiceBuilder

To help generate Web services in a consistent way, as mentioned previously, NEON Systems ServiceBuilder 3.5 is integrated with Visual Studio .NET 2003. A Web service generated using ServiceBuilder looks just like any other Web service in the .NET environment.

There are five steps for creating a Web service that accesses a mainframe application. Firstly, we create a new project in Visual Studio .NET using the ServiceBuilder template. After this, we use the ServiceBuilder Recorder to record a mainframe session and map input and output fields in the screens to our Web service. After the recording is complete, we generate a .NET C# Class Library. This enables us to generate the Web service.

Finally, we test the output using one of the starter applications that are created automatically. One of the starter applications contains a Web service (ASMX) that can be immediately hosted.

Creating a ServiceBuilder Project in Visual Studio .NET 2003

To start creating a new Web service, Visual Studio .NET 2003 is launched. From the file menu we select a new project type as shown in Figure 5:

Figure 5.   Creating a New Project Using ServiceBuilder 3.5

As shown, NEON Systems ServiceBuilder includes its own templates for Visual Studio .NET. Within the Screen Logic Integration set of templates is a new item—Class Library C#.

Selecting this project type generates a skeletal project within Visual Studio .NET. This includes the necessary references to the NEON Systems libraries, a default class and two XML files; one to record the session and the other for configuration.

Figure 6.   New ServiceBuilder Project in Visual Studio .NET

Recording the Host Session

With the new project created, the next step is to record the session. This process of recording is a one-time effort, required to build up a series of screens and fields used to generate the Web service.

Within Visual Studio .NET, selecting Recorder from the ServiceBuilder menu opens the recorder, as shown in Figure 7.

Figure 7.   The ServiceBuilder Recorder Tool (click for larger image)

Clicking on the record button and entering the connection details for the mainframe application (for example, IP address, port, and RACF security details) opens the session.

Once connected, to record the session we walk through the operation of the application—entering example values for the inputs. For example, on the main menu we select Get Flight Details as shown in Figure 8.

Figure 8.   The Flight Details Menu Captured in the Recorder

This in turn displays the screen that requires input for the carrier and flight number. Here, we enter some example values that will allow us to proceed to the next screen, as shown in Figure 9.

Figure 9.   Entering a Company Name and Flight Number

Based on these values, the screen displaying details for the flight is then shown, similar to Figure 10.

Figure 10.   Viewing the Returned Flight Details in the Recorder

Within the recorder application these screens are saved to an XML repository. Now that we have all of the screens that depict the process we wish to capture, we can stop recording and start identifying fields and data.

Mapping Recorded Screens and Fields

Once recording has completed, we can use the tool to review screens that were captured. For example, as shown in Figure 11, the recorder is able to list the input fields in screen 19 of our recording.

Figure 11.   Using the Recorder to Identify Input and Output Fields (click for larger image)

At this point, we navigate through each of the input and output fields, identifying them appropriately.

Double-clicking each of the fields enables us to affix a variable name. For example, I double-click on company name field and then enter CompanyName as a variable name for this property as shown in Figure 12.

Figure 12.   Properties for the Recorder Field

Within this properties field, ServiceBuilder has already assumed some defaults—such as the usage (this is an input field), COBOL variable name, declaration and type.

We repeat this process for the flight number and map our second input field. For the output fields, we navigate to the next screen. Here we select the origin, destination, and fare fields as shown in Figure 13. Again, we map this to a property that will be returned from our Web service.

Figure 13.   Mapping the Fields for the Output Screen (click for larger image)

Generating the Output

Once all of the fields have been mapped, and the recorded session has been saved, we complete the process by generating the .NET class library. Clicking on the Build tab within the ServiceBuilder recorder displays the details of the class library that will be generated to access the underlying CICS transaction. This is shown in Figure 14.

Figure 14.    Generating the .NET C# Class Library (click for larger image)

Double-clicking the .NET C# Class Library icon instructs the recorder to generate the C# assembly.

Figure 15.   Generation Complete

Returning to Visual Studio .NET, we can see the generated output from the build process. As shown in Figure 16, Visual Studio .NET now contains two additional projects, ContosoAirStarter and ContosoAirStarterWeb.

Figure 16.   Viewing the Starter Projects in Visual Studio .NET (click for larger image)

These two projects are starter applications (ContosoAirStarter contains a Windows Forms application; ContosoAirStarterWeb contains a Web page and Web service).

Testing Using the Starter Projects

The starter projects are forms-based applications that call the underlying application on the mainframe.

To test the underlying connection, we can run the Windows Forms starter form. Selecting the ContosoAirStarter project as default and hitting F5 runs the application:

Figure 17.   The Windows Form Starter Application

After entering security credentials to access the mainframe, the Windows Form as shown in Figure 17 is displayed. Upon entering the CompanyName and FlightNumber into the Windows Form, we click on the ContosoAir button. Under the covers, the NEON Systems ServiceBuilder libraries package the call using FEPI and send it to the mainframe application. The results (Origin, Destination and Fare) are returned and displayed on the form. The Web-based form also generated by ServiceBuilder provides similar functionality in a Web page (the ContosoAir.aspx in ContosoAirStarterWeb project), shown in Figure 18.

Figure 18.   The Web Form Starter Application

As you might expect, both these starter applications can be used as starting points for your own application.

Generating and Consuming a Web Service

Now that we've seen and tested the FEPI connection using the starter applications, how can we go about creating Web services?

In addition to the starter applications, ServiceBuilder also generates an ASMX file as a starting point (ContosoAirWS.asmx in ContosoAirStarterWeb project). Deploying this to IIS generates a default WSDL that can be consumed by a Web service client, shown by Figure 19.

Figure 19.   Generated WSDL for the Contoso Air Service (click for larger image)

In this example, the Web service defines a single document based method called ContosoAirRun. This method accepts a parameter of type ContosoAirIn that contains the CompanyName and FlightNumber. When called, the method returns a parameter of type ContosoAirOut containing the Origin, Destination and Fare.

To test this we can call the Web service in any .NET application. After adding the Web Reference to the generated Contoso Web service, the code to call the service looks as follows (in C#):

// Create a new instance of the service
MainframeServices.ContosoAirWS s = new MainframeServices.ContosoAirWS();

// Create the request
MainframeServices.ContosoAirIn details = new MainframeServices.ContosoAirIn();
details.CompanyName = "AA";
details.FlightNumber = "110";

// Call the service
MainframeServices.ContosoAirOut result = s.ContosoAirRun(details);

// Display the result
Console.WriteLine("Flight leaving from: "+result.Origin);
Console.WriteLine("Going to: "+result.Destination);
Console.WriteLine("Fare: "+result.Fare);

As expected, this produces the following output:

Flight leaving from: CDG
Going to: JFK
Fare:       +350.00

Conclusion

Out of the four possible ways of generating Web services for mainframe applications, this article has covered only one—using Screen Logic Integration. In this article we saw how to use NEON Systems ServiceBuilder to create a new Visual Studio .NET project, record a session and create a set of starter applications and a Web service to access the mainframe. Other Microsoft partners such as NetManage, Farabi Technology and WRQ also provide similar Visual Studio .NET tools that generate Web services for mainframe applications using Screen Logic Integration.

One of the major advantages with this approach is the non-invasive nature in which we created the Web service. Here, I didn't need to install any additional code or applications on the mainframe. This can be very important for organizations that are reluctant to install additional workloads on the mainframe that will increase the CPU MIPS utilization or update their legacy applications for support with Business Logic Integration.

I would like to express my thanks to Hugh Raiford from NEON Systems for help given in creating this article.

Simon Guest is a Program Manager in the Architecture Strategy team at Microsoft Corporation, and specializes in interoperability and integration. Simon holds a Masters Degree in IT Security from the University of Westminster, London, and is the author of the Microsoft .NET and J2EE Interoperability Toolkit (Microsoft Press, September 2003).

Simon can be reached via his blog at http://www.simonguest.com.