Hi, I'm Todd. Welcome to Leveraging Soap Technologies on OS X.

Over the past couple of years, we've seen a growing collection of popular web applications providing you, the application developer, a lot of their functionality through what is called web services. Very popular web applications such as Google Maps, YouTube, Amazon web services, Face Book etcetera.

And these web services are very often provided through web service architectural styles two that are particularly popular, Soap and Rest. So today we're going to talk about the tools available to you on OS X to access remote Rest and Soap based web services. So looking at the agenda, first we're going to focus on Soap and the tools available to you for Soap. So first we're going to survey the tools available for Soap programming on OS X. And then we'll go in depth with Apple's native web services tool kit, web services core.

When we look at web services core, first we'll focus on code generation from WSDL files and the features and functionalities web services core offers there. And then we'll look at using the web services core API directly in your client application. Second style of web services we'll look at accessing from your applications are Rest phone web services and we'll take a close look at using NSXML, Apple's native XML programming tool kit for accessing Rest services.

So just briefly, let's catch up and make sure we know what we're talking about when we say what is Soap. Soap is a W3C specification and I found this definition of Soap on the W3C website in the Soap 1 point 2 specification and I find it kind of long and involved and not very helpful. So actually I kinda prefer the definition I found on Wikipedia for Soap.

And Wikipedia says Soap is a protocol for exchanging XML based messages over computer networks normally using HTTP. I think that's a pretty good definition. Soap originally invented by Microsoft and others as the successor to earlier RPC technologies like XML Air PC. It's another approach to the age old problem of inter process communication, the idea being that if one program written in one programming language and another program written in another programming language need to communicate. One possible way to do this is to pass XML messages back and forth. The idea being that most programming environments have solid XML tools, so that's one way to communicate between the two programs.

This probably sounds a lot like XML RPC and it is. Soap is very similar to XML RPC but the innovation of Soap is meant to add is object orientation where the primaries that you pass and return from the remote service could be native object types rather than just scaler values which we usually use in XML RPC.

Another technology that's often associated with Soap based web services is a technology called WSDL, W S D L, stands for web services description language. This is an XML vocabulary used to describe the interface and features of web services. And in practice it's almost always used to describe soap based web services. So this kind of a XML format that's meant to be machine readable so that automated processes can come and discover features of your Soap based web service.

So again, it's a service interface description language. So Soap is kind of the centerpiece of a large and ever growing collection of web service specifications from the W3C and these all kind of start with the abbreviation WS for web services. Kind of collectively referred to as WS star.

There's been some negative press recently from some developer camps targeted towards the WS star specifications, leading them to maybe even refer to it as WS death star. The implication being that these specifications might be a little bit overly complex or convoluted. But the point remains that certain Soap services do exist out there and there are times when you need to interact with them. So the good news is that on OS X there are tools available for you to do that.

So today we're going to look at those tools. I think it bears mentioning, Soap was kind of originally invented as an RPC mechanism. More recently there's been kind of an attempt to generalize Soap to a more general XML message passing system. But I think you'll find in practice, Soap is probably most often used as an RPC mechanism.

And the tools we'll look at today generally model it as an RPC mechanism. So I'm going to just kinda refer to Soap as an RPC messaging mechanism today. So let's look at a little diagram of kind of a common Soap interaction just to get us up to speed.

We've got a client application and a server application. And the client's going to send what is logically a method call to the server. And this is represented by an HTTP post request that contains and XML document as its body. This XML document is specifically a Soap XML envelop. And the return value from the server to the client in HTTP response again containing an XML document as its body.

Just a quick look at a standard XML or a standard Soap HTTP request. You've got all the normal aspect of an HTTP request that you'd expect. Headers up top and then in the body again, a Soap envelopee XML document, outer most element being the envelop element containing the normal name space declarations you'd expect.

Also an optional header, header element which can contain XML content for the server to use at it chooses and then the required body element which contains the actual method call we're calling, in this case a method called do spelling suggestion. And any parameters or arguments we're sending to the server, in this case a single strand value. Keep in mind that conceptually what we're talking about is something similar to this pseudo code here. You've got a service, you're calling a method and passing a single named parameter.

And so, conceptually one of the kind of rubs on Soap has been in the past that this is the same representation of what we just looked at, the pseudo code and it's kind of robust and its kind of a large XML document that tends to be a little bit, well robust. So that's one of the kind of the rubs on Soap.

And if you look at, just a quick look at the Soap HTTP response, again the normal aspects of an HTTP response you'd expect. The HTTP prolong and the body is an XML document with the outer most element is an envelope element. And there's a required body element that, that contains the return value. In this case a strain that's correctly spelled. So that was just a quick overview of Soap to make sure we're all up to speed. Let's go ahead and take a look at the tools available on Mac OS X for doing Soap programming from your client applications.

So we're going to take a look at two broad types of tools available on OS X. Third party tools and the built in tools available from Apple. So obviously Java is a cross platform environment that runs extremely well on OS X. Java has a large collection of very mature tools for web services programming and Soap programming in particular.

So the story here is that you have a lot of options in the Java world for web services programming tools. As far as integrating these tools into your Cocoa or Carbon client application, you may actually run into some problems because Java is in the Java programming language, your Cocoa application is probably written in Objective-C, crossing this language bridge could be difficult. So even though the tools in Java are very mature, you may have a hard time integrating this into your Cocoa, Cocoa or Carbon client application.

Mono is another tool set that contains a lot of Soap services or web service programming tools. Mono, you may be familiar, is an open source implementation of Microsoft dot net platform. Being an implementation of the dot net platform, it does contain a lot of web services tools, but it kinda runs into the same problem from our context of OS X programming that we saw with Java. It's going to be difficult to integrate with your Cocoa application, the native language of Mono being C Sharp, bridging from C Sharp to Objective-C can be difficult.

There actually is an open source tool available that looks really promising called Dumb Barton Bridge, which allows you to bridge Mono and C Sharp to Cocoa and Objective-C. I recommend you take a look at that. But again, it's probably not going to be the easiest choice for you if you want to access remote services from your client application.

Soap client is a third party free developer tool that we're going to take a look at in a minute, during one of the demos. This is a pretty helpful tool for debugging and testing your Soap services. It kind of creates basically a dynamic user interface for remote Soap services. Given a WSDL file. And it can be really helpful for testing and debugging, but that's about it. It's not something that, that you're going to be able to ship in the shipping application. Its not going to help you in your production code.

So as far as built in tools from Apple for Soap or web services programming, Apple script actually has very high level language integration for Soap and XML RPC programming. This can be an extremely easy and quick way to do fast and easy scripting of remote Soap services or XML RPC services. It's great for testing and debugging. But again, it's a little short on features if you need to get under the covers of your, something a little bit unusual with the remote service. It may not have all the features that you need.

Automator is a, another tool on the platform that has some Soap service or Soap programming tools that you might take a look at. Automator is a really great application they released in OS X Tiger, that's kind of a graphical programming environment where you can drag discrete actions into a scripting workflow and then execute the workflow. And automater actually includes an action for accessing remote Soap service. It's kind of similar to the user interface with saw with Soap client.

And it can be again a really great way to test or debug your remote Soap service or accessing a remote service. So it's great for fast and easy scripting. But it's kinda very similar to Apple script in that it's a little short on features if you need to do something unusual or you're having problems with the remote service, you may not be able to get the job done with just this tool. And then finally we've got web services core.

So what is web services core? WebServices Core is Apple's native XML RPC and Soap tool kit. It's a C based tool kit. And it's based on a couple of other tool kits available on the platform. So at the lowest level we've got core foundation, which is Apple's general purpose programming environment based in C.

And so its got all the basic data types that you expect from a modern programming environment like strings and arrays and dictionaries and also some higher level objects and classes like dates or URLs. And on top of core foundation is another C based framework called CF Network. And the CF here stands for core foundation of course. And CF Network adds and HTTP 1 point 1 implementation on top of core foundation.

On top of CF Network is web services core. And again, this is Apple's native C based tool kit for XML RPC and Soap programming and it adds to those high level features on top of CF Network. So what can web services core do? WebServices Core is actually a great option for you to access remote XML RPC or Soap services from your Carbon or Cocoa client application for OS X. A couple of features that we'll look at today, you can do code generation from WSDL files for remote services. And also of course it has a lower level API that you can use directly in your client application to access the remote services.

So first let's take a look at code generation using web services core. WebServices Core includes a tool called WS Make Stubs. WS Make Stubs is the easiest way for you to interact with a remote known Soap based web services that's describe by a WSDL file. So if you have a remote Soap service and it has a WSDL file description, WS Make Stubs can help you auto generate code.

So again, it's the easiest way to interact with these services when you know they have WSDL and you know what they are. It's a command line interface. It's an executable, you access from the command line. And using WS Make Stubs actually produces stub interface code from the WSDL. WS Make Stubs can generate code in one of three languages, C++, Objective-C or Apple script. And the code generated by web services core, actually, I'm sorry. By WS Make Stubs actually uses the W, web services core API under the hood.

So WS Make Stubs again, a command line executable that located at slash developer slash tools slash WS Make Stubs. So we're going to do a quick demo of using WS Make Stubs to interact with the remote service. I just went online and looked for a free, simple Soap based service that was also described by a WSDL file and I found something called Random Quote. So again this is a real live Soap service that's available online. And it actually returns, oops. Not just yet, thanks.

So the service is called Random Quote and it's got a couple of methods and we're going to call one of these methods. One method is called get quote and it accepts a single parameter, Boolean parameter called inHTML. We're going to call that method. And this returns actually a quotation, not a stock quote, but a quotation from an individual. And it returns a dictionary with a couple of keys and values, author and the author name quote and the actual quote value. So demo slides please, or demo machine please.

So before we actually call the random quote web service, I mentioned Soap client dot app, which is a desktop debugging tool on OS X. Let's just go ahead and use that tool, just to kind of interact with the service before we actually call it. So here I'm launching Soap client dot app. And again, this is just a free debugging tool available on the platform.

And with the remote quote service, I said it was described by a WSDL file. Well I went ahead and found the WSDL file out on the web and downloaded it to my desktop here. I could just as easily point this to the actual WSDL file online, but I went ahead and downloaded it. So I'm going to click the browse button and I'm going to open the WSDL file in Soap client.

Try that again.

Okay I'm going to drag the WSDL file direct to the Soap client. So once we've got the WSDL file loaded into Soap client, I can click the parse button and it's going to dynamically create a user interface for the web service described by the WSDL file.

So as you can see here, I've got a user interface created dynamically for the web service and I choose one of the two methods, again there's methods and we're going to choose the get quote method. And notice that it conveniently filled out some of the values for us.

This way we don't have to fill out all the details of the Soap request, which is kind of a handy feature. And again there was a single parameter to that method and it's a user interface for entering the value there. And you get a little type hint here that it's actually a Boolean parameter. So I'm going to go ahead and say false, we don't want the return value in HTML format. We just want a dictionary.

So when I click the execute button, down on the button half of the user interface, you can actually see the raw XML messages sent to the server and actually back from the server to the client. So here we've got the raw XML that we sent. And this is again the Soap envelopeee.

We can see it as a pretty style. We can see the raw response as text, and we can see the pretty response. So let's just take a quick look at the pretty response. I mentioned that the response is a dictionary. And here's the raw XML representation of that dictionary with the key of author, with Will Rogers and the quote is the best doctor in the world is the veterinarian. He can't ask his patients what's the matter, he's just got to know. So there you have it. Anyway that's how you can use Soap client to kind of debug your remote Soap service.

So I do want to talk about using WS Make Stubs now to actually auto generate code for this random quote web service. So what I'm going to do is first take a look at the help information for WS Make Stubs. And I've got a little text clipping here. So again, WS Make Stubs is located at slash developer slash tools slash WS Make Stubs. I'm going to pass the help argument. And that's how you can get the documentation for WS Make Stubs.

And there's a few arguments, probably the most interesting is the Dash X argument. And that's how you can specify which of the languages you're going to generate code in. C++, Objective-C or Apple Script. And there's a couple other arguments for specifying where you want the output to go or where you want the WSDL to be fetched from, either a local file or remote URL. I'm just going to use a local file because I've got it here on my desktop.

So I've got another text clipping here for the actual command WS Make Stubs, I'm going to produce Objective-C Stub files for the WSDL file for my remote service. So I executed WS Make Stubs and it actually produced a pair of header and implementation files here on my desktop.

So these are files that you can actually link into an Xcode project to interact with a remote service. So I'm actually on Tiger here not on Leopard. All of the tools that I'm talking about today are available on Tiger and available to you now. So just approve that I'm going to do this on Tiger. I'm going to go to Xcode and incorporate this into, incorporate this into an Xcode project. So I'm going to do file new. And choose Cocoa application. Call this random quote app.

I'm going to drag the four files that were generated by WS Make Stubs into my project. Its going to ask me to confirm that I want to add them to the project and I'll do that. Just to show you how easy it is to use the code generated by WS Make Stubs, I'm going to actually go ahead and build this application. So I'm going to go to Interface Builder, very quickly drag out a text find which will display the result of calling the web service.

And a button to execute the web service. I hope you'll do something a little more inventive than what I'm doing here. But this will get the job done. Now I'm going to create a controller class for my application. So I'm going to choose the base class for my controller class which is going to be NS Object. I'm going to go up to classes and subclass NS Object. Create a class called my controller.

In my controller class, I'm going to add outlet to my controller. Call it text view. And this'll be a pointer to the NS Text view that I just dragged into the user interface. And I'm going to add a single action. I'm going to call the fetch quote. And this will interact with the web service. So now I'm going to link.

Oops. So I've got this new class, my controller, where I've added an outlet and I've added an action. I'm going to go ahead and instantiate my controller into the nib file. And now I'm going to link the outlet text field and I'm going to link the button to the action of my controller fetch quote. And finally I'm going to select the my controller class.

And we're going to create the files for my controller and send them over to the Xcode project. Its going to make me confirm that I want to actually send these files to this specific Xcode project, I'm going to confirm. So when I come back to my Xcode project, I see the code for the class I just created, my controller.

And I'm going to go to the implementation file for the controller class. I'm going to go ahead and import one of the headers the WS Make Stubs generated for me. And that file is called WS Stub dot H. If I go ahead and look in that header file, and again this is the file that was generated for me by WS Make Stubs, it creates a few ways that I can interact with this web service. A few of them synchronous, a few of them asynchronous. I'm going to choose the simplest which is just a synchronous way to interact with the web service.

And you can see it created a class for me called random quote service and it has a couple of methods corresponding to the methods available by the service. So I'm going to go ahead and use that in my action method. And if you're familiar with the other programming environments, this is kind of like an event handler for when someone clicks on the button in the user interface.

So I'm going to say ID result equals random quote service, oops, get quote. Wanna pass a single argument of no because I don't want an HTML response, I just want the dictionary response. And then I'm going to set my text view, the string of my text view, to a string description of the result of calling the remote web service.

So now I'm going to build my. And again what I'm actually doing here is probably not a best practice. I'm actually calling a synchronous remote web service and the main GUI thread. So I wouldn't recommend doing this in your actual application. but just to kind of demonstrate how easy it is to interact with the code that's generated by web serve, WS Make Stubs, I'm going to show how quick and easy it can be So hopefully you'll do something more interesting with the user interface and not be calling methods synchronously on the main GUI thread. But again, now I've clicked the button and here's the response from the web service.

And I've got my quotation. This one is from Rudyard Kipling? A woman's guess is much more accurate than a man's certainty. Anyway, that's, that's how you can auto generate code and use WS Make Stubs to save you a lot of time in accessing remote Soap based services from your client application. Back to slides please.

So we looked at auto generating of code using WS Make Stubs. Now let's just take a quick look at the web services core API in case you needed to do something a little more specific or a little more dynamic from your client application. Remember that conceptually what we're going to be talking about here is basically calling method of a remote service. In this case we're going to call a method call do spelling suggestion, passing a single parameter with a key, a phrase and a value of the string that's misspelled.

Let's go ahead and just look at a diagram here of what the interaction is going to be like with the web services core. We're going to first create an object that represents our Soap request. And this is actually a very central data type to web services core called WS Method Invocation Ref.

And this will represent either a Soap or an XML RPC request. In this case, a Soap request. We're going to set the parameters of the request and set a few extra properties on the request. Then we're going to send the Soap request to the remote server. The server is going to return a Soap response.

We'll check for HTTP authorization challenges and if we have any of those we'll add credentials and rise and repeat. Finally we want to check for a Soap fault. And then we can use the, the information in our client application that the Soap service returned. So let's just walk through that quickly.

Again, the first step is to create the object that's going to represent your Soap request, WS method invocation ref is the name of that data type. And you can create one of those items using the function WS Method invocation create. This function takes three argument, the end point URI of the service, oops.

The actual string method name of the method you are calling. And the third parameter is the protocol. This is where you specify or XML RPC. In our case we'd be specifying Soap. Then you want to actually set the parameters on the Soap request and these are the arguments to the method you're calling. The parameters are represented by a dictionary because in Soap we have a name value pair representation of arguments.

So we might set these with something like the code below where we have a, a key, a phrase and value of a string that's misspelled. And again that's a dictionary. And then you set these parameters on the request using WS method invocation set parameters. So the first argument is the Soap request. And then the dictionary of parameters.

And then finally you can specify the order of the parameters because some Soap and XML RPC services require parameters to be in a specific order. You can use this stirred array argument to specify the names in the order that you want to send them. Next its time to set extra properties on the request.

WebServices Core represents some aspects of Soap and XML RPC requests as these, this concept of extra properties. And the properties come in basically four categories, Soap, HTTP, debugging properties and then there's a few miscellaneous properties. But you set these with the WS method invocation set property function. This takes three arguments, the request itself, a key and there's several constants to defining web services core for all of the properties that you might want to set. And a value.

Just to look very briefly at some of the properties that are available, in the Soap category they follow of naming convention of K WS, WS for web services, Soap. And then the actual property that you're setting. Method names base URI is one you will often have to use for Soap.

And there others including encoding styles and other features of Soap that you often deal with when dealing with Soap services. There's HTTP properties. Again, following the convention of K WS HTTP extra headers, this is how you can actually add a Soap action header to your request. It's often necessary and also some other HTTP information like proxy information.

There's actually four keys for debugging that can be extremely useful. These follow the same convention, KWS debug. Then you have outgoing body, outgoing headers, incoming body and incoming headers. If you set any, all of these properties to true, you'll actually see the raw XML messages being sent back and forth in the result dictionary, this return from the server. So this can actually be extremely helpful for debugging.

I recommend always setting these to true when you're first starting out using web services core to access a new service. So you can see the raw XML messages being sent and debug. And there's some other miscellaneous properties we won't go into. You can check those out in the API.

So now its time to send the Soap message. WebServices Core supports both synchronous and asynchronous messaging. For synchronous messaging, there's WS method invocation invoke function and this actually returns the result dictionary directly synchronously. Or if you want to send an asynchronous message, you can set a call back with a function of a defined signature And then schedule the execution in the next run loop.

So we've sent the Soap request to the Soap server and the server should return a result. And the result is going to be modeled as a dictionary. And the dictionary will contain all of the information including the result value as well as debugging information if you ask for debugging information.

First thing you should do is check for a Soap fault. Soap faults are something defined by the Soap specification that's an application level fault that the server may send back to you. So you want to check for that as soon as you get the result. If you did get a Soap fault, there's a couple of keys that you could access inside the result dictionary to get Soap fault information.

So assuming that you've gotten passed the fault stage, you can now retrieve the result object from the response from the server. So to get those result object out of the response dictionary, there's a specific key, WS method invocation result. And you can fetch the result out of the dictionary using that key. So now at this point we've done the entire interaction of the Soap request and response. And you can use the response data in your application however you choose. So that was web services core.

Increasingly, we're seeing adoption of a new style or a new architecture for web services rather than Soap or XML RPC that kinda follow an RPC mechanism. There is a growing collection of web services that are using something called Rest. So what is Rest? Just to describe briefly what we're going to talk about today when we mean, when we say Rest, there was an individual, a very smart guy named Roy Fielding who is one of the cofounders of the Apache Foundation. And also involved in the IHEF working groups for several very important specifications for web technologies such as URI, HTTP, and HTML. So obviously, Roy Fielding, very smart guy, involved in a lot of important projects.

In the year 2000 he wrote a PhD dissertation where he coined the term Rest. I think it's probably fair to say that about the time around 2000, Soap and XML RPC were beginning to gain popularity as ways to develop web services. It's probably fair to say that Roy Fielding was not a huge fan of this architectural style for web services.

And he was kind of looking at these design ideas coming from Soap and XML RPC and saying, actually I think maybe there's simpler way to design web services that also is working today in scales extremely well. And I see these services all around me and it's called the World Wide Web.

So he coined the term Rest as kind of a means of codifying the characteristics of the web which made the web useful. So again, in this 2000 PhD dissertation, he kind of went on to say, what makes the web work so well? What about the architecture of the web is so great that makes it do all these things that we enjoy every day? And so he did coin this term called Rest.

And Rest stands for representational state transfer. Rest is not a standard. It's actually an architectural style of network systems. But it is however built on top of several other standards such as URL, HTTP, XML, HTML, PING and others. And an important point is the World Wide Web itself is a massive restful system.

So what is a restful web service? Just the, the actual basics of what a restful web services is actually quite simple. And probably sound very familiar to you if you're used to the web, which of course you are. So a restful web service is just a collection of resources and all these resources are addressable by URL.

This is important for book marking. You can always book mark a resource just by book marking its URL. And these resources are accessible by a small set of HTTP verbs such at get, put, post and delete. Using a HTTP verb like get just accesses a resource. Using a HTTP verb such as post will create a resource, delete deletes a resource, put updates etcetera.

So the resources returned by a restful, restful web service could be anything but, but in practice and in the web services we're going to talk about today, you'll often find that either HTML or XML mark up is returned as a resource from a restful web service. So as kind of an example of the popular restful web service that's available today that you can use, Amazon has several services for which it has a rest based, rest style interface. And here we have a URL to specific resource available by the Amazon web service.

And this URL is actually asking for books, items from the category books who might be associated with the title Harry Potter. So if we were to use this resource or if we to use this URL to access resources from Amazon, we might receive this XML resource that includes a list of books available for sale on Amazon associated with the title Harry Potter.

So again, just a quick diagram of the interaction we're talking about here. We have a client, we have a server. The client is going to send an HTTP get request with the specific URL to the server. And the server's going to return an XML representation of the resource that was requested.

So accessing a rest service from a Cocoa app. There's actually a few different ways you could do this. But one really simple way you could do it we'll talk about here in this diagram. First obviously you want to build the URL for the resource that you want to access. So in Cocoa URLs are represented by a class called NS URL, so you can build this URL first.

Then in a minute we're going to talk about a tool kit called NSXML. So we'll go into the details in a minute. But there's actually a class called NSXML document, which has a method called contents of URL. Which is a really easy way to grab an object representation of a remote XML resource, given a URL.

So a very high level, convenient way to access this remote resource. At that point, you've got your object representation of the remote XML resource. And you can use any kind of XML programming tools that you've got at your disposal to interact with this data return from the server. Tools such as Xray, XSLT, DOM or others.

So we've been talking a lot about XML especially in connection with Rest based web services. So you're going to need an XML programming tool in your Cocoa application to interact with this and program these XML responses returned from the server. We actually have a fantastic tool kit available to you in Cocoa called NSXML.

So NSXML is our native Cocoa API for XML programming on OS X. NSXML is a tree API for XML programming, very similar to what you might be familiar with, with DOM if you're familiar with Java Script or Java programming. So it's a tree API that represents an XML document as a hierarchy of nodes, very similar to DOM.

However it's based roughly on the X Query data model. X Query data model is very similar to DOM except that it adds a few extra items to its model that DOM doesn't include. So whereas DOM represents an XML document as a collection of nodes, X Query data model also represents XML document as a collection of nodes.

But X Query data model includes a couple of other items such as atomic values in its data model and also sequences. So atomic values could be anything like strings or numbers or dates. And sequences are ordered items, sorry, ordered collections of items. So again the X Query data model not only models XML documents as nodes but also includes atomic values and sequences.

NSXML is based roughly on this model. NSXML also includes an implementation of X Path 2 point 0 and X Query. If you're not familiar with these, these are really fantastic tools to have available on your platform for doing XML programming. X Path could be thought of maybe as a, kind of a regular expression syntax specific to XML.

It's a non XML syntax that allows you to address and extract very specific parts of an XML document at a very high level and very conveniently. And X Query is kind of like Sequel for XML. Obviously it's a query language specifically built for XML. And it's a super set of X Path 2 point 0. NSXML also supports XSLT transformations.

And NSXML also supports validation against a DTD. A couple other features like X include for including a remote XML fragments into a main XML document as you parse it. And also tidying for fixing up well form NS errors in an XML document as you parse it initially. You can use NSXML to create an object representation of an XML file on disk, either locally or remotely.

You can also use NSXML to programmatically create an XML document. It's layered on a couple of open source technologies that are available on OS X platform, specifically lib XML 2 which provides the parsing abilities. Lib XSLT which provides the XSLT capabilities. And tidy which of course provides the tidying abilities for fixing well form NS errors.

Another interesting feature of NSXML that maybe a lot of people don't know about is it does all the methods in NSXML or excuse me, all of the attributes of the NSXML objects support key value observing and key value coding, so it also supports Cocoa bindings. This is a way to very easily bind the elements and attributes of an XML document directly to a Cocoa user interface without a lot of controller code, shuttling data back and forth. So just a quick look at a couple of the important classes from the NSXML API.

Very much like DOM, NSXML has a base node class that is the base class from which other types of nodes descend. And in DOM you have the base node class. In NSXML you have base NSXML node class. And then there's a couple of specific important classes that descend from that. Specifically NSXML document represent the document as a whole. And NSXML element which represents XML element nodes.

Just to go over a couple of the interesting features of NSXML features that I mentioned before, it does include a really great high level way for accessing remote XML documents. So there's an instance method of the NSXML document class that's called Init with Contents of URL. If you're not familiar with Cocoa, Init methods are kind of very similar to constructor methods in some other languages. So this actually is kind of like constructor method that will return an NSXML document representation of a remote XML resource. So it's a really great, convenient high level way to get an object representation of a remote XML document.

So with the Init of content, Init with contents of URL method of NSXML document, you retrieve an NSXML document representation of a remote resource given the URL. And I mentioned there were a couple of other features of NSXML such as tidying and validation. And this is actually the gateway to some of those features right here. There's a second argument to this method called options where you can order together a few options that allow you to validate or X Include or tidy your document as its parsed initially.

So I mentioned the NSXML supports X Query. There's a couple of methods that support this functionality. But one important one is this, the instance method on NSXML node called objects by applying X Query. With this method you can retrieve a sequence of items. And the context of your X Query will be the actual node that you call this method on. And you can pass a string that contains an X Query and that of course will return the sequence of items that match the X Query.

I also mentioned that XSLT is supported by NSXML. There's an instance method of the NSXML document class called object by applying XSLT. So again, you can pass an XSLT string or an XSLT data object to this method. And what will be returned is the result of the XSLT transformation.

XSLT itself can return a new XML document or even strings or other objects. So this is kind of generically typed as ID rather than a document. And I just want to do a quick demo of a Cocoa app that I threw together that uses NSXML to access a remote rest style web service.

Gonna quit Xcode. So I created this little application called YouTube Pal. And as I mentioned before YouTube has a rest interface for its web services that allow you to search its videos by tags. So as users upload videos to YouTube, they tag them with different items, with different strings to represent what they're about.

So this is just a very simple Cocoa app that using NSXML and also uses web kit. If you're not familiar with web kit, web kit is our web rendering engine on the platform. You've probably heard a ton about it this week. Obviously its, it powers to Safari web browser So I've embedded web kit in this application.

And I'm going to use NSXML to make a request to the rest interface of YouTube and then I'm going to use NSXML to apply an XSLT transformation on the XML response that I get from YouTube. So I'm going to go directly from XML response from the web service to HTML interface.

So there's no objects in between. This is kind of a really convenient way to access, to access remote web services and, and interact with them. Because there's no converting to objects and then back to mark. There's just no mark up objects, mark up. I just go straight from XML mark up directly to HTML user interface using XSLT.

So the way this application will work is, I can type in a tag that I want to search for. So if I want to search for say iPhone videos on YouTube, when I click enter, it's going to send the request to the YouTube rest interface, transform the result into an HTML user interface and display it on the UI.

And so here it is. I've got a list of just a few, I'm limiting the results to like 20 or 22 or so mething. Of course there's a lot more videos on YouTube than this. And then when I click an item, its actually using an HTML embed tag over here on the left and I can watch videos about the iPhone. I don't think I have audio hooked up, but that's okay.

Might remember this video was the Conan O'Brien play on the iPhone functionality which was pretty funny. But anyway, this application. ( Laughter ) Side burns. Just a really simple example of how you can use NSXML to interact with the remote rest style web service. It's a cheese grater.

Anyway. Back to slides please.

so that was NSXML and it's a really fantastic tool for accessing remote rest style web services or just doing general XML programming on OS X. Very helpful tool, a lot of great features, X Query, X Path 2 point 0. So I just kinda want to summarize the things we talked about here today.

WebServices Core is our native C based tool kit for doing XML RPC and Soap based programming from your Cocoa or Carbon client application. If you need to interact with an XML RPC service, I highly recommend trying web services core. It's very solid for that. As far as Soap programming, Soap is kind of notorious for in or out problems where a lot of times Java tools won't interact well with dot not tools and etcetera. And so you're probably going to run into some in or out problems. But I would recommend trying web services core for Soap programming as well. And then for accessing remote rest style web services, NSXML is a fantastic tool available on our platform for doing that.

For more information we have an NSXML programming guide and also a programming guide for web services core online. And we have a new article that we just did a, a short while again about adding HTTP authentication to your use of web services core. So if you need to access a remote based web, a remote web service that's behind HTTP basic or digest authentication. And we've got an article up on that.