SOAP runtime files

[Mike Lewis]

I have developed an application that uses SOAP to run a web service. It works fine on machines that have VFP 9.0 installed. But when I try to run it on an end-user's system, it cannot access the web service.

According to the VFP Help, I need to include some SOAP client runtimes in the distribution, but there is no indication of what runtime files to include or whether they should be registered.

Does anyone have any experience of calling a web service from an application? If so, can you point me to the appropriate runtime files?

Thanks in advance.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Mike Lewis]

Problem solved (at least, it might be).

After some digging around, I found a directory on my system containing a bunch of DLLs for the Microsoft SOAP Toolkit. I don't know exactly what each of these DLLs is, or whether it should be registered. But I've now added them to the distribution, and it seems to be working OK.

This is not an ideal solution. Chances are that I don't need all these files and they don't all need to be registered, but I couldn't find any further information to help me home in on the essential ones.

If anyone has the same problem, the files in question are as follows. They are all in <program files>\Commmon Files\MSSoap or its subdirectories:

mssoap1.dll
mssoap30.dll
soapis30.dll
WHSC30.dll
wisc10.dll
WISC30.dll
MSSOAPR3.dll
mssoapr.dll

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

I'd say all you need to redistribute is the Soap Toolkit redistributable :

http://www.microsoft.com/downloads/...FamilyID=ba611554-5943-444c-b53c-c0a450b7013c

Perhaps you'll also need redistributables of MSXML3 and 4 additional to that. At least to support VFP XML functions and the XMLAdapter.

Bye, Olaf.

 

[Mike Lewis]

Thanks for that, Olaf.

I had already seen the download you referred to, but unfortunately it only leads to a merge module. The problem is that my client uses Inno Setup rather than a Windows Installer system, so merge modules aren't very useful. (I did consider creating a dummy install with the merge module to see which files it installed, but I couldn't see any easy way to do that.)

I take your point about the MSXML files. I found on another project that these are necessary when using the XML Adapter in VFP. In the present project, the web service doesn't return XML, so I'm hoping they won't be necessary. I'll find out next week when I send the distributable to the client.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Okay,

I wouldn't know how to determine where a merge module installs which files, so I second you, that creating a dummy install with that merge module wouldn't give insights, but perhaps ISE coming with foxpro will already show you what files are in it, before you even create a setup.exe of it - that could be enough insight.

I'm not sure if soap classes will use msxml classes directly or indirectly. Soap and XML are rather involved with each other. If the web service you want to use doesn't use XML I wonder what SOAP wil have to do with it, as SOAP envelopes sent back and forth in soap based web services are already XML.

Bye, Olaf.

 

[Nigel Gomm]

Mike,


could you distribute the msm file in your inno script, install it to the user's temp folder and run msiexec /package xyz.msm /qn

i'm not too familiar with inno but something like
[Run]
filename :msiexec; parameters : "/package {tmp}\xyz.msm /qn"

?

nigel

 

[Mike Lewis]

Olaf,

I was also wondering about Soap using MSXML internally. I'll try my install on a new laptop later today, and see if it works without MSXML.

Nigel,

Your idea sounds like a good possibility. I'll keep it in mind in case anything goes wrong with my present plan.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[dbMark]

SoapClient - uses mssoap1.dll and mssoapR.dll

SoapClient30 - uses mssoap30.dll and mssoapR3.dll

I would suggest to always use the newer 3.0 version, it has more option and is more robust, though of course Microsoft plans no further development for SOAP.

obj = CREATEOBJECT("mssoap.soapclient30")
obj.ClientProperty("ServerHTTPRequest") = .T.  && new for 3.0
* [URL unfurl="true"]http://msdn.microsoft.com/en-us/library/ms766434(VS.85).aspx[/URL]
* Setting ServerHTTPRequest property to True uses WinHTTP.dll (actually, WinHTTP5.dll) rather than WinInet.
* WinHTTP is server-safe, but lacks support for asynchronous mode and is unavailable in Windows 98/Me.
* WinInet is widely available but unsafe in multi-thread and server environments.

http://support.microsoft.com/kb/321512

the ClientProperty setting ... determines whether to use the server-safe XML components to load the WSDL and the Web Services Meta Language (WSML) files. Set the server-safe setting to True when an ASP application or an ISAPI DLL uses the SOAP client object.

I believe this is required: MSXML 4.0 SP2 (KB936181)

The server's registry also will have several SOAP settings and some will likely need to be adjusted based upon your needs. The only one I changed was MaxPostSize.

Real World XML Web Services by Yasser Shohoud

http://books.google.com/books?id=P4pJdn2MH64C&printsec=frontcover#PPP169,M1

http://yassers.com/content/book/chapters/chapter5.htm

(at end of chapter)
It explains the 4 entries for MSSOAP:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSOAP\30\SOAPISAP\
MaxPostSize - increase to allow larger files
NoNagling - set to 1 and it may speed up server response (avoids 200ms pause delay)
NumThreads - default is two threads per CPU plus one
ObjCachedPerThread - should be at least how many Web services may call it

· MaxPostSize is important to configure if you expect request messages that exceed 100KB in size which is the default permissible size. When you change this setting, be sure to switch to Decimal base and keep in mind that 1 KB=1024 Bytes.
The default hex value is set extremely low, about 100K decimal equivalent as I recall, so as to reduce the risk of DOS attacks crippling a server. With it set at 100K, it will be able to handle an incoming XML about 65K in size. In my tests you need to calculate your maximum XML size, pad that a little higher just in case, then add at least 50% overhead to that figure for the value to place here.

· NoNagling turns off the nagling delay. By default, when a service responds with a small message, this response might be buffered for a while before being sent to the client. This is a TCP optimization that tries to maximize the payload sent with each TCP packet by waiting to see if there’s more data to send before sending a packet. Normally, having nagling delay on is a good thing but if your service’s response messages are small and the performance you’re getting is much worse than expected, you can try to turn it off by setting the NoNaggling value to 1.

· NumThreads is the number of threads handling incoming requests. Normally the default (2 threads per CPU plus an extra thread) is close to optimum. You should try increasing this number only if the request queue gets too long (as indicated by the queue length perf counter). You should know however that too many threads is not a good things: It causes CPUs to spend too many processing cycles switching between thread contexts rather than performing useful work.

· ObjCachedPerThread is the number of objects cached per thread. The ISAPI listener will cache a SoapServer30 object for each Web service you have exposed (just like the ASP listener does). So this number should be at least the number of Web services exposed via the ISAPI listener.

 

[Mike Lewis]

Thanks for that info, dbMark.

I'm pleased to say that the DLLs I listed above have solved the problem for me (so far). All the users are up and running, without any further difficulties. But I'll keep your post in mind in case I need it at some point.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business