Midrange Programmer

In "Web Services and the AS/400," I explored the importance of Web services and the role I expect them to play in the AS/400 environment. To exemplify how easily they are developed and implemented, I used the Microsoft .NET environment to create a Web service, and a browser to consume it. In this article, I will write a .NET client/server program to consume the Web service programmatically and to show how seamlessly the AS/400 fits in the Web services environment.

To maintain consistency in the application, we will once again take advantage of the .NET environment. More specifically, we will use Visual Basic .NET to create a Windows-based application designed to consume the service. To get us right back where we left off, we'll start by writing a program that consumes the same Web service we created in the last article. As a refresher, let's review that program. The code is displayed in Figure 1.

The name of our Web method is GetEmployeeName. It expects a single parameter of type Integer (EmployeeNumber), and returns a single variable of type String (EmployeeName). However, we must also keep in mind that the data returned will be in XML format. In just a while we'll see how VB .NET handles this. With our Web service in place, let's create the VB. NET program to consume it.

I start by creating a new Windows Application project using Visual Basic. I have named the project WebServiceConsumer and have stored it in the WindowsApplications\MidrangeServerProjects folder. This creates a default form called Form1. Visual Studio .NET also creates a folder called References within our project. This is an area in the project that we will use to reference all programs that are external to our application. It is in this folder that we will establish a reference to our Web service. By right-clicking References and selecting Add Web Reference from the drop-down box, we are presented with a dialog box that allows us to enter the location of our Web service. The result is shown in Figure 2.

Note that in the Address field I have filled the input box with the value of http://localhost/WebServices/MidrangeServer/EmployeeService.asmx. This is the location of the external Web service that we will be referencing in our program.

It is worth mentioning at this point that I am not limited to accessing Web services that exist solely on the local host machine. For example, if I were creating a package tracking application, I would be inclined to find the appropriate Web service offered by FedEx or UPS, if those were made available to the public and I had authority to use them. The objective is that we allow the business rules to be encapsulated by the Web service and to communicate with it via input and output parameters in XML format. Essentially, we are communicating with an external object that can reside on any server, anywhere on the Internet. This is indicative of some of the power of Web services, and is a primary reason why this topic has industry-wide appeal.

By clicking the Add Reference button, a reference to the Web service is added to our project. This means that we can now instantiate and use this object as if it existed on the development machine. Although we do not see the code behind the service, we are able to surface all the public methods exposed by the service, along with explicit information on how to call it. Take a look at Figure 3 to see what our project now looks like. Specifically, notice the Web References entry that has been added.

Now it's time to do some coding. Create a form similar to the one in Figure 4. Two fields and one button will be used: txtEmployeeNumber, to input the employee number; lblEmployeeName, to display the retrieved employee name (it is not visible but exists immediately below txtEmployeeNumber); and btnGetEmployee, which, when clicked, calls the subroutine that, in turn, calls the Web service.

When the program runs, a value of 1 will be entered for the employee number. To see all the action, let's focus on the btnGetEmployee_Click subroutine. The two lines of code that comprise our click event are all that's needed to request and retrieve data from the service. The first line of code in the subroutine creates an instance of the Web service object. The second line calls the service and receives the returned data.

Before we move on, let's consider one more topic. You'll recall, from "Web Services and the AS/400," that the data was returned in an XML format and looked something like this:

How, then, are we able to simply extract the value Joe Johnson without additional manipulation? Because .NET does it for us. Just as .NET serialized the output into XML format when sending from the Web service, it is also capable of deserializing the input and making the data available to our program as fields, rather than as just a string of XML. This is very powerful and greatly simplifies the time and energy that we as programmers would otherwise have to invest. Now that you see how it works, let's really make it worthwhile by bringing our AS/400 into the mix.

Having laid the foundation for creating and consuming Web services, exposing AS/400 data via the Web is actually a trivial task. The objective of this modification is to alter the Web service, as opposed to the consumer program just developed.

Although there is more than one way to accomplish this, we will continue to use the VB. Net framework to complete the sample application. To keep things simple, we are going to use the .NET OLE DB connection from within our Web service to access our employee data from the AS/400.

The data for this example is stored in an AS/400 file named Employees, located in the library Midrange. The Employee record has two fields: EmpNum and EmpNam. By replacing the GetEmployeeName Web method in our previous Web service program with the code shown in Figure 5, we can now provide real-time access to live AS/400 data, via the Internet:

What we see in the code is a straightforward use of an ADO connection and an SQL statement. It is also worth mentioning that our Web service consumer program does not even require a recompilation in order to take advantage of the latest enhancements. It simply continues to use the application as it always has. The results of running the program can be seen in Figure 6.

Imagine one of your clients has requested real-time order status updates on demand for incorporation into their internal, custom-written applications. Before Web services were available, you would most likely have implemented an EDI solution or something equivalent. And your client would have been limited to making the request as part of a batch process. Now it is feasible and practical to provide an Internet-based Web service, which you write and your client consumes--in real-time or in batch.

In our example, we purposely simplified the amount of data that was returned in order to focus on the fundamentals. But there is nothing to keep a Web service from returning an entire record or, for that matter, a set of records, for each request. Web services and XML are perfectly suited for just that type of functionality. How you choose to provide the data is entirely up to you as the application developer.

But Web services do more than simply provide data. It is feasible that clients will look to post data such as purchase orders, inventories, and status updates. Web services are also well-suited to be the interface to a distributed set of data found on many servers around the country or around the globe. Because of the loosely coupled architecture that Web services offer, a request can be made of one service, which, in turn, accesses several others before returning the consolidated data to the requesting program. An example of such an application might apply to supply chain or airline ticketing applications. The potential is endless.

Web services are here to stay and their uses will continue to expand. Organizations will have increasing expectations of direct system integration with trading partners as well as with internal systems. The AS/400 programmer is well-positioned to take advantage of this trend. By incorporating Web services with XML, AS/400 shops will be well-positioned to ensure the organizations they support remain competitive while continuing to bring sound, practical technology to the forefront.

Rick Farina is president of Farina + Associates Inc., a Boston-based consulting and training firm focused on Web and Windows applications for the AS/400. Rick is a frequent speaker at COMMON and ASNApalooza and has written several articles on bringing the AS/400 to the Web. In 1993, Rick was the lead architect and designer of an application that won the Computerworld-Smithsonian Award for Information Technology in Transportation. E-mail: rfarina@farina-assoc.com.