I'd like to get rid of the microsoft soap3 dlls in our webservice communication. The main reasons are performance and error handling.

Microsoft's soap3 dlls are quite picky about binary characters in the data you're sending over the wire. We have to base64 encode quite a lot.

Microsoft's soap3 dlls don't support automatic gzip/deflate compression and decompression.

And they do not handle errors correctly. COMRETURNERROR() results in "OLE-IDispatch exception code 0 from Client: Client:Loading the request into SoapReader failed. HRESULT=0x80070057: Wrong Parameter". The reason behind this is IIS sending text/html while microsoft's soap3 client dll is expecting text/xml.

The heart of our webservice is a vfp9 MTDLL. Micosoft's soap3 dlls are just a wrapper around it.

I'd prefer to replace microsoft's soap3 dlls with a C# based wrapper at the server and clients in vfp9 and C#. The clients should use simple http POST. gzip/deflate compression should be handled automatically by server and clients.

Any ideas?

TIA,

Markus

The SOAP Toolkit was always more of a skunk works project at Microsoft and there are lots of issues with it and it's been discontinued for a very long time even prior to VFP's discontinuation.

It's pretty straight forward using the .NET tools for this and they are reliable.

There's a bunch of info in this White Paper:

• Creating and Consuming FoxPro Web Services

We also have a tool that automates much of that process, creating the proxy for you and creating a FoxPro wrapper class to call the service along with the registrationless COM hookup via wwDotnetBridge and error wrappers for dealing with error handling effectively.

• West Wind WSDL Proxy Generator

Using the .NET tools is the way to go as they are kept up to data and can navigate just about any service thrown at it. The tools I mention here support SOAP 1.x only though - not WS* based services. If you want to go that route then you need to use WCF explicitly and call that from FoxPro - roughly the same process, but you need to manually configure the exact protocol settings in the WCF client which for most WS* services is ugly to say the least.

+++ Rick ---

Hi Rick,

thanks for the reply. After reading all this, and a few more articles linked from these pages...

1. The whole "webservice" thing is just overhead I don't need. A simple web page that accepts POST parameters and returns data is enough.

2. Using .NET 4.6.2 is it still true that your StaHttpHandler in Creating-STA-COM-compatible-ASPNET-Applications will give me the best performance possible when I have to call vfp code from a c# "web page"?

3. Does StaHttpHandler automatically compress (gzip/deflate/whatever) my requests and responses while traveling over the wire?

4. What's the most performant way to do http POST from vfp9 clients? API calls to WinInet.dll like wwIPStuff or wwHttp? Or what else?

TIA,

Markus Winhard

If you're going to call FoxPro code why not just use something like Web Connection that has built in support for REST services?

You STAHttpHandler is the lowest level approach you can take yes - not that it makes a difference if you end up calling COM objects since the overhead of the single COM call will be exponentially more expensive than the entire rest of the request.

Building raw handlers is not particularily nice though - because you have to handle everything yourself.

Personally I would use some sort of framework.

• REST CallbackHandler

It doesn't have the STA code directly associated with it (no .NET framework will do that out of box) but it'd be fairly easy to add.

+++ Rick ---

Hi Rick,

OK. Let's discuss the server part first.

We already talked to our boss regarding web connection or active foxpro pages and he said no.

I don't want to change the data format that travels over the wire. Therefore I'm not looking for something like your Rest CallbackHandler.

You say that the overhead of the single COM call will be exponentially more expensive than the entire rest of the request. So it should be OK to start with a single asp.net WebForm that returns data instead of html. Right?

But the question is still: How do I force IIS to automatically gzip/deflate the result?

TIA,

Markus

As always you are cryptic about your actual needs 😃

What format is 'your current format'? SOAP? If so ASMX services is the way to go. You gain nothing in ease of use by doing it manually with ASPX and lose terribly by trying to do your own XML parsing and serialization which is going to be inefficient and most likely incorrect.

This:

• ASMX Web Services and STA Handlers

All of the workarounds revolve around the same STA handler that ASPX WebForms use and this approach works just fine with all the limitations implied by doing COM interop in the first place.

I know this works - I've built a number of services using FoxPro data - some fairly heavy duty - that work reliably.

As to GZip compression:

• HttpWebRequest and Gzip

This has code for the server side. On the client side you need to have a tool that can automatically handle GZip compression. wwHttp in the Client Tools does this with the wwHttp::lAllowGzip property on requests. If set it'll check the incoming request for Gzip compressed content and unpack it.

+++ Rick ---