Friday, April 15, 2005
SOAP, Data Definitions & Port
SOAP ... Simple Object Access Protocol. Web services are becoming a very important part of any business today. Amazon.com for example. Where would they be without there web services? SOAP is the communication protocol from one application to a web service provided on a server somewhere. My recent forray into web services involved my investigation, and implementation of a web service using the MS SOAP toolkit.
The basic run down is like this. We need to build a web service. We have the brains of things in VFP applications. A new system in PHP that needs to make use of this web service. One would think it would be easy to do this. I would say it's easy now that I have it figured out. I spent most of three days making all of the parts work properly to allow the PHP site to execute 3 lines of code.
The entire SOAP protocol is hidden underneath the scenes. I do not have to worry about the XML creation. The wsdl is taken care of by VFP. I do not have to worry about the SOAP envelopes. Connections are handled. I simply create and call. Getting this to work was no small feat however. When you think about it there are so many different parts at work here. SOAP is a very complex idea. Where do you start when something goes wrong?
Is the problem in the PHP code? Is the problem in the PHP library code used, or the PEAR module used? Is the problem on the client web server? Is the problem on the receiving IIS server? Is the problem in the connection bewteen the two? Is there a problem with access restrictions? Is the problem in the VFP code? Is the problem with windows not releasing the dll once it has been loaded and recompiled? Is the problem with the generated web service files? As you can see there are lots of areas to look into. I looked into all of these and more.
I have very little experience with VFP. However if you have written code once it's pretty much the same all over. Subclass from an OLE session, create a simple procedure and compile the prg as a dll. VFP provides a tool kit for working with and publishing XML services. You need access to a working IIS server. You create a virtual directory, and use the VFP publisher to generate your WSDL, and web service files for your com object into the virtual directory. That is a task that needs careful attention to details, and making sure every setting is exactly correct. You also need to be careful that the IIS directories, and the on disk directories have proper access and sharing set up. I needed to allow access on the directory with the generated files, and the directory with the dll with read, write, and execute appropriately for the web service to work.
I would suggest testing the web service in VFP before going to test it out from server to server. At least you would know that the web services is functional, and would know that any problems would arise from your client code. PHP has built in SOAP functions. I thought I couldn't use them, then realized I was trying on a windows machine. I switched over to the Mac OSX server where SOAP is enabled. I tried both the built in module, and the PEAR module for SOAP. I found the PEAR module just as easy to use, and underlying calls actually made use of the built in SOAP client anyways (IIRC). I went with the built in module. One less thing to worry about.
It's all working now with a basic service taking a string parameter. We are going to send the data accross in XML as well. It does seem rather funny to me to use XML to set up communication to a com object just to pass it some XML. Why not just make a simple listener that takes a variable containing XML in a POST var? Then one side would have to handle things. I think this makes it easier in the VFP world, but it does seem like a great deal of overhead to me.
Now that the SOAP communication was working I moved on to some new tasks of mapping data we collect into the proper format. I have a spec to work off of, and map my data names to 7 digit codes in the spec. There are about 250 or so fields. I tell you it sucks going cross eyed flipping between pages, and screens. Looking from a document to a PGSQL table definition, and trying to figure out the this column named "foobar" is really supposed to be data ID 8000100. Working with a numbered spec like this brought back memories of my earlier career days working at SED Systems in Saskatoon. This current spec is rather small. I remember spec documents for the Space Station project where it was over 100 pages of tables defining codes, ranges, signals, changes and all sorts of other fun things on the test beds. I loved going through them, and comparing to the previous version, and seeing what had changed. ;-)
On the lighter side of things, I have really gotten into drinking port. Marshall likes to drink port with me right? He doesn't like the hangovers though. He started to get scared when the third day in a row I brought a new bottle home with me and said "Wnat some port Marsh?". All he said "Oh God". He had some all the same. It's Friday, I may have to pick up a new bottle on the way home today.
On another drunken Marshal note. We decided to BBQ awesome hamburgers from Thrifty's rolled in peppercorns. He was cooking, and moving cheese burgers from hot grill to plate. Lets just say there is a big splotch of cheese on the patio now. "Andy ... I need more cheese" Needless to say that was his burger. ;-)
Now I'm hungry. ¶ 1:12:00 PM
The basic run down is like this. We need to build a web service. We have the brains of things in VFP applications. A new system in PHP that needs to make use of this web service. One would think it would be easy to do this. I would say it's easy now that I have it figured out. I spent most of three days making all of the parts work properly to allow the PHP site to execute 3 lines of code.
That may seem like a whole lot of work to do that. But it's pretty slick in the end. It's actually cool when you think about what really happens in there. A VFP application is built as a multi-threaded dll. You then publish your com object as a webservice to an IIS server. You even get to select what methods are made public by this web service. All of the needed files are generated for you, and VFP even offers a testing application for web services to make sure it works. In this simple case I create a SOAP client object in PHP based on the WSDL file published by my web service. This creates an new class and provides methods that match the public methods of the web service. I can simply call these methods from my new object, and pass any parameters as needed.
$client = new SoapClient($wsdl_url);
$which = "BYE";
$rv = $client->hello($which);
The entire SOAP protocol is hidden underneath the scenes. I do not have to worry about the XML creation. The wsdl is taken care of by VFP. I do not have to worry about the SOAP envelopes. Connections are handled. I simply create and call. Getting this to work was no small feat however. When you think about it there are so many different parts at work here. SOAP is a very complex idea. Where do you start when something goes wrong?
Is the problem in the PHP code? Is the problem in the PHP library code used, or the PEAR module used? Is the problem on the client web server? Is the problem on the receiving IIS server? Is the problem in the connection bewteen the two? Is there a problem with access restrictions? Is the problem in the VFP code? Is the problem with windows not releasing the dll once it has been loaded and recompiled? Is the problem with the generated web service files? As you can see there are lots of areas to look into. I looked into all of these and more.
I have very little experience with VFP. However if you have written code once it's pretty much the same all over. Subclass from an OLE session, create a simple procedure and compile the prg as a dll. VFP provides a tool kit for working with and publishing XML services. You need access to a working IIS server. You create a virtual directory, and use the VFP publisher to generate your WSDL, and web service files for your com object into the virtual directory. That is a task that needs careful attention to details, and making sure every setting is exactly correct. You also need to be careful that the IIS directories, and the on disk directories have proper access and sharing set up. I needed to allow access on the directory with the generated files, and the directory with the dll with read, write, and execute appropriately for the web service to work.
I would suggest testing the web service in VFP before going to test it out from server to server. At least you would know that the web services is functional, and would know that any problems would arise from your client code. PHP has built in SOAP functions. I thought I couldn't use them, then realized I was trying on a windows machine. I switched over to the Mac OSX server where SOAP is enabled. I tried both the built in module, and the PEAR module for SOAP. I found the PEAR module just as easy to use, and underlying calls actually made use of the built in SOAP client anyways (IIRC). I went with the built in module. One less thing to worry about.
It's all working now with a basic service taking a string parameter. We are going to send the data accross in XML as well. It does seem rather funny to me to use XML to set up communication to a com object just to pass it some XML. Why not just make a simple listener that takes a variable containing XML in a POST var? Then one side would have to handle things. I think this makes it easier in the VFP world, but it does seem like a great deal of overhead to me.
Now that the SOAP communication was working I moved on to some new tasks of mapping data we collect into the proper format. I have a spec to work off of, and map my data names to 7 digit codes in the spec. There are about 250 or so fields. I tell you it sucks going cross eyed flipping between pages, and screens. Looking from a document to a PGSQL table definition, and trying to figure out the this column named "foobar" is really supposed to be data ID 8000100. Working with a numbered spec like this brought back memories of my earlier career days working at SED Systems in Saskatoon. This current spec is rather small. I remember spec documents for the Space Station project where it was over 100 pages of tables defining codes, ranges, signals, changes and all sorts of other fun things on the test beds. I loved going through them, and comparing to the previous version, and seeing what had changed. ;-)
On the lighter side of things, I have really gotten into drinking port. Marshall likes to drink port with me right? He doesn't like the hangovers though. He started to get scared when the third day in a row I brought a new bottle home with me and said "Wnat some port Marsh?". All he said "Oh God". He had some all the same. It's Friday, I may have to pick up a new bottle on the way home today.
On another drunken Marshal note. We decided to BBQ awesome hamburgers from Thrifty's rolled in peppercorns. He was cooking, and moving cheese burgers from hot grill to plate. Lets just say there is a big splotch of cheese on the patio now. "Andy ... I need more cheese" Needless to say that was his burger. ;-)
Now I'm hungry. ¶ 1:12:00 PM
