There is no doubt about it: The world of the traditional AS/400, iSeries, System i5 programmer is changing. The world of the Web has descended upon us or maybe even passed us by (was that the strange whizzing noise I heard?). Numerous new technologies and products (along with a corresponding host of new acronyms) appear to be requirements for providing information to and receiving information from different interfaces. We no longer live in a green-screen world.

The Web is the one interface that stands out above all of the others. And the Web has progressed beyond simply providing static or dynamic Web pages for human interaction: Web services are the means by which applications can communicate with each other over the Web, with no human intervention required.

The difficulties facing the traditional programmer in this brave new world usually fall into one of two categories: Either learn the new technologies or learn to communicate with the new employees who are implementing them. The latter is probably the harder of the two, since both parties end up trying to find common ground while using completely different terminology. Do you ever find yourself reading an article on WebSphere or Java and giving up halfway through because you don't understand most of the terms being used? I refuse to admit how often it happens to me.

I think we can be forgiven for feeling slightly left behind. In this article, I will present an overview of Web services from the perspective of the traditional programmer, and, in a follow-on article, I will provide an example of using WebSphere Development Studio Client (WDSC) to generate a Web service for an existing RPG subprocedure. This will provide an introduction to some of the concepts of Web services and demonstrate how a traditional programmer can generate a Web service to call a subprocedure or a program without having to become an expert in the 50 flavors of Web services.

What Is a Web Service?

At the risk of over-simplifying, a Web service is a transaction service that runs over the Web. This means that you need to use some form of application server, such as WebSphere, Tomcat, or JBoss. Many third-party applications also provide Web services, or you could even have a go at writing your own.

A Web service is provided through a URL: The Web service is invoked when the URL is requested.

A client codes a request as an eXtensible Markup Language (XML) message and invokes the service. The service processes the request, generates an XML message as a response, and returns it to the client.

Could this be why those new XML operation codes and built-in functions were introduced in the V5R4 release of RPG IV?

What Is the Problem?

What exactly is the problem that Web services are trying to solve? Primarily, it is one of integration. The nature of the Web is that you have multiple hardware platforms, operating systems, and programming languages all trying to communicate with each other in a meaningful way. This is not just a simple issue of presenting information on Web pages; instead, it's a means of making information available and accessing information through a Web-enabled interface.

For example, your customers have a requirement to access order-status information. You have made this information easily available to them on a Web page, but they want a means of incorporating the information directly into their own applications—and it is not acceptable to tell them to copy and paste. A Web service provides a means whereby your customers' application programs can request the order information via the Web and have the information returned in a "standard" format that they can process easily.

Or you might have a requirement to perform credit validation when you create a new customer account. Wouldn't be nice to be able to do this directly from an RPG program?

Get the Back-End Right

Before you even start contemplating Web services, you must give a lot of consideration to the state of your application. Let me present you with a fairly common scenario. A company has a traditional green-screen application that has been serving the business requirements for 15 years. But the business requirements are changing, and there is now a need for access from the Web and for information to be provided from multiple sources, not just the traditional phone and fax. The company knows that the existing application has all the complex business logic required, so, quite sensibly, it wants to utilize what it already has. Where does the company start? The mistake made by most companies is that they start at the front-end. They spend a lot of time deciding what the front-end should look like, what the middle tools should be, and whether it should use CGI, .NET, WebSphere, or another of the multitude of products available. And when all that is ready, the company suddenly realizes that the traditional application is very much geared toward working with a green-screen and consists of monolithic programs that don't fit the model of working with the new application interface.

So the first step is to get the back-end right. This means that you must truly modularize the application and separate the database process from the business logic from the interface. This in turn means you must fully utilize the benefits of RPG IV and ILE. When this is done, you are ready to have any sort of interface use your application. This really is one of the key elements of applications that use Web services. You must take the approach that, in the back-end application, not one line of code will change when the company suddenly decides that the technology it chose was the wrong one and it's going to switch (e.g., from .NET to WebSphere/Java or vice versa).

From the traditional programmer's point of view, it would do no harm to gain some understanding of how the Web works and how to program for it. I think the best place to start is with CGIDEV2, a free development tool that enables you to write RPG programs that will output to and input from Web pages. Basically, CGIDEV2 is a service program containing procedures that make it very easy to use the CGI APIs. Learning to use CGIDEV2 will show you how to interface with the Web and provide some understanding of the problems solved by application servers, JavaServer Pages (JSPs), and Java servlets. You can go to the Easy400 site for all your CGIDEV2 requirements.

In a lot of cases, CGIDEV2 may well satisfy your business needs for presenting and receiving data, but the design principle remains the same, and you must separate the interface from the business logic.

Once you have your application (or parts of your application) in a well-modularized state, you're ready to start experimenting with the wonders of Web services.

Why Use Web Services?

At first glance, Web services would appear to be just the latest flavor of transaction services. You could be forgiven for having that feeling of déjà vu by just replacing the term "Web services" with Remote Procedure Call (RPC), Electronic Data Interchange (EDI), Remote Database Access, or Remote Messaging.

But Web services provide a few advantages over the more traditional forms of transaction services:

• Web services have an open standard architecture for linking different applications types on different servers.
• There is a low cost of implementation because you can use existing Web infrastructures. Communication is via the Web as opposed to some form of direct communication.
• Web services do not require proprietary tools, software, or code. Server and client applications can be written in different languages and run on different platforms.
• There is an ever-increasing level of support from vendors in tooling and runtime environments.
• Web services registries are being implemented by industry to enable integration between customers and suppliers.
• But most importantly, assuming you have modularized your application, the same code provides information to all clients as opposed to using different application programs, depending on who issues the request.

But implementing Web services also has potential disadvantages:

• If you are already implementing one of the traditional transaction services, is there any business benefit to be gained from implementing Web services?
• If you do not have an existing Web infrastructure, you will need to implement one. This can be quite an undertaking and may require expertise and skills that are not currently available in your company.
• Performance may be an issue because you are dependent on the performance of your Web access.
• Security is also a consideration because information is passed via the Web as opposed to some form of "direct" communication.
• Your application is not in a state to be used by a Web service. I know I am starting to sound like a broken record, but this is still the biggest stumbling block for implementing Web services. You must restructure your back-end applications into callable modular structures.

Regardless of the pros and cons, you can be assured that Web services are here to stay. They are becoming a standard (and a requirement in some industries) and are being implemented in an ever-growing number of applications.

Terms and Conditions

The use of a Web service requires compliance to standards, and it is important to be aware of some of the methods (and terms) used to implement these standards.

• XML is a specification developed by the World Wide Web Consortium (W3C) for defining mark-up languages (much like HTML). It enables the definition, validation, and interpretation of data between applications. Requests to and responses from a Web service are messages in an XML format.
• Web Services Description Language (WDSL) is used to describe an interface to Web Services (what the Web service can do, how to invoke it, what the structure of the parameters is, which communications protocols to use).
• Simple Object Access Protocol (SOAP) is an XML-based protocol used to encode request and response messages before sending them over the network. These SOAP messages must match the message formats defined in the WSDL document.

How Does a Web Service Work?

At its simplest level (the best place to start), a Web service is a straightforward process very much like requesting information from an HTTP server:

1. A client application creates a request as an XML message using a SOAP framework and invokes a Web service via a URL on a server.
2. The server interprets the request from the XML message and processes it by calling the relevant program or procedure.
3. The server creates a response as an XML message using the SOAP framework and sends it back to the client. The response message will contain either the requested information (if the request was successful) or an error (if it failed).
4. The client receives the XML message and processes it to access the response data.

The process is not that complicated. But for most of us, the only piece of the process that we fully comprehend is the "relevant program or procedure" that is called by the Web service. This is the good old RPG program or subprocedure that has always done our bidding. The generation of a Web service requires the generation of a "wrapper" program that will decipher an XML request, call our program or procedure, interpret values returned, and put them in an XML format.

The good news is that you can use WDSC (which you should already be using for your day-to-day programming requirements) to generate and test a Web service request without having to gain any knowledge of application servers, XML, JSPs, or Java. You can then safely pass it all on to your Web application server gurus.

Got It?

Hopefully, you now have an understanding of what Web services are and of some of the components required to make them work.

In my next article, I will demonstrate how to generate and test a Web service using WDSC to do all the hard work.

Paul Tuohy has worked in the development of IBM midrange applications since the '70s. He has been IT manager for Kodak Ireland Ltd. and Technical Director of Precision Software Ltd. and is currently CEO of ComCon, a midrange consultancy company based in Dublin, Ireland. He has been teaching and lecturing since the mid-’80s.

Paul writes articles for many publications and is one of the quoted industry experts in the IBM Redbook Who Knew You Could Do That with RPG IV? He is the author of the books The Programmer's Guide to iSeries Navigator and Re-engineering RPG Legacy Applications as well as the self-teach course “iSeries Navigator for Programmers.”

He is also an award winning speaker who speaks regularly at COMMON conferences, the renowned RPG and DB2 Summit, and other conferences throughout the world.