PHP, Soap and WSDL Caching
Today I was offered a free lesson in how PHP handles Soap, and more specifically WSDL caching.
When you instantiate a PHP Soap Class you pass it a WSDL (Web Services Description Language) and it looks like this:
$client = new SoapClient('http://example.com/services/thescript.php?wsdl');
Depending on how your caching is setup, this will go out to the WSDL provided, pull in the document and store it in a cache. The default cache for PHP is 86400 seconds. If you are familiar with time in seconds you know that that is 24 hours. So by default you only actually read the WSDL once in a 24 hour period. Normally this is not a problem.
What is a WSDL?
For that answer let's turn to the W3 site:
WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.
So in English that means it is a map to the services provided by the provider. Basically you get a copy of the map, and follow the endpoints to the answers you need.
One basic function of this is that it tells you want methods (services) are available on your fresh client.
When WSDLs go bad
So today one of my providers, without warning, updated their WSDL. This wreaked havoc on my system because I had cached the WSDL on my side for 24 hours (remember, the PHP default). The change was a super simple change, a change in URL for a service, that's it!
The problem was that since PHP had already read the file within 24 hours it didn't care that there was a new file, that the URLs had changed, and so it continued to work as it had before.
The real problem wasn't that the URLs changed, that would have been fine if the provider hadn't shut off the previously reported URLs.
Turn off the cache
So you are left with two options when something like this happens. First, you can sit and wait up to 24 hours for the problem to fix itself. This was not an option for us. The second is to clear your cache and try again.
Now PHP (on Linux) stores the cache for the Soap WSDL in /tmp and I wasn't sure which one of the many files was the actual cache for this particular provider so I decided I would have to tell PHP to not cache the WSDL and try again.
Into php.ini I went, located the soap.wsdl_cache_enabled flag. I changed it from 0 to 1
soap.wsdl_cache_enabled=0
I saved the file and restarted Apache.
The service continued to fail. I was perplexed. I thought maybe I flubbed the save so I opened the php.ini again located my line and it was fine. So I looked around there to see if maybe I missed another important flag. The only thing I could find was soap.wsdl_cache_ttl listed as the "(time to live) Sets the number of second while cached file will be used instead of original one" I promptly changed this to 0 as well
soap.wsdl_cache_ttl=0
Restarted Apache, and finally my script stopped failing.
I have since re-enabled my cache ttl and enabled flags, as reading the WSDL every time is a resource hog that doesn't need to be in place.
The Lesson Learned
The lesson learned by all today is be aware of your caching, and be aware of the changes you make to your live/production systems.
PHP and Josso – Transparency Rocks!
Bogdan recently asked in my comments:
I can't seem to find a call like josso_authenticate($name, $pass), returning an array to be appended to user's SESSION. I was expecting such a method, because SOAP is already used everywhere, so it shouldn't be too hard implementing this.
Has anyone had success implementing this kind of "transparent" login?
JOSSO simply doesn't make it easy to log people in with a single call. Instead you need to make an interface to the API to do so. I just so happen to have an example of such a wrapper function.
Let’s Get Open!
Being that it is Monday and I am really not feeling it today I thought I would dig up what is happening around the nets and share with you.
Chrome OS Zero
Looks like Hexxeh has been hard at work getting a cleaned up version of Chrome OS called Chrome OS Zero out to the masses. Reading through the Wiki and FAQ things look pretty nice and clean. I may take a stab at playing with this in the next week or so. Thanks Hexxeh!
Droids
Tim at CTRL-ALT-DEL Comic has this silly for us today:
Thanks Tim!
Nexus One
We all know about Google's latest move in the Android field by now, right? Well it looks like the Nexus One is selling well, and people are having problems with the 3G service that T-mobile is offering on the Nexus One. Being a T-mobile customer myself I can tell you the problems are not limited to the Nexus One. My phone refused to stay on 3G this weekend too, oh well.
PHP
References
Johannes Schluter discusses how references in PHP work, and suggests that maybe we should not use them anymore.
Last year I spoke at eight conferences and attended a few more multiple times at most of them I found myself in discussions about references and PHP as many users seem to have wrong understandings about them. Before going to deep into the subject let's start with a quick reminder what references are and clear some confusion about objects which are "passed by reference."
Patterns
Giorgio Sironi has two new blog posts about patterns in PHP. The first is on Abstract Factory patterns:
The major problem that creational patterns try to solve is that objects need collaborators: we often pass them in the constructor of a Client class to aid decoupling, as every class should know only what it really needs to get its job done. With the verb know I mean that they just know that the other part exist at all.
The second is on Builder patterns:
The Builder pattern's intent is to encapsulate the details (the new operators and other wiring) of the object creation process under a common interface. Though, the Builder can actually change the internal representation of an object, as it is not a black box.
Both blog posts were great reads, and I suggest all my UPHPU buddies hit them up.
Pro PHP: Patterns, Frameworks, Testing and More
Pro PHP: Patterns, Frameworks, Testing and More
Kevin McArthur is a self-taught entreperneur and opensource developer from Edmonton Alberta. Kevin has been running a very successful PHP application development studio for over 7 years. Additionally Kevin took time to write Pro PHP: Patterns, Frameworks, Testing and More, published by Apress.
The book really lives up to the name. It disucsses in great details the framworks that are most popular including Zend Framework. Kevin has what seems an infinite amount of knowledge on Zend Framework, and a quick Google search will reveal he is quite active is sharing that information.
I was a little let down on the Testing and Code Control sections of the book. I felt like Kevin mearly skimmed, and could have really dug into more detail, espeically about testing.
In talking about patterns for PHP Kevin reinforces some of the basics of good programming, and explains the pros and cons of each style of framework. You can tell he has spent his fair share of time in each of the patterns discussed.
Overall if you are thinking about playing with patterns and frameworks this is the book for you. Don't look for any golden knowledge about testing, but the rest is gold!
Book Review: RESTful PHP (Packt Publishing)
This weekend I had the opportunity to read RESTful PHP, by Samisa Abeysinghe, published by Packt Publishing. The book is short, about 200 pages, but full of great information about what REST is, how it is used, how it is supposed to be used and how to use it with PHP.
The book assumes you have a working knowledge of PHP, and how to install extensions (or use existing ones). The concepts are clear and concise. Samisa is direct, but explains the reasons for why code is the way it is, or explains what can be done different.
The books runs through many examples using Yahoo! and Amazon APIs. Most of the book could be called a manual for use of CURL and SimpleXML, as well as some DOM work. Although you will not need to know any of those things before picking up this book.
In a short seven chapters Samisa explains what rest is, who uses it, why it is used, and what you can do with it. Samisa walks you through consuming (or using) REST APIs and also how to setup your own APIs using the REST style and architecture.
I would recommend this book to any beginning and middle tiers PHP developer as it is a quick reference to REST and APIs that you know you already want to be working with.
Josso & PHP
I recently had the pleasure, if you would like to call it that, to implement JOSSO with PHP at my work. I quickly learned a few things about the process of setting up Josso with PHP, that aren't well documented, and as such I am going to share my findings.
Downloading
Let's start with downloading the PHP library for Josso. Most people will head straight to the SF.net repository for Josso and look for the PHP link. Well, let me save you the headache, it ain't there. The PHP library is stored inside of the josso main package (currently josso-1.7.zip as of this writing). The main package by-the-way is 80+ MB. You are looking for roughly 30Kb of files inside that zip.
Inside the zip you will find tons of files, and folders . Let me guide you to where the PHP files are: (after unzipping)
\josso-1.7\josso\core\src\plugins\php\php
No, the double php is not a typo. Inside of that directory you will find three class files, a config file, a couple of login/logout views, the security check, and the josso file. Be forewarned there is also a nusoap directory, and this thing will cause some headache if you are not prepared.
Installation
Unless you have full control of your server that you are installing the JOSSO + PHP interface on, you will not have access to add Josso to the php.ini file to make is autoload on every single page. For this I really suggest using a MVC with Front Controller setup. This allows you to force the user through a single point to access any part of your site, and thus eliminates the need to make Josso autoload for every single php file on your site.
SOAP
Finally I want to talk about Josso's implementation of SOAP. On their PHP site they write:
In case of using PHP5 be sure of disabling the native SOAP support in order to avoid conflicts with the SOAP API used by JOSSO.
That is 100% completely not needed. Here is why. The SOAP class they do use doesn't touch the SOAP class from PHP, and as such it can simply have all references changed. I simply loaded all the files from Josso into Eclipse and did a find and replace on soapclient (the actual class that conflicts) and renamed it to josso_soapclient. There were only a handful of places to change this, maybe 10. Once they were renamed the Josso + PHP experience was quite simple.
Example Scripts
Lastly I want to quickly mention that when you load the sample scripts provided by Josso, you will get errors. Apparently some of the methods have changed since they wrote the Josso examples. I have submitted my changes to the Josso project, and I hope that they will be included as they only make sense. So if you get errors, just go into the code and look to see if 1) the method exists anywhere, and 2) find a similar method and call it.
Conclusion
I don't want to sound as though I am bagging on Josso at all, instead I am just letting people know the problems I had, and how I fixed them. The rest of the setup was really quite simple. For Single Sign-on, Josso is great.
Update
So another small annoyance I found while using Josso was that when you send a bad login to Josso, Josso will hijack your user experience. I was passing the "josso_back_to" string, and I couldn't think why it wouldn't send the user back. It turns out that Josso only uses the "josso_back_to" string when there is a valid login, and a second parameter of "josso_on_error" is required for bad logins (or errors).
