26 IT Pro September ❘ October 2001 1520-9202/01/$10.00 © 2001 IEEE
Cross-Platform
Integration with
XML and SOAP
Timothy M. Chester
T he current rage for middleware has pro-vided tremendous opportunities for thosewho love to build complex distributedsoftware applications. Interoperability is
no longer a fringe movement; it’s become main-
stream. The big three—Microsoft, IBM, and Sun
Microsystems—are now investing considerable
resources into interoperability research.
Here, I tackle the abstract concept of software
interoperability and how the Extensible Markup
Language (XML) and Simple Object Access
Protocol (SOAP) can assist in integrating busi-
ness applications. Together with the concept of
Web services, these standards could provide an
alternative to what organizations do today: rely
on the batch export of data to integrate software
applications.
THE PROBLEM
Most developers would agree that cross-plat-
form software integration can be challenging.
Attempts at standardization, including the vari-
ous electronic data interchange (EDI) transac-
tion sets, have succeeded
only in environments with
considerable technical and
financial resources. Never-
theless, organizations seri-
ously need standard methods
to exchange data.
Consider my organization,
Texas A&M University. Our
data center encompasses
myriad platforms, operating systems, and data-
base services.We use an IBM OS/390 mainframe
for the accounting, payroll, and student informa-
tion systems. E-mail and directory services run on
an SGI server.We have homegrown software that
tracks everything from student housing to schol-
arships and advising appointments. This data
resides on Oracle, Microsoft SQL Server, and
Sybase database servers scattered across our
enterprise.
We have deployed every conceivable applica-
tion or Web server currently available: Sun
Solaris,Microsoft Windows 2000,FreeBSD,Linux
(name your flavor), Apache, iPlanet, Microsoft
Internet Information Server, and so on. Now,
don’t get me wrong; this type of diversity can be
preferred within large organizations.The best-of-
breed approach can increase flexibility within
decentralized organizations, letting departments
meet custom business needs more easily. Each
system in our organization does a great job meet-
ing a particular need.The challenge is figuring out
how these systems can efficiently exchange infor-
mation with one another.
APPLICATION INTEGRATION
AND BATCH PROCESSING
Until recently, the interoperability attempts by
the enterprise vendors (Microsoft, IBM, Sun,
Oracle, and Computer Associates) were dismal at
best. Sure, you could buy Distributed COM
(DCOM) implementations for Unix or OS/390,
but they didn’t work well. There were various
Want to get around generating
a bunch of flat files to make
your information systems
interoperate? Web services,
XML, and SOAP could help.
XML-Based
Communications with
the EntireX Broker
Resources
Inside

September ❘ October 2001 IT Pro 27
implementations of Corba/IIOP (Common Object
Request Broker Architecture/Internet InterORB
Protocol) for Windows, but they didn’t work well either.
Open or Java Database Connectivity (ODBC/JDBC) are
great if you are writing business services in Visual Basic or
Java. However, despite my best efforts, I can’t get my data-
base support group to give me ODBC access to crucial
mainframe files.They fear that I will corrupt the data.
EDI transaction sets provide some foundation for shar-
ing information between computer systems. EDI has
worked well for large organizations with ample resources.
But, there’s one problem: Every organization using EDI
tends to make tiny modifications to the EDI format to sup-
port its own specific needs. This makes it very difficult to
build one standard EDI parser that supports multiple busi-
ness partners, rendering EDI work costly and difficult to
maintain.
Figure 1 illustrates how most organizations integrate
software applications.The method of choice appears to be
dumping large amounts of data to text files, and then send-
ing those files over the network using ordinary FTP batch
processes. The receiving system then processes the data
using other batch programs to upload the data into another
software application. I call this the batch FTP method of
application integration.
The process illustrated in Figure 1 automates the fol-
lowing work flow:
• Texas A&M has a Web-based application for university
admissions. This application stores data in Oracle run-
ning on a Sun Solaris server. A Windows 2000 server
provides Web access to this information. Each night, the
applications completed by potential students must be
uploaded to the mainframe-based Student Information
Management System (SIMS), a system build on top of
Software AG’s Adabas data management system.
• The state of Texas operates a common admissions appli-
cation that prospective students can also use to apply to
our university. Again, completed applications must be
uploaded to SIMS each night.
Internal
admissions
applications
(Oracle/Unix)
Off-site
credit
card
processor
ActiveX
API
ActiveX
API
ActiveX API
6:00 AM
Batch
processing
(Visual Basic)
5:00 AM
Print
subroutine
(Natural)
2:30 AM3:00 AM
3:30 AM
2:00 AM
4:00 AM
1:00 AM
Credit card
preprocessing
(Visual Basic)
EDI
preprocessing
(PL/SQL)
FTP flat file
Creates
flat file FTP
program
(Perl)
ODBCODBC
FTP flat fileProcess
credit card
(Visual Basic)
Preprocessing
(Natural)
Off-site
common
application
(Adabas)
FTP EDI file
Creates flat file Final
posting
(Natural)
Creates flat file
Student
Information
System
(Adabas)
Figure 1. Batch FTP method of application integration.

28 IT Pro September ❘ October 2001
M I D D L E W A R E
• Both systems transmit completed applications to SIMS
via FTP.They convert the data to an EDI format (trans-
action set TS-189) before shipping. An EDI parser on
the mainframe (OS/390) processes this information and
does the actual data posting.
• Information transmitted from the state of Texas contains
credit card information that must be processed.Because
the university’s credit card vendor does not provide an
application programming interface (API) for OS/390
programming, a preprocessing routine dumps the credit
card information into another text file.This file is trans-
ferred via FTP to a program running on a Windows 2000
server for processing.
• Finally, another mainframe program picks up the pre-
processed information from the state of Texas, applica-
tions from our own system,and the processed credit card
responses. It then posts this information to SIMS. This
process also dumps some information to another file that
is used for printing.
As you can see from Figure 1, this is a multistep process.
Eight separate batch jobs must fire in sequence for the
process to complete successfully. This process uses four
separate languages—Natural, Perl, Visual Basic, and
PL/SQL (Oracle Corp.’s proprietary procedural language
extension of the industry-standard Structured Query
Language). It operates on three separate platforms—
OS/390, Sun Solaris, and Windows 2000—that communi-
cate via three separate wire protocols—FTP, ODBC, and
HTTP (hypertext transfer protocol).
Has this worked? You bet; in fact, this process has been
in production for just over three years. Everything runs
fine until a failure occurs, usually once a month.When this
happens, an analyst spends about
half a day searching the various
error logs to determine what hap-
pened, and then makes the neces-
sary adjustments to correct the
problem. Depending on the error,
the batch programs may need to be
manually reexecuted. Serious
errors sometimes require that the
original source resubmit the data.
Integrating applications through
FTP is not the same as enabling
them for e-commerce. FTP- and
EDI-based transactions, for exam-
ple, cannot provide customers real-
time information regarding the
best available fare for an airline
flight.A system that is e-commerce
ready is capable of providing this
type of information. Technically
speaking,e-commerce transactions
involve multiple transactions with
instant feedback and output. Wouldn’t it be better if
process A received real-time notification when an error
occurred in process B so that it could adjust operations
accordingly?
Developers require more robust tools to enable their
software applications for e-commerce.They need
• a more sophisticated and robust method for sharing data
(FTP was not designed for e-commerce transactions);
• a platform- and language-neutral way for software to
communicate;
• sophisticated methods for exception handling and error
trapping—when an error occurs, the client must be able
to handle this using conventional exception-handling
schemes; and
• secure and easily encrypted network communication
protocols.
Web services are an emerging solution to these needs.
Because this solution is open, built upon World Wide Web
Consortium (W3C) standards, and has the support of all
the major software vendors, it merits careful consideration.
INTRODUCTION TO WEB SERVICES
Industry trade magazines have paid attention to the con-
cept of Web services for some time, but most organizations
have yet to consider what a Web services architecture
means for their enterprise. I will not attempt to answer the
question of whether Web services is a new term for some-
thing that existed previously, but let me try to demystify
the concept. First,Web services are similar to component-
based, n-tier design architectures. If you’ve ever built a
reusable software component, you’ve done something
Presentation/business
services tier
Database
Windows 2000
Web server
EntireX
Broker
COM
object
EntireX
Broker
Web
page
Active
Server
Page
Cobol
program
IBM OS/390 mainframe
Data services tier
Lo
g
ic
al
ar
ch
it
ec
tu
re
Ph
ys
ic
al
ar
ch
it
ec
tu
re
Figure 2. Example of a simple Web service.

September ❘ October 2001 IT Pro 29
extremely similar. Think of compo-
nent-based objects as the foundation
for distributed software: You build a
service as a separate logical entity and
expose this service to other business
objects.
The Component Object Model
(COM), Corba/IIOP, and Enterprise
Java Beans (EJB) object models are
tools that allow the creation of
reusable software components. Each
of these models works well provided
that cross-platform integration is not
required. Anyone who has tried to
integrate programs across these tech-
nologies knows that doing so is time
consuming and expensive. Web serv-
ices add a compelling, cost-effective
alternative: Communication between
objects is via HTTP, an inexpensive
and easy-to-encrypt network protocol.
The actual network conversation is
encoded in XML, a platform-inde-
pendent and robust definition vocab-
ulary.
Using XML offers tremendous advantages to software
communication. XML is a text-based metalanguage for
creating vocabularies that describe information.For exam-
ple, the following XML snippet describes me:
<Person>
<Name>Tim Chester</Name>
<Email>tim-chester@tamu.edu</Email>
</Person>
XML is also a platform-independent method of describ-
ing data that is both human and machine readable.Because
XML data is expressed within a textual format (as opposed
to binary encoding), it is also language independent, mak-
ing XML-based solutions very flexible. Second, you can
express the structure and relationships within the data with
a document type definition (DTD) or XML schema.This
ability lets computer programs validate the XML data to
ensure that it is structured appropriately.
HTTP is the network protocol that provides the Web’s
foundation. In the Web’s early stages, Web servers pro-
vided access to static documents using HTTP. Today, the
Web server has become a platform for providing access to
dynamic content that is produced in real-time using server
programs and scripts. Because HTTP is also text based,
you can easily use it to exchange XML-based data.This is
the core concept behind the idea of Web services: Encode
data in XML and have client and server converse using
HTTP.
Figure 2 illustrates what a simple Web service might look
like. In this example, I’ve created an ASP document that
receives some posted input and then retrieves information
from our mainframe based on these parameters.The ASP
script encodes both the input and the output in XML.This
script runs on a Microsoft-based Web server (Internet
Information Server) and is Web browser accessible. The
EntireX messaging broker, running on the mainframe,
manages the transaction between the Web server and
OS/390. Physically, this solution’s architecture consists of
a Windows 2000 server, which initiates a call to our main-
frame, using an EntireX Broker COM object when pro-
cessing HTTP requests. (For more details, see the
“XML-Based Communication with the EntireX Broker”
sidebar.)
Now, think about what this architecture achieves. In this
example, I have created a Web server script. The script
accepts input that it uses to initiate a database query writ-
ten in Cobol, which runs on a mainframe. We can expose
this simple Web service to other services on other plat-
forms. A developer, using any HTTP-enabled program-
ming language, can communicate with this Web service by
opening an HTTP connection—just like a Web browser—
and posting XML against the ASP script. The client can
then process the XML response just like the response from
any other database query. Figure 3 (next page) contains
the source code for this simple Web service.
The simple nature of this service makes it elegant,
although there are a couple of issues to resolve. First, the
service does not permit standardized error handling. In
this example, the simple Web service records errors as
attributes in the resulting XML.Although this mechanism
My team has created a custom COM object that facilitates XML-based
communication with SoftwareAG’s EntireX Broker running on the
mainframe. SoftwareAG provides a developer’s tool kit that includes a
similar Java-based XML wrapper. This
XML wrapper provides a simple form of
Web services, similar to that discussed in
this article.
Due to both business and technical
considerations, our organization opted to
create a custom COM object that allows
expanded functionality. This object is
available under the General Public Use
(GPU) open-source license.
A discussion of these issues is beyond
this article’s scope, but interested read-
ers can see http://tim-chester.tamu.edu/
AggieEntireX/ for more information.
XML-Based Communication
with the EntireX Broker

30 IT Pro September ❘ October 2001
can adequately communicate program exceptions, it would
not handle network or HTTP-related errors. Second, the
example doesn’t include a standard way to describe the
Web service, required inputs, and expected return values.
SOAP is an emerging W3C standard that addresses these
shortcomings. SOAP is a network protocol for invoking
methods, objects, components, and services on remote
servers. It uses HTTP and XML just like the simple Web
service in Figure 2.The SOAP specification provides a stan-
dardized XML vocabulary for representing input param-
eters, return values, and errors, encoding this information
in an XML document called a SOAP envelope.
Using SOAP, a program can send and receive both sim-
ple and complex variable types,and receive error messages
in a standardized way. Developers can describe SOAP-
enabled services using Web Services Definition Language.
WSDL is a standardized XML vocabulary that describes
the available methods, input parameters, and return val-
ues of a SOAP Web service. It provides a detailed way to
describe and communicate services to others. Most ven-
dors—including Microsoft, IBM, Oracle, and Sun—are
now providing (or will soon provide) SOAP-enabled prod-
ucts, services, and tool kits. The open source community
has also released SOAP modules for the Apache server
and Perl.
Figure 4 shows the results of converting the simple Web
service from Figure 2 into a SOAP-enabled Web service.
In this example, I’ve SOAP-enabled the COM compo-
nent used to communicate with the mainframe.To do this,
I first created a WSDL file that describes the compo-
nent.These files (including a script called a listener, which
processes incoming requests) are made available from a
Web server.
The Microsoft SOAP Toolkit provides all the tools a
developer needs to create these files for a COM component.
The documentation from Microsoft covers how to create
these files using the SOAP Toolkit wizard.
Once you copy the WSDL and listener files to a Web
M I D D L E W A R E
<%@ Language=VBScript %>
<link REL=“STYLESHEET” TYPE=“text/css” HREF=“title.css”>
<%
‘On Error resume next ‘///enable my own error handling. . .
Response.Expires = -999999
Response.Buffer = true ‘///buffer my response
‘//create your
‘///sample xml send area
‘///let’s create a string variable
‘///that holds my XML send area
Dim strXMLSendArea
strXMLSendArea = strXMLSendArea &
“<GETADDRESS BROKERID=““etb100:18100”““ & vbcrlf
strXMLSendArea = strXMLSendArea &
“ SERVICE=““CCLASS/CSERVER/CSERVICE”“
USERNAME=““““ PASSWORD=“““““ & vbcrlf
strXMLSendArea = strXMLSendArea &
“ FUNCTION=““1”“ WAIT=““30S”“>“ & vbcrlf
strXMLSendArea = strXMLSendArea &
“ <CALLING-FROM>W</CALLING-FROM>“ & vbcrlf
strXMLSendArea = strXMLSendArea &
“ <STUD-ID>555555555</STUD-ID>“ & vbcrlf
strXMLSendArea = strXMLSendArea &
“ <STUD-ADDRESS-TYPE>L
</STUD-ADDRESS-TYPE>“ & vbcrlf
strXMLSendArea = strXMLSendArea &
“ <STUD-BIRTHDATE>19800730
</STUD-BIRTHDATE>“ & vbcrlf
strXMLSendArea = strXMLSendArea &
“</GETADDRESS>“
‘///print out the top of your page first
%>
<h2>Simple Web Service Demonstration</h2>
<p>
<form action=“script.asp” method=“post”>
<textarea COLS = 69 ROWS = 8 name=“xml”>
<%=server.HTMLEncode(strXMLSendArea)%></textarea><br>
<input type=“checkbox” name=“simulation” value=“1”>
Simulate this EntireX transaction?<br>
<p align=“center”>
<input type=“submit” name=“execute”
value=“Execute Web Service”></p>
</p>
<h3>Output:</h3>
</form>
<%
select case (Request.Form(“xml”) <> ““)
case True
‘///declare all the objects
‘///that I will need for this transaction
‘///declare and instantiate
‘///the Aggie EntireX XML Component
‘///using what is referred to as ‘late-binding’
Dim ObjBroker
set objBroker =
server.CreateObject(“AggieEntireX.COMXML”)
Dim strXMLOutput
‘///this is the call to the mainframe
‘///using a custom object which talks to EntireX broker
strXMLOutput = ObjBroker.EntireXTransactionByFile
(server.MapPath(“stillneeds-adapter.xml”), _
Request.Form(“xml”),
server.MapPath(“stillneeds.xsl”))
‘///check for connection error
‘///and or other error coming out of the entirex broker call
if err.number <> 0 then
Response.Write “Error: “ & err.description
Response.End
end if
‘///now let’s take the xml data
‘///and format it using a
‘///so that we can see the data in
‘///a pretty format
set objXMl1 =
server.CreateObject(“msxml2.domdocument”)
set objXml2 =
server.CreateObject(“msxml2.domdocument”)
objxml1.async = false
objxml2.async = false
objxml1.loadXML strxmlOutput
objxml2.load server.MapPath(“output.xsl”)
Response.Write objxml1.transformNode(objxml2)
set objxml1 = nothing
set objxml2 = nothing
end select
%>
Figure 3. Source code for the simple Web service.

September ❘ October 2001 IT Pro 31
server, the SOAP-enabled compo-
nent becomes a Web service that
other clients and servers can use.
The sample code available with
this article includes a simple Visual
Basic client that uses this Web serv-
ice:
Dim soapClient As
MSSOAPLib.soapClient
Set soapClient =
New MSSOAPLib.
soapClientCall
soapClient.
mssoapinit
(“http://
myservername/
GetAddress.wsdl”)
strXML =
soapClient.EntireX
TransactionByFile
(“c:\stillneeds
adapter.xml”),
strXMlInput,
(“c:\stillneeds.
xsl”))
Calling this service is fairly easy
in Visual Basic: Simply create a
SOAP object and pass it the loca-
tion of the WSDL file. The result-
ing SOAP object will have full
access to the object methods
described in the WSDL file.
Variable strXML stores the
return value of the EntireX-
TransactionByFile method. Be-
cause the output is in XML, the
client application can easily con-
vert it into a grid or any other type
of format. If an error occurs in the
Web service, the server encodes
that error within the SOAP
response to the client, which raises
an error. These steps occur auto-
matically; there is no need to parse
the return values for an indication
of success or failure.
INTEROPERABILITY
BETWEEN WINDOWS-,
UNIX-, AND MAINFRAME-
BASED HOSTS
Thus far, I’ve taken a Cobol pro-
Database
Windows 2000
Web server
EntireX
Broker
Cobol
program
IBM OS/390 mainframe
Data services tier
Lo
g
ic
al
ar
ch
it
ec
tu
re
Ph
ys
ic
al
ar
ch
it
ec
tu
re
SOAP
Business
services
(any object,
process,
service, or
platform)
EntireX
Broker
COM
object
Figure 4. SOAP-enabled version of
the simple Web service.
Required Tools
➤ SoftwareAG EntireX Broker
➤ Microsoft Visual Studio 6.0, Service Pack 5 (VB, Vbscript)
➤ Microsoft SOAP Tookit, 3.0, SP 1
➤ SOAP::Lite Perl Module, 0.47
Further Reading
➤ “Web Services and the Simple Object Access Protocol,” Pete Loshin,
MSDN Online, Dec. 1999.
➤ “SOAP: The Simple Object Access Protocol,” Aaron Skonnard,
Microsoft Internet Developer, Jan. 2000, http://www.microsoft.com/mind/
0100/soap/soap.asp.
➤ Understanding SOAP: The Authoritative Solution, Kennard Scribner
and Mark C. Stiver, Sams Publishing, Indianapolis, Ind., 2000.
➤ “SOAP Frequently Asked Questions,” DevelopMentor, http://www.
develop.com/soap/soapfaq.htm.
Other Resources
Source code and this article
➤ http://tim-chester.tamu.edu
Web Services, XML, and SOAP
➤ http://www.develop.com/soap/
➤ http://msdn.microsoft.com/soap/
➤ http://www.soap-wrc.com
➤ http://www.soaplite.com
Resources

32 IT Pro September ❘ October 2001
gram running on a mainframe and created a Web service
using Visual Basic and SOAP. I’ve shown how to make this
service available via the HTTP protocol and discussed how
a desktop PC program built with Visual Basic can use this
service. The physical architecture of this solution contains
Microsoft-based technology (the PC client) talking to other
Microsoft technology (the server), which then talks to a
mainframe.Although this is a good example of how to cre-
ate and use Web services, it is not the best example of inter-
operability.
Let’s add another platform—Sun Solaris (Unix)—into
the mix, as shown in Figure 5.
In this example,a Perl CGI (common gateway interface)
script acts as a client that uses the SOAP Web service I cre-
ated earlier.This CGI script runs on a Sun Solaris (Unix)
server.The open source community was an early adopter
of SOAP, and provided various tool kits for Apache Web
servers and Perl that operate on Solaris.
For this example, I’ve chosen the Soap::Lite and
XML::Parser Perl modules (http://www.soaplite.com and
http://search.cpan.org).Both are free and support any plat-
form that supports Perl. Each is fairly easy to use and
comes with documentation.
Figure 6 lists the sample code for a simple Perl CGI script
that accepts search parameters and then queries the Web
service using the SOAP::Lite module.
This script is fairly complex. It first determines whether
the client has initiated a query. If a query is detected, the
script processes the request using the SOAP Web service
located on the Windows 2000 server. If a query is not
requested, the script generates a simple Web search form.
To use the SOAP Web service, the script creates a SOAP
object by using the following code:
my $soapCall =
SOAP::Lite
->schema(‘http://
myservername/
getaddress.wsdl’)
->on_fault(sub
{my($soapCall, $res) =
@_;
print “<font
color=\”red\”>“;
print $res->
faultstring;
print “</font>“;
exit;
});
This script creates the SOAP
object using the my $soapCall=
SOAP::Lite statement. It then
assigns the WSDL file location to
the schema property. This is the
WSDL file created by the Microsoft SOAP Toolkit; no
modifications are necessary. Next, an error handler is
assigned to the on_fault property of the SOAP::Lite object;
the error handler will execute when the Web service
returns an error.
The following line of code executes the Web service’s
EntireXTransactionByFile method:
my $Result= $soapCall
->EntireXTransactionByFile
(“c:\\stillneeds-Adapter.xml”,
$strxmlsendarea,
“c:\\stillneeds.xsl”);
This code executes the method in a way remarkably sim-
ilar to that of my earlier Visual Basic example:
strXML =
soapClient.EntireXTransactionByFile
(“c:\stillneeds-adapter.xml”),
strXMLInput, “c:\stillneeds.xsl”))
This example takes a software application running
natively on a Windows 2000 server and uses it from an
entirely different platform—a platform that doesn’t
natively support Microsoft-based technology.As Figure 5
illustrates, the physical architecture consists of a Sun
Solaris server that queries a Windows 2000 server, which
then queries a mainframe. The SOAP-based Web service
accomplished this interoperability without anyone pur-
chasing additional application servers or programming a
laborious conversion between COM and Perl.
M I D D L E W A R E
Presentation/business
services tier
Windows 2000
Web server
Web
page
Soap::Lite
Perl
module
Perl
script
IBM OS/390 mainframe
Data services tier
Lo
g
ic
al
ar
ch
it
ec
tu
re
Ph
ys
ic
al
ar
ch
it
ec
tu
re
SOAP
Sun Solaris
Web server
EntireX
Broker
COM
object
Figure 5. Simple Web service with
Perl script incorporated.

September ❘ October 2001 IT Pro 33
It would be appropriate to ask, “Why doesn’t the Sun
Solaris server communicate directly with the mainframe?”
In the present example, the EntireX Broker on the main-
frame does not support XML-based transactions. Also,
forcing all inbound requests through a middle-tier server
offers tremendous advantages. Developers writing clients
can code their requests against a common platform
(SOAP),which runs on a separate server that acts as a cen-
tralized messaging hub. Developers can update the main-
frame database, programs, or files transparently. Making
these changes at the middleware level avoids additional
maintenance for each separate client, an aspect I will dis-
cuss in the next section.
I’ve demonstrated that the SOAP model is platform and
language neutral; other factors are also important. The
SOAP protocol is secure and scalable. You can secure
access to SOAP Web services using HTTP authentication,
and you can require additional security at the program
level. It’s also possible to hide the entire transmission from
prying eyes using secure sockets layer (SSL) encryption.
Because SOAP-enabled Web services leverage HTTP, you
can scale up the service during peak demand by using net-
work load-balancing technologies.
E-COMMERCE ENABLING,
NOT APPLICATION INTEGRATION
Remember the batch application in Figure 1? Let’s
revisit it in light of what I’ve discussed about Web services
#!/usr/local/bin/perl
#written by tim-chester@tamu.edu to demonstrate
#interoperability between COM and Solaris/Perl using
#soap sprotocols
#first thing we are going to do is write out our
#content type for all these transactions
print “Content-type: text/xml\n\n”;
#ok, we have a lot of work to do here so first let’s initialize
#all the perl modules that we will use in this process
use CGI qw(:standard); #use the cgi standard module
use SOAP::Lite + trace=>all; #use the soap lite module
use XML::Parser; #use the perl xml parser module
#get my parameters, if submitted
#via the form
$ssn = param(‘id’);
$dob = param(‘dob’);
$output = param(‘output’);
#first, determine whether this is a get or a post
#if data is posted it has to be processed, if it isn’t
#a post, then simply generate the webform
if (!param()) {
print “<?xml version=\”1.0\”?>“;
print “<?xml-stylesheet type=\”text/xsl\” href=\”default.xsl\”?>“;
print “<GETADDRESS></GETADDRESS>“;
}
else
{
&processHTTPPost;
}
#my subroutines start
#here. . .
sub processHTTPPost {
#’//create a send area
#’////in xml format
$strxmlsendarea = “&lt;GETADDRESS
BROKERID=&quot;etb100:18100&quot; “;
$strxmlsendarea = $strxmlsendarea .
“SERVICE=&quot;CCLASS/CSERVER/CSERVICE&quot;
USERNAME=&quot;&quot; PASSWORD=&quot;&quot;”;
$strxmlsendarea = $strxmlsendarea .
“FUNCTION=&quot;1&quot; WAIT=&quot;30S&quot;&gt;”;
$strxmlsendarea = $strxmlsendarea . “
&lt;CALLING-FROM&gt;W&lt;/CALLING-FROM&gt;”;
$strxmlsendarea = $strxmlsendarea .
“&lt;STUD-ID&gt;$ssn&lt;/STUD-ID&gt;”;
$strxmlsendarea = $strxmlsendarea .
“&lt;STUD-ADDRESS-TYPE&gt;L&lt;
/STUD-ADDRESS-TYPE&gt;”;
$strxmlsendarea = $strxmlsendarea .
“&lt;STUD-BIRTHDATE&gt;$dob&lt;/STUD-BIRTHDATE&gt;”;
$strxmlsendarea = $strxmlsendarea . “&lt;/GETADDRESS&gt;”;
#create a soap object called $soapCall
#just plug in the wsdl schema created by the microsoft soap
#toolkit and you will be in business
#embed error handler in the object
my $soapCall= SOAP::Lite
->schema(‘http://tim-chester.tamu.edu/soapwebservice/
soapwebservice.wsdl’)
->on_fault(sub { my($soapCall, $res) = @_;
print “<font color=\”red\”>“;
print $res->faultstring;
print “</font>“;
exit;
});
#execute the soap (com on the win2000 side) method and
#pass it two parameters from cgi. store the resultset in the
#$Result object. Error handling will trap errors. . .
my $Result= $soapCall->EntireXTransactionByFile
(“c:\\stillneeds-Adapter.xml”,
$strxmlsendarea, “c:\\stillneeds.xsl”);
#if this code runs that means an error didn’t occur
#we have data now do something with it
#’’//remove the xml encoding tag
#’///because we will replace it below
substr($Result, 0, 39) = ““;
if ($output eq “table”) {
#user selected xml output
#use the xml stylesheet
print “<?xml version=\”1.0\”?>“;
print “<?xml-stylesheet type=\”text/xsl\”
href=\”table.xsl\”?>“;
print $Result;
}
elsif ($output eq “format”) {
#user selected xml output
#use the xml stylesheet
print “<?xml version=\”1.0\”?>“;
print “<?xml-stylesheet type=\”text/xsl\”
href=\”label.xsl\”?>“;
print $Result;
}
else {
#user selected xml output
#use the xml stylesheet
print “<?xml version=\”1.0\”?>“;
print “<?xml-stylesheet type=\”text/xsl\”
href=\”xmlOutput.xsl\”?>“;
print $Result;
}
}
Figure 6. Perl CGI script based on SOAP::Lite module.

34 IT Pro September ❘ October 2001
and SOAP. Using Web services, a developer can break
down the eight processes in Figure 1 into three critical serv-
ices, shown in Figure 7, one each for
• processing credit card transactions,
• posting information to the student information data-
base, and
• printing the necessary parts of the admission application.
At first, EDI-formatted files would continue to play an
important part in this new architecture. Both trading part-
ners continue to transfer completed admission applica-
tions using EDI.They transfer this information via FTP to
a central server that acts as an information gateway. This
server then takes the applications and processes the infor-
mation. For each application received, the gateway server
would synchronously initiate separate SOAP transactions
for credit card processing, database posting, and printing.
If an error occurs, it can be handled in real-time.With addi-
tional modifications, each trading partner could migrate
their applications away from EDI formats and begin using
these three Web services to transfer the required infor-
mation.
Don’t underestimate the gateway server’s role in the Web
service model. Not only can it process incoming admission
applications, but an enterprise could also route all other
inbound transactions through this server. Such a gateway
provides additional levels of security because all inbound
requests must pass through one centralized service. In turn,
the gateway server passes the
request to the appropriate destina-
tion service. This is the role that
messaging products—such as
IBM’s MQSeries, Microsoft’s
BizTalk Server, and SoftwareAG’s
EntireX Broker and Tamino—can
play within a data center.
The challenge to developers is to
think about how they can use the
Web services architecture to facili-
tate communication among differ-
ent computer systems. Although
the example Web service used here
is simple, it is representative of how
distributed computing systems
should communicate. This repre-
sentation holds true regardless of
whether you are building one or
two simple objects, or dozens.
T he need to integrate complexbusiness software applica-tions is not new. Until
recently, the tools and technologies
available for this integration were either crude—like using
FTP batch transfers—or too tightly coupled to proprietary
technologies.Most firms have used crude methods for inte-
grating software applications, with some success. EDI-
based transactions have allowed large organizations to
manage inventories and transmit purchase orders. Despite
these successes, this model of commerce is flawed because
it is cumbersome, is difficult and expensive to create and
maintain, and does not permit clients to initiate transac-
tions in real-time with instantaneous feedback.The emerg-
ing XML and SOAP standards address these
shortcomings. 
Timothy M. Chester is a senior IT manager for application
development, Computing and Information Services, Texas
A&M University, College Station,Tex. He is also on the fac-
ulty at the College of Business, where he teaches courses on
business programming fundamentals and XML. Contact
him at tim-chester@tamu.edu.
For further information on this or any other computing
topic, please visit our Digital Library at http://computer.
org/publications/dlib.
M I D D L E W A R E
Off-site
credit
card
processor
ActiveX
API
SOAP-enabled
credit
card
processing
Student
Information
System
(Adabas)
Natural
subprogram
SOAP-enabled
student
information
posting
Natural
subprogramSOAP-enabled
application
printing
FTP transfer
of EDI
information
EDI
processing
server
Internal
admissions
applications
(Oracle/Unix)
Off-site
common
applications
(Adabas)
Figure 7. Revamped batch process that
incorporates Web services and SOAP.