Getting started with Middleware Web Services
Background and Basic RequirementsThe general idea is that a web service is a client/server application which exchanges data in the form of XML documents. The protocol for doing this is called "SOAP" and all data is transported with HTTP. Other transport protocols can be used, but HTTP seems to be the most prevalent. The client and server need not be of the same architecture, operating system or programming language or even on the same network. Web Services provide methods to applications as if those methods were from libraries installed locally. In most programming environments, a "SOAP" object is instantiated and methods are called upon it using XML documents as inputs and outputs. Consider a fictional identifier translation web service: There is a method which accepts as input an XML document which represents a list of PeopleSoft "emplids." That method will do some processing and return an XML document which represents a list of Internet email addresses associated with those emplids. The application developer does need not to be concerned with the backend database operations which would most likely involve both Oracle (PeopleSoft) and LDAP (Sun One Directory Server 5.2). All the developer has to do is first format the input XML correctly, pass it to the SOAP client then extract and process the response XML. It is difficult to learn how to do this at first in most languages since the XML is abstracted by object orientation, however in the long run it is easier then attempting to manage Oracle and LDAP connections and the structure of data in those stores.Middleware would write and maintain the method that does the translation from emplids to email and formats the output XML appropriately. Application developers are left to focus on what their business rules are and the proper format of the input XML. Learning web services is a two step process of first figuring how the environment makes and configures SOAP objects and connections and then learning how to extract data from returned objects which represent XML documents. Middleware has worked with SOAP clients in Perl,PHP,Java,Visual Basic 6.0 and VBScript(Microsoft Soap Toolkit 2.0). Middleware is most familiar with Perl based web services clients and can offer the most assistance if Perl is used as the client.There are a few technical requirements of the SOAP client software and these are:
With this in mind, some SOAP clients will work whereas others will not, even though they advertise "SOAP/web services" compatibility. Our services operate as a shared infrastructure, so we try to avoid writing services that are specific to one particular project or application. We aim to write libraries of reusable code that can fit multiple sets of UW business models and rules. WSDL Files, Toolkits and Web Services:Okay, here's how you find out the information you need to know. First go to a regular web browser and load in the WSDL file. The WSDL file describes which methods and XML documents a web service provides. http://rpctest.services.wisc.edu/Test.wsdl It is important that you understand the components of a WSDL file, there are many resources on the Internet. (Google it.) But here's a quick HOWTO on extracting variables from WSDL files which you will need to specify when configuring your client's toolkit. Go all the way to the bottom of the NetID.wsdl until you find the <wsdl:service> element. There you will find the service name and port names. Write these down, they are usually specified in most toolkits at the same time the url of the WSDL is specified. Go back up a bit to the <wsdl:binding> element. There you will find all of the operations. These are the methods or operations (library functions) that can be called. The notion of a class (e.g. a collection of methods) is called a portType in wsdl. You can find that by looking for the <wsdl:portType> element. Note that the method names are here as well. This is usually only important for .NET and Java clients as classes are built from the port types. Check out the <wsdl:types> section for the format of XML input and output messages. Each method will have it's own format depending on the information it accepts or returns. This is expressed in XML Schema, which is something useful to be familiar with. Some toolkits do all of this for you without needing to generate stub classes, shims or any other go-between and it works like this:
Toolkits which do this:
Toolkits that generate proxy/stub classes which require more programming effort:
Technical Details about our Web Services and WSDL files:
DebuggingOne of the best debugging aids is to actually look at the XML and HTTP headers on the wire as they go out. It's often easier to build a client looking at an example capture that works, then tweaking your code to produce the same result. Perl's SOAP::Lite client has a great debug switch that'll do just that. Sample Code #!perl use UWDS::WebService; my $service = "NetID"; foreach my $question (@result) { POST http://localhost/services |