SOAP is obviously the big one. I use the PHP 5 ext/soap extension, which is great, but there’s actually another PHP SOAP extension that might be even better. No, it’s not PEAR::SOAP or NuSOAP; it’s axis2.

If you haven’t heard of axis2, you’re not alone. That’s because it’s a pecl extension that’s still in beta, so there aren’t a lot of people using it yet. However, it’s a PHP version of the Apache Axis 2.0 SOAP stack.

Unlike ext/soap, which is recreating SOAP one feature at a time, Axis 2.0 already supports a good portion of the WS-* specifications. So all that needs to happen is for someone to write the hooks between PHP and Axis 2.0, which is far easier than actually writing the features themselves.

I met a number of people from WSO2, the company that’s writing Axis 2.0, and they’re quite excited about the extension. However, they did mention it’s still in beta, so I haven’t actually spent any time using it yet.

The other PHP XML extension I’ve been hearing a lot about is SDO. SDO is an attempt to provide a standard data interface regardless of the backend datasource. So, for example, you can interact with XML data in the exact same manner as information pulled from your database.

At OSCON and ApacheCon, I’ve run into a couple of people from IBM who have been doing the heavy lifting on this extension, and we’ve had a number of interesting chats with them about eBay Web services and SDO, but I hadn’t had any free time at work to install the extension.

Therefore, when I had a little free time today between the end of my session and lunch, I sat down and reproduced a short code example that I had wrote using ext/soap with SDO instead.

Here’s the key portion of the original code:

// Print Titles and Mileage
if (isset($response->SearchResultItemArray)) {
    foreach($response->SearchResultItemArray as $item) {
        printf("%s\n\t%d miles\n", $item, $item->ItemSpecific['Mileage']);
    }
}

This iterates through a search result for eBay Motors listings and prints out the title and the mileage for each individual item.

Normally the code would be far more complex, but through a series of ext/soap class mappings I wrote that implement the IteratorAggregate and ArrayAccess interfaces, along with the __toString() magic method, I’ve managed to abstract away a number of the complexities.

Best I can tell, SDO doesn’t give me quite the same level of control, but it does implement a number of these features for me out-of-the-box.

Here’s my rewrite using SDO:

foreach ($root->SearchResultItemArray->SearchResultItem as $item) {
    $title = $item->Item->Title;
    $mileage = $item->ItemSpecific["NameValueList[Name='Mileage']"]->Value[0];
    printf("%s\n\t%d miles\n", $title, $mileage);
}

It’s not quite as brief, but I do get this nice XPath-like filtering that lets me pull out the the value of the car’s Mileage in one line. Pretty handy.

I had to implement the ArrayAccess interface to get this to work under ext/soap, which included this method:

public function offsetGet($name) {
	if (! is_array($this->NameValueList)) {
		$this->NameValueList = array($this->NameValueList);
	}

	foreach ($this->NameValueList as $NameValueList) {
		if ($NameValueList->Name == $name) {
			return $NameValueList->Value;
		}
	}

	return null;
}

Not the hardest thing in the world to write, but this is just one of the custom class maps that will arise in our data schema, and SDO takes care of them all automatically.

Still, right now I think I prefer my ability the greater control I have over the interface with ext/soap. Our SOAP schema isn’t that pretty since there are lots of list, array, and hash wrappers. Through classmaps and interfaces I can turn these into native-looking PHP arrays and hashes.

I may be introducing a leaky abstraction, but I think this is better than exposing a NameValueListArrayType for people to wrangle with.

Like ext/soap, SDO requires you to define your data using an XML Schema. While we actually publish a stand alone XML Schema file, SDO will also happily parse a WSDL file, too, which is nice.

However, it will not directly consume a SOAP message because the WSDL doesn’t include any mention of the SOAP envelope wrapper. I needed to rip out the contents of the SOAP body into a separate XML document in order to get SDO to parse my data. Oddly, this corresponds perfectly with our “XML API,” so I could use that to retrieve properly formatted data that I can pass directly to SDO.

Where SDO really falls down for me is performance. Admittedly, eBay is a pathological case, but our WSDL file is 2.94 Megs in size. When I feed that to SDO, it takes 8.5 seconds to process the XML Schema data. Yikes!

I don’t mind a one-time start up hit, but it doesn’t appear that SDO can cache a parsed version of the schema. In contrast, ext/soap has both an on-disk and in-memory WSDL cache.

This means it takes SDO about 8.7 seconds to process the schema, load in data, and print out the information — and all with locally stored files.

In contrast, ext/soap takes as little as 0.55 seconds to pull in a cached version of the WSDL from the disk, go out over the network to query eBay via SOAP, wait for eBay’s SOAP server to run a database query on its end and send back a SOAP response, parse the SOAP envelope, and print out the exact same data. If I was using the in-memory cache, I think it’d be even faster, and I’m sure the big bottleneck here is talking to eBay.

Now, I’ve spent all of 60 minutes playing with SDO, so it’s quite possible that I’m missing some obvious configuration flag. If not, I hope IBM can do something to help speed up the performance, since while I could probably write a script to break apart our schema to create individual files that contain all the possible types on a per-call basis, I am hoping I don’t need to.

In the meantime, I’m going to continue exploring SDO to see what else I can do with it because I’ve sure I’ve only grazed its surface.

[Update: I cannot get the axis2 extension to compile, despite trying a number of different versions of Axis2c and both Linux and Mac OS X. I may try again tomorrow.]

Given the following line of PHP:

$xml = DOMDocument::loadXML(
'<r xmlns="urn:a"/>');

The easy way to print the namespace URI of the root node, urn:a, is:

echo $xml->documentElement->namespaceURI;

But how do you retrieve it using DOMElement::GetAttributeNS()? What are the two magical input parameters to coax that value out?

As usual, I had a great time at the show. It was fun to see all my old friends and make new ones.

For this talk, I decided to demonstrate Web services using a number of real Web services, so you can get a flavor for how people are actually implementing Web 2.0. Specifically:

• del.icio.us (bought by Yahoo! earlier this week)
• flickr (bought by Yahoo! earlier this year)
• eBay (almost bought by Yahoo!, almost bought Yahoo!)

And, of course, there’s the obligatory Google Maps reference because, well, it’s a rule or something. I think. I can’t remember.

This was my first presentation done in Keynote. It’s certainly easier to make non-ugly slides in Keynote than in PowerPoint, which almost seems to lead you down the path of ugly slides. You think Microsoft could invest in a few good new templates instead of still using the ones their intern programmers designed in 1992.

If you’re going to be at ApacheCon, let me know. I am arriving Monday afternon and leaving Wednesday night, and staying at the conference hotel. I will have a rental car, so if you know a good place to eat or drink or visit that’s off the beaten path, we can help each other.

Since we rev our Web services API every two weeks, we run into versioning problems that aren’t well covered by existing practices. For example, we define a whole set of complexTypes, but those types can morph overtime and we want to maintain backwards compatibility whenever possible. Or, a piece of data may be mandatory in one call, but optional in another.

Seeking a standards-based solution, our documentation team turned to the appInfo element defined as part of XML Schema. It’s quite a nice idea, and also allows us to auto-generate reference documentation from the WSDL file itself. We’d love for other companies who encounter a similar problem to take a similar approach, so that we can pool resources.

If you’re interested, check out Alan’s piece.

• Microsoft PDC: September 13-16 in LA. I haven’t managed to wrangle a chance to speak yet. :)
• Zend/PHP Conference: October 18-21 in Silicon Valley. Speaking about eBay Web services. Final talk TBD.
• ApacheCon US 2005: December 10-14 in San Diego. Speaking on “Consuming Web Services Using PHP 5″.

I may also go to Web 2.0 and the 4D Summit, but I have yet to finalize those events.

The ApacheCon talk should be quite cool, as I will be showing off nifty real-world web services examples. For example, sucking del.icio.us RSS bookmarks into a WordPress blog, or mashing up eBay Web services search results with the Google mapping API. Here’s the full abstract:

As we move into the world of Web 2.0, PHP developers must increasing include Web services in their toolkit of skills. This session covers how to implement REST and SOAP clients using the latest PHP 5 extensions, such as ext/soap, SimpleXML, and xsl.

This is not an academic talk discussing theory and specifications. Examples show applications of popular Web services, including del.icio.us, eBay, and Google Maps.

Don’t be left behind. Come to this session and learn how to integrate Web services into your code.

I have most of the code already written in various places, so there’s only the problem of creating the slides. Once I know more about my other talks, I will pimp them here, so stay tuned for all the details.

Missing from his list is PHP/FI, which should clearly be filed under winners. People always made fun of the simplicity of PHP (no OO, no namespaces, no Unicode support, etc.) However, you can’t argue with the growth curve.

Tim also references Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked.” So, even though PHP 5 now has fullblown OO support, and we’re working on Unicode, (but still avoiding namespaces), we still keep ourselves rooted in Rasmus’s early principles of simplicity.

If we had tried to jump directly to PHP 5 back in the mid 90s, we never would have made it. We would have had our asses kicked by Perl, Java, or both.

The eBay Developers Program enables third party programmers to write applications that use the eBay platform. We have an amazing set of web services (over 100 API calls) and want everyone to use them. Not only do we expose almost all of eBay, we do it big time, serving up billions of API calls every month.

Your job would be getting the word out to new communities, getting them excited about the possibilities, and helping them build all sorts of cool applications. In my opinion our platform is particularly interesting because eBay is so dynamic — people are always listing, bidding, and buying. Our web service is more than just search results, and it’s read/write, not read-only.

The official job description has all the details. (That’s job “5731″ if the link breaks.) Also, apologies in advance to my fellow Mac and Linux users, our brain-dead job site only works under Windows IE. (It also works under Firefox on Windows, but that doesn’t extend to Firefox Mac or Linux. However, you may be able to spoof your user-agent string.) Please don’t read anything into this and apply it to my attitude towards developers.

Actually, this format has turned out to be quite practical. Its building blocks — HTTP, HTTP Headers, HTTP POST, SSL, and XML — are sufficiently well-implemented standards that we haven’t found any language that can’t make API calls. From our perspective, that’s the most important characteristic. That’s not saying that if we had known in 2001 what we know now, things wouldn’t have turned out different.

However, at least we got the GET vs POST decision right.

So I took a peek and was quite surprised by what I found. RSS.

I think this is brilliant. RSS is XML, so it’s easy to parse. It’s also easily consumable by RSS readers, so other people can piggy-back on the feed. Of course, it does mean you need to be willing to open this up to the world because it won’t take before this is figured this out and people start publicizing the interface.

Sure enough, there’s already a blog post describing how the widget works and it even provides a little form for making your own URL.

We’re finally beginning to see the adoption of Web services into client applications. One of the advantages of REST is that it’s super easy to consume from programs such as Dashboard and Firefox.

I can’t wait to see where this goes.