With all of the hype surrounding XML and Web services, sometimes it's good to step back and look at a specific example of how to tie all of the technology stuff together. During the past months, I've received correspondence from TechRepublic members asking for some simple guidance for how to get started. Here's a recent letter (edited for simplicity and clarity):
-I have read your articles on XML and Web services, but I don't understand how to tie the Web to our legacy system. For example, we have a 10-year-old order entry inventory system running on an SCO UNIX box written in AcuCobol. We create small Web sites for our clients to order promotional goods from us. They would like to see real-time inventory and order status on the site. I understand that we could create a data stream with information from the site, such as order number or customer number, and I know the O/E entry system could read it and look up the information, but what is the middleware piece that sends data back to the site in response to a query? Can you give me a graphical look of how the pieces work through the whole process?"
Yes I can, and it's a great idea to look at the processââ,¬"and the pitfallsââ,¬"of developing Web services that can take advantage of the data stored in legacy systems. We'll look primarily at returning data from a legacy system to a trading partner through a Web server using Web services technology.
Data access vs. object access
The legacy system mentioned above is a great example of the biggest obstacle faced when trying to front end the legacy system with a Web interface: data access. In order to create an automated way to deliver data through the Web, you must have a data-access mechanism that allows you to read the data from a proprietary file structure.
Luckily, it's possible to find ODBC drivers for most legacy databases and file formats. If you can't find an ODBC driver, the lone choice is to write extract routines in the native language of the legacy system (in this case, AcuCobol) and do periodic dumps of the tables and columns data you wish to deliver through the Web. These extract routines should put the data in a set of flat files that can easily be read into another DBMS that you can use as a data repository for your Web system. (If your internal systems are heavily transactional in nature, you may want to make periodic copies of the data anyway in order to minimise the additional database traffic that the Web's likely to generate.)
With most legacy systems, you can get access to the data but not access to the process or object that creates the data. In the example system, you can get access to the files that store the invoice headers and invoice line items, but it's unlikely that you could actually call the section of AcuCobol code that would insert a new invoice by populating the header and line item tables. Without access to this code, you have no way of knowing whether you are following the business rules defined in the code itself. For this reason, Web interfacing to most legacy systems is done as a read-only process. The updating is done by capturing the data and then giving it to an order entry clerk to process with the application.
As a general rule of thumb, you should never update underlying data unless you use the same process that terminal users would use. (CIOs who invested early in IBM's CICS technology are now reaping the benefits of their decision. Since legacy systems based on CICS were developed as discrete transactions with specific entry points into legacy code, it's relatively easy to build Web service interfaces into these systems that are process based without regard to the format or location of the underlying data.)
Object access vs. page access
Once you've identified the data you want to return to the users through your site, you have to decide whether you're going to return a page or an object. What's the difference? Returning a page allows your users to view the data from your legacy system, but returning an object allows them to integrate the underlying data from your system with their internal business processes.
Returning a page is as simple as writing some HTML code on your Web page that formats the data coming from the system data files. Returning an object, however, requires more work but gives the ultimate user much more flexibility. This is where Web services using XML and SOAP become essential. Here's an example of how you could implement a Web Services front end for this AcuCobol-based legacy system.
Assuming that an ODBC driver for AcuCobol exists, it's likely to communicate with the data files using a TCP/IP sockets interface. To centralise all access to the underlying AcuCobol data, I've proposed the development of a single COM object with multiple functions designed to return data from the underlying AcuCobol order entry system, represented by the GetData() COM object. Once you've developed this object, you can use it directly from an ASP page or you can call it from a Web Service.
I've chosen to implement this particular Web service design on an all-Microsoft platform because the .NET Framework is the simplest, most compatible, and most complete implementation of XML Web services standards today.
More importantly, you can install the .NET Framework on any Windows 2000 Server running IIS 5.0 without paying any additional licensing fees. You can implement this solution with a Linux server running Apache and Java, but you'll have to write all of the underlying code to generate SOAP messages and to convert the data from the GetData object into XML. You'd also have to find a Linux version of the AcuCobol JDBC driver and code the GetData object in Java. Either way, you shouldn't have to do anything special to the underlying AcuCobol order entry system since we're just reading the customer, order header, order detail, and product files to return a completed order.
Wrapping data with Web services
Rather than developing HTML pages that access the GetData() COM object directly, I'm recommending you wrap all data access with Web services. Using this approach lets companies give customers the choice of how they want to access the company dataââ,¬"as a page or as an object.
In this example, the company has developed a Web service called GetOrder that takes the customer ID and order ID and returns the details of the order as an XML stream. For customers who want a simple Web page interface, the company can develop a set of Web pages that allow the customer to log in with their customer ID and then enter an order ID for which they'd like to see the underlying details. The Web page then calls the GetOrder Web service at the server and formats the returned XML stream for the customer's detected browser.
For customers who want a richer interface, the company can give the customer direct access to the Web service itself. Some customers will choose to develop their own Intranet solutions that call the Web service and display the data returned on their internal pages.
Others may want to interface the GetOrder Web service with their internal systems, allowing them to automatically retrieve order data and process it any way they choose.
The most important technical detail to point out here is that all of the processing takes place over the HTTP protocol. This means customers can consume the data returned from the Web service without having to install any local software or system drivers. In the past, this level of interaction would have required each end of the connection (customer and company) to have the same set of object drivers (COM, CORBA, JNI, etc.) in order for them to integrate this tightly.
Better tools mean less integration work
Although this is a very high-level view of all the underlying components, this should give you a feeling for the work involved in creating Web services.
The other key point outlined is that the amount of work required for new technologies like Web services depends upon the chosen platform.
If you're working with these technologies today, you can develop robust Web services solutions with a minimal amount of detailed knowledge of SOAP and XML if you use the .NET Framework. IBM's WebSphere platform also does an admirable job of hiding the intricacies of the underlying SOAP framework from developers.
Unfortunately, if you've bet on Sun or Oracle technology, you'll have to have an intimate knowledge of the technologies before you start any real work. Sun won't support XML Web Services natively until the next release of the JDK (due at the end of 2002), so vendors like IBM, Oracle, and BEA are writing their own proprietary extensions in order to make it easier to implement them today.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
6%
1%
Excellent Article, thank you for pointing out the actual function of some of the buzz words.
I am the business owner for a project that will be creating a web service to replace some legacy interactions for upwards of 200 customers. The crucial aim of the project is to make automated connectivity to our service as easy for customers to impliment as possible.... and my project manager has just told me that the IT architect controlling our system design has rejected the use of SOAP due to extra effort to impliment.
I think I shall be recommending that SOAP should be used after reading your article.
Thanks Again