PHP: Exposing web services - Part 2
In part 1 of this post, we had a quick look at how to expose webservices using the NuSphere Soap Library.
PHP 5 does however have support (in the form of an extension) for SOAP services - which should be superior performance wise (C++ based etc) to the NuSphere implementation.
There is a little hiccup though, we are required to provide a WSDL file to make this process work (consumption/exposion wise). Now instead of explaining the tedious details of how to write the required XML, we're simply going to use the WSDL generated from the NuSphere library in the first post (e.g. index.php?wsdl).
Observe the following snippet:
$server = new SoapServer("definitions.wsdl"); $server->addFunction(SOAP_FUNCTIONS_ALL); $server->handle(); function test($name) { return "Hello $name"; } // other functions omitted
- Save the generated WSDL to definitions.wsdl, and pass it to the SoapServer Class.
-
The SOAP_FUNCTIONS_ALL constant tells the class to add/register all functions defined
within the WSDL - we're also able to simply register specific functions
e.g. $server->addFunction("test");
Alternatively one can set a class thats responsible for handling the requests/functions defined within the WSDL.
class Tester { public function test($name) { return "Hello $name"; } // other functions omitted } $server = new SoapServer("definitions.wsdl"); $server->setClass("Tester"); $server->handle();
Note that we can make the class instance persistent as well - useful if we're going to call multiple methods.
Observe:
class Tester { public $name; public function test($name) { if ($name != "") { $this->name = $name; return "Hello $name"; } else { return 'Hello '.$this->name; } } } //ini_set("soap.wsdl_cache_enabled", 0); //ini_set("session.auto_start", 0); //ini_set("session.use_cookies", 1); //session_start(); $server = new SoapServer("definitions.wsdl"); $server->setClass("Tester"); $server->setPersistence(SOAP_PERSISTENCE_SESSION); $server->handle();
In the preceding snippet you will notice four lines that are commented out, now while doing research I found a number of sites that stated that it is required to start sessions etc in order to enable persistence.
However while doing testing (on my linux & windows dev environments), it persisted fine without needing any of those commented out lines of code (perhaps I am missing the point - I can be wrong, someone?), it seems to be enough to simply use
$server->setPersistence(SOAP_PERSISTENCE_SESSION).
Something else I noticed in regards to persistence, while attempting to consume the service using .NET (something which might provide us with a clue to how the persistence actually works), is that persistence failed in .NET while it worked fine using PHP.
The reason being that we need to enable cookies for those requests in our .NET based code.
When consuming the service using the older .NET 2.0 based webservice tech, we need to instantiate a cookie container, e.g.
com.example.www.TestService t = new com.example.www.TestService(); t.CookieContainer = new System.Net.CookieContainer();
When using WCF we don't have a CookieContainer property like seen in the older model, instead we need to set the allowCookies attribute within our settings (e.g. web.config/app.config etc) file.
<system.serviceModel> <bindings> <basicHttpBinding> <binding name="TestServiceBinding" allowCookies="true"
In conclusion I feel this is an useful and simple class to use, except for the lack of WSDL generation - which isn't much of a problem in my opinion - would however be nice if we didn't have to rely on other components/tools or write the WSDL ourselves.
It should be fairly simple to derive our WSDL definition from our handling class - perhaps something I can look at in a future post.
Enjoy.
Posted by - Christoff Truter
Date - 2010-12-11 12:42:45
Comments - 0
Date - 2010-12-11 12:42:45
Comments - 0
Office Shared Add-ins: Issues - Part 2
The following issue I find to be quite an interesting one, took some digging and guessing to figure this one out - perhaps this can save someone some time.
A while ago we created some shared add-ins for office 2007 & 2003 using Visual Studio 2008, the add-ins worked great, but on some Office 2003 machines it didn't work at all. The moment the office application started, it disabled these add-ins immediately.
The reason being that Office 2003 doesn't natively support .NET (managed) based shared add-ins - for this reason (among others) Microsoft released a patch KB908002.
There is however a funny thing regarding this patch, it requires Visual Studio 2005 and Microsoft didn't include this fix in Visual Studio 2008 (and I couldn't find a 2008 specific version of the patch).
The workaround is simple though, this patch added a prerequisite to the contents of KB908002 to Visual Studio 2005, which we need to deploy to the end user machine - the prerequisite itself doesn't actually require Visual Studio.
What we need to do is to extract the prerequisite and manually add at it to the folder containing deployable prerequisites for Visual Studio 2008.
Step 1
Download the patch from http://support.microsoft.com/kb/908002.
Step 2
Extract the files from the patch e.g.
vs2005-kb908002-enu-x86 /c /t:c:\kb908002Step 3
Extract the bootstrapper e.g.
msiexec /a C:\kb908002\bootstrapper.msi TARGETDIR=C:\kb908002\bootstrapperStep 4
Copy the contents of
C:\kb908002\bootstrapper\SDK\BootStrapper\Packages
to
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages
Step 5
To find the prerequisite dialog:
> right click on your setup
> select properties
> click on prerequisite
You will notice an item called Shared Add-in Support Update... in the list (the one we just added), tick this item to include it as prerequisite for Office 2003 add-ins.
As soon as you run the setup, you will notice the following window:
Once we click on install, this will register/install the assemblies (like Extensibility.dll) required to run shared add-ins on Office 2003.
Posted by - Christoff Truter
Date - 2010-11-29 11:34:50
Comments - 1
Date - 2010-11-29 11:34:50
Comments - 1
First 6 7 8 9 10 11 12 13 14 15 Last / 62 Pages (124 Entries)