Our next session this afternoon is XML in WebObjects. I'd like to introduce Bob Frank, who's going to give the presentation for this session. Bob? Thank you, Toni. Hold on. There's the clicker. Good afternoon. Welcome to XML in WebObjects. Today we're going to cover a wide variety of materials so that you can get familiar with what is XML, how to use it in WebObjects, and why you should be using it. Han Ming is going to cover the basics of what XML is, what are the key concepts, and basically give you an overview if you're not familiar with it.

Also he'll discuss serialization of... using XML to read and write simple configuration files, which is a very common use of XML. Also we'll be discussing serialization of EOs. Slightly more sophisticated, but using the same approach as you use for reading and writing files is serializing EOs into XML and also using XSLT, which is XML-style transformations, which allow you to transform one XML document into another XML document.

Lastly, we'll be discussing a very popular way of using XML to communicate between servers, XML RPC. We'll discuss what it is, how to use it, and compare and contrast it with SOAP. You'll see the letter X so many times in this session that you'll probably be sick of it. And without further ado, Han Ming.

There you go. This button. Good afternoon. My name is Han-Ming Ong. I'm in the engineering team. And I'm going to give you a quick refresher on XML. I have 10 to 15 minutes, so I'm going to assume that you have done some XML work before. So I'm going to give you some definition, basic definitions of XML, followed by constraints, so that it can make sense out of XML data. There are two main specifications.

Sorry about that. Okay. So there are two main specifications for doing constraints. One is document type definition, DTD, and schema. So as Bob mentioned, with XML technology, there's a proliferation of acronyms. So my advice is don't worry too much about the letters, but try to understand the meaning behind them. Then I'll talk about processing of XML data, which means the producing and the consumption and the consuming of XML data using low-level APIs like DOM, DOM, SAX, and JXP.

Then I'm going to give you a list of parsers that one would use to parse and consume XML data. So what is XML? Essentially, XML is structured data that always has the same fixed, big, synthetic formation. It is always hierarchical and tree-like form, which means for developers like us, we worry a lot less about the how of extracting information out of it.

And because it is organized, so it is familiar for laymen to read as well. That's one of the goals of XML. The other great goal of XML is that it should be portable. And the reason why it is portable is because it encodes the data as text. A piece of text string is the same across different development platforms and languages.

and not only is it in text, it accepts Unicode characters. That means all the languages in the world can be written in XML. And it puts that encoding right at the top in the declaration so that most of the time you don't have to apply heuristics to try to understand it. The next slide I'm going to show you is a simple XML document so that you have a feel of it.

So the first line that you see is what we call the XML declaration. The version is 1.0. The W3C organization did a good job, so after two years or so, it's still 1.0. They may wrap it up soon to 1.1. The encoding that we see here is UTF-8, which is a good default encoding.

For your, you know, if you have just have English, you can, you can, you can don't put it down or you can put S-U-S-S key. That will make the parsing a lot faster. Here in this XML document, we see a root element called purchase order. The starting tag is a line 3. The ending tag is a line 10.

This root element has two char, comment and item. And here it has an attribute called order date. Attributes may or may not be required. When it's present, it usually means metadata. and to illustrate the fact that you can have Unicode character, I put in some Chinese character, which I'm sure all of you understand.

OK. This thing right here. I figured it out. Linking at me. Constraints. The above XML document that we just saw adheres to a concept called well-formedness that is defined by the basic XML 1.0 specifications. The basic rules say stuff like, you must have one and only one root element in an XML document, and every element must have an opening tag and an ending tag.

There are many exceptions to it. Validity is a contract of structure between the producer and the consumer of the XML data. The producer of the XML data would say stuff something like, expect to see the root element purchase order having a child element, two child elements, comment an item.

The contract of structure varies across domains and industry. So when one says that an XML document is valid, it is always with respect to a contract. And the structural contract is defined in two ways. More than two ways, but the two most common ways is using DTD, document depth definition, and schemas.

So document type definition. That's rooted way back in the SGML world. And so for some of us who have worked with XML, you may find the syntax a bit weird. But to some of the old timers out there, it's very natural. So you still have to publish your contract in DTD.

The two main deficiencies with DTD, unfortunately, is that it doesn't have a typing facility. and that it doesn't work naturally with namespace. Now, words in English, common words in English, are very important to some domains, and they are common. So you have to have namespace to avoid the name conflict, just like packages or namespace in C++. So in the next slide, I'm going to show you an example, a simple example of a DTD, part of it, that constrains the XML data that we saw earlier on. I don't want you to focus too much into it, but just, you know, you'll find it intuitive.

So what it says here is, you might find an element called purchase order, and it must have two child elements in sequence, comment, and item. And it must have an attribute called order date, and it must be a parsed data. So on and so forth. Schema. The same grand goals as DTD, except that there are three main differences. The first one is it's written in XML, which means for most of us who are familiar with XML, it's easy.

You can use your favorite XML editor, create your schema file, and have it validate across the schema schema. and solve two main problems, of course. Data typing. You can have the basic system types like string, integer, and so on and so forth, and even customize types, which means in schema files you can put in stricter permissible content, which can be validated. And it works very naturally with namespace. So in the next slide, I'm going to show you an example of a schema file that constrains the same XML data. Despite slightly more verbose, you will find it as intuitive.

I highlighted using colors to show you the sections I want to talk about. Red color is a prefix of a namespace. You can call the prefix anything. So in this case, the prefix is linked to a namespace. Namespace has a one-to-one relationship with the URI. In this case, our URI is an URL, www.apple.com/publications. So the prefix which I chose to use is Apple. If you focus on the gold color now, these are just the elements. We've seen that before. Purchase order must have two child in sequence, two children in sequence. The first child is comment. The second child is item.

and the green colors are the data types. I've mentioned before, string in this case is a basic data type. And it's great that, you know, that W3C actually studied quite a lot of languages to find some common system type, like string, integer, boolean. It's very similar to Java, so it's very easy for us to use. And you can customize the type as well, of course.

So at this point, I'd like to take a little pause, a little breather for me and for some of you out there to remind ourselves what XML is not really. So a contract of structure is just what it is. There's no semantics in it. It doesn't explain what purchase order is.

What that means is the producer of the XML data has to talk to the consumer of the XML data to explain to her what the XML elements are. What the producer of the XML data usually does is put the semantic explanation in the DTD or in the schema file.

So you still have to talk to achieve interoperability. The second thing is that a piece of XML data is just structured text data. You still have to find domains for end users for it. Some of the users that we have seen out there is storing XML configuration information.

And to do that, you have to find a way to store XML data. You do content publishing, meaning you store XML, your data is XML, then you apply transformation to get WML, HTML, or even binary formats like PDF. And of course, a lot of companies, including Apple WebObjects, is leveraging XML to build web services, whatever that means.

So we move on to processing of XML data. This set of low-level APIs is called Document Object Model. Document Object Model has been used, again, in the SGML world and way back to model any documents, not only XML. Those of you in the audience who have worked with HTML browsers must have seen DOM models of HTML before. So it is a very general tree structure. And for me, at least, and for some of you, most of you out there, you probably use it for producing XML data, serialize it out.

It is less useful parsing because it is pretty memory intensive. It builds the entire object tree and let you manipulate from then. There's another low-level API that allows you to do parsing, and most people like this simple API for XML. It is faster than DOM because it is very sequential. It starts at the very top, look at the first element, and it generates standard callbacks that you're supposed to implement and handle. It maintains very little state information and hence extremely lightweight, which is good for parsing.

Jack Spie, this is neither sex nor DOM, but it is an abstract layer that Sun provides for you to instantiate parsers and transformers so that you can easily plug in transformers and parsers from different vendors. I would advise you to start using it if you have not. This will make your code more portable, and you can choose parsers depending on their performance and functionality and speed.

So next slide will show you a list of parsers that you can choose. And if you have JaxP, you can plug and play. The Xerces parser, very popular. Sun's Crimson parser is going to be included in 1.4. and I.B.M. have their own parser. And just to illustrate that, you know, a lot of people write parsers as well, James Clark has a pretty reputable parser, which I think is fast.

Okay, I'm going to switch gear now and talk about the integration of XML technology with WebObjects. I'm finished with the refresher so the XML expert can wake up. So we're going to ship the Xerces 2 parser and the Xilin 2 transformer in the Java XML. Before, we used to, we planned, sorry, I have to say this. We planned to ship Xerces 2 and Xilin 2.

In the current WebObjects, we only have the Xerces 1 parser, but we have noticed that our developers started using the Xilin 2 transformer anyway. So we want to facilitate that. And synchronization of versions, as some of you out there might know, is very important. So we keep them synchronized.

That's support at the lower API level. At the slightly higher API level, we have two serialization schemes for WebObjects. The first one, as some of you may have used it, is OXML Coding Decoder, and we plan to support a new one called NSXML Input and Output Stream. So let's talk about them.

What is XML Coder and Decoder? We like to deprecate them, following the philosophy of deprecating, of aligning our serialization APIs with Java APIs. Now the analogy here is NS coding versus serializable. We used to have NS coding, which is a more objective C-way of doing binary serialization. We made the transition in WebObjects 5 to serializable.

So we'd like to follow that and deprecate all XML coder and decoder. Following that deprecation, we'll be saying goodbye to our mapping file, the non-standard mapping file that we use for transforming XML data, and say hello to XSLT. My colleague Mike Brumbelow, he will talk more about XSLT transformation later on.

Now, XSLT is an industry standard that became a recommendation by W3C about a year ago, I think. And it is good because knowledge is very portable. Once you learn XSLT, you can use that knowledge in Objective-C, in C++, or even in Microsoft, different platforms. If you're already an XSLT expert, you can apply the knowledge immediately.

So the new XML serialization scheme, for the most part, is going to be as easy as the binary serialization, because it follows the basic binary serialization rules. What that means is classes, they already implement serializable. You get, they become XML serializable for free. This is because the classes that does the serialization, an XML input stream and output stream, they are built on top of the respective I/O classes. Instead of instantiating object output stream, you instantiate object and XML output stream. You write out the object and vice versa for NSXML input stream.

So the WebObjects does the heavy lifting of figuring out what should be serialized. And as I said, they follow the basic serialization rules. What that means is non-transitive, non-static data members become serializable. And if you want to be fancier, you override the two methods, the write and read object, to customize them. They will be called. And by aligning our APIs with the Java industry standard, the serializable interface, we make our APIs more available to Java developers who are learning WebObjects and Java developers who are more familiar with the serializable interface.

So here is the default XML output of a serialized object. I want you to focus in the middle part, because the rest are just namespace and stuff. We have a serialized object, and this first child is a class structure, which most of us who are focusing on the content part of it can ignore. Those of you guys who want to know the class structure, it is there for you.

I'm going to skip to the content. It just says that this object has a field called first name, and it is of data type string, and the content is just Mike. Now, this, this is, this is, this is, this This XML content is actually deserializable to become a person object in memory if you use an XML input stream.

So here is an example of how to write out that particular object. You must have seen this before if you have used serialization, binary serialization, the last two lines at least. You instantiate an object, an NSXML output stream. You write out the object, and you close it. That's it. Now I want you to focus hard on the next slide because it's going to be really complicated for reading it in.

All right, that didn't go well. It went well during rehearsal. It's supposed to be a joke. So, again, you instantiate an NSXML input stream. You read the object in, the XML data in. You pass it to your class, and then you close it. That's it. Good. I'm doing pretty well on time. So I'm going to give you a demo now, demo two.

So On using the new serialization scheme to do configuration. Now one word about storing XML is configuration. Now as I said earlier on, because the basic structure of XML is always the same, so storing configuration data into XML is becoming more popular. You see it in Ant and almost everywhere, in Tomcat. This is because people worry a lot less about the extracting of it.

They worry more about what you're going to do with the data. Compare this with makefiles, where, you know, a tab is actually a very important delimiter. You miss that tab, your makefile won't compile. Or in the Apache configuration, where the new line is an important delimiter as well.

So here, I'm going to make use of an example that was shipped with WebObjects 5, so that you're familiar with it. It's create plot. Create plot is a very simple example that shows you how to make use of the plotting APIs to create graphs. And there are three kind of graphs.

One is based on floating point number. The other one is based on string. And the last one is based on date. We hard-coded the example when we shipped it so that it always started with the floating point example. I've already run it, and let me bring up Y.

So this is the example that started up when you first run it. And it just plots a graph of floating point. And you can illustrate there are three kind of graphs-- floating point, date, and string. So when the application started up, it writes out a configuration file, which I'm going to show you.

This is the XML configuration file. It is similar to the XML data that we saw earlier on. And I added a comment. I'll show you how to do it later on. It says, "Change its value to configure the starting plot." I'm going to change it to object. Save it. Create a new session.

So a new session comes in. And there you go. It is a new CACIA object. It is an object based on string. And let me change it again back to date. I have a new application. So we have a new plot based on date. So imagine an administrator who is just concerned about changing the configuration file and doesn't care about WebObjects application. She can go in and change the XML file, and the next time the session comes in, you have a new plot. So now I'm going to go to the code and walk you through it briefly.

I created a class called StudConfig and I made it serializable. And I'm following the rules of serialization, binary serialization. I created a variable, instance, a member variable called starting plot. Make sure it's non-transitive and non-static. And because I added-- I wanted to customize it by adding a comment, if you do want to add a comment, you don't have to customize-- override the WriteObject method. I have a couple of utility methods to help me create it. Those are, these are the stuff you saw earlier on.

Write an object and close it. And this is the creation of the class. And here, what I did was, I I customize it so that the session itself, on a per session basis, you can put this method in application and it becomes application-wide. And last, in the main.

So instead of hard coding it in main, I now get it from the session. That's it. So with that, I'm going to bring up Mike. He's going to talk about serialization of EOs using the new XML serialization scheme. And he's going to talk about transformation as well, XSLT, one of my favorite topics. Mike, please. Thank you.

Hopefully this isn't the demon clicker. Hi, my name is Mike Brumbelow, and today I'll be talking about EOXML serialization and XSLT. The good news about EO XML serialization is that it's easy as pie. You give us a collection of EOs, and we go through, and using NSXML output stream, we serialize it out for you.

And using NSXML input stream, we read that back in for you. Now, concerning managing your object graph, the good thing is that as a part of the serialization process, we don't fire off any faults. So the objects you give us are the objects you serialize out. We don't fault any objects in.

Let me demo this for you here. I wrote an application that takes an RSS document. An RSS stands for RDF Site Summary. An RDF stands for Resource Description Framework. It's a way of describing content information for a site. And a lot of news sites vend this kind of document out to the public, and you can use it to read news and information. And I wrote an application that goes out, pulls out this document, and we'll display it on the screen here. Where are you at? There you go. Now I'm going to launch it.

Okay, I'm going to select a site to look at. I'm going out and fetching the RSS document, and it's an XML document. Going through and displaying all the links, information associated with that site, the different news today. Let's see, is there anything here for us? No? Okay. Let's go to Wired. Is there anything here concerning us? Any news? The last one, where's that at? Hmm, let's look at that.

Interesting. So, you know, we can navigate and look at the different news articles and everything underneath there. So let's go back to cnetnews.com. Now, when I press this button at the bottom here, Save Articles, that's going to go out. It's going to fetch that XML RSS document. It's then going to save it out to the database, and then from there, it'll convert it into EOs and save it out to the database. And then from there, we're going to then serialize those EOs out to the file system. magically it happens. So let's go look at the document that gets generated here.

As you can see, wow, there's a lot of stuff there. Really, no data is serialized out. Basically, references to our data. And you can see in here, for instance, we've actually serialized out, let me highlight that for you, the editing context and some of the other EOs as well.

It's a nice little long document. Close that out. Now the next thing I'm going to do is navigate to the next page. From here, we're going to deserialize and bring all of those EOs back into the application and display the links again. It's just that fast. We'll click on an item. Voila.

And let's look a little bit of code here to see how simple it was. For serializing out, you pass us your objects, and then from there we go through and we get a hold of an NSXML output stream. We format it, and then from there we write out, and then from there flush and close the buffer, and we're all set to go. Of course, you know, there's some error handling there. That's a positive thing.

Then to deserialize and bring back the EO, you just go out and get a hold of your stream. Then from there, create an NSXML input stream, read it back in, and you're all set to go. So it's easy as pie, very simple, straightforward, to the point. Back to slides.

Next, I want to talk to you about XSL. XSL stands for Extensible Style Sheet Language. It has two rule-based vocabularies, that being XSLT, or Extensible Style Sheet Language Transformation, and the other one, XSLFO. That stands for Formatting Objects. Both of these vocabularies transform source XML documents, and both specify the formatting of XML documents.

Now, formatting objects is an XML vocabulary that defines page layout, pagination, the placement of images, text, that kind of thing, on a document, and then from there, it's converted to a binary format, like PDF and Word. And you can also maybe generate an SGV file or any kind of binary output that you want based on these objects.

And a really good place to go to get information concerning FO, XSLFO, is the Apache site. They have a formatting objects parser out there that you can download and use as a part of your application. It's very simple, straightforward, and to the point. But what we really want to focus on... is XSLT, which is the rules document of XSL. It enables us to extract data from a source XML document and then transform it into whatever format, XML, text, HTML that we want to.

Now, the XSLT vocabulary has many constructs, and the main one is the template matching functionality. And that enables you to look in your XML document, identify an element, tag, and then from there, work on that tag, the data that's inside of it as well, the content. It also has copying, control structures such as if-then-else, if-then-else-choose. It also has iteration, the ability to loop through. And it also gives you the ability to mainstay.

It also gives you the ability to maintain state by defining variables. Using XPath, which is an expression matching functionality as a part of XSLT, you're able to find data and then from there, work upon that data. And we'll kind of touch upon that in a small example coming up here in a few moments.

Now, the components that make up XSLT are the source valid XSL transformation document, the XALAN XSL transformation parser or processor, and a valid source XML document. And those three components work together to generate an output XML document. So you're basically going and you're converting an XML document to another XML document, or maybe converting an XML document to an HTML document, XHTML document, or even a text-formatted document.

Now here are some examples of the components that make up the transformation process. At the top, we have foo.xml, and this is a basic input document, very simple, straightforward. It's kind of like a Hello World kind of document. In the middle, there's our XSLT style sheet, and you can see there that there's a template element, and that's used to find the tag or the element and work upon it.

You see that one of the attributes is the name match, and that tells you what the name of the element is. And as a part of that, there's also the value of element, and that enables you to find the content inside of there. And at the bottom, there's the output that gets generated based on that. Now, some of the uses of XSLT are transforming XML to HTML, XHTML, WML, and you can also take a FO document, put it through your XSLT processor, and then from there generate a PDF document. There's any number of different text transformations that you can do as well.

Now, some of the two key processors in XSLT are Apache Xalan and Saxon, which is located at SourceForge. And here are some of the URLs that you can go to to get more information. Give you a moment to jot those down. Now let's look at the demo. And as a part of this demo, what I'm going to do is I'm going to take an XML document and convert it into an HTML document to show you how simple and easy it is to do transformations in WebObjects using our parser. Okay, so we bring up the application here, and let's fire it up.

Okay. So the first thing I'm going to do is I'm going to load in an XML document called And then I'm going to take an XSLT style sheet, load that in, and I'm going to enter the name of our destination document. And by pressing this button, I'm going to do the transformation.

and magically there it appears. Let's look at this real quickly, the document that we just generated. It's just straight HTML, very simple, straightforward and to the point. And if we look at the style sheet, A very basic style sheet that enables you to go through and transform the source XML document. And you can see the template here.

And it's looking for the tag product. And based on that, it's going to pull out the data where you see the description in. I'm sorry? We're not as close to your

So there's the XML document that we transformed. And let's go back again, give you a better look at the other document.

How's that? Thank you. So there we're doing transformations from an XML document to XSLT. Now the next thing we're going to do, and this is kind of a little bit unplanned here, is we're going to go ahead and we're going to take...

Okay. What's your favorite card game? Solitaire.

Solitaire. Excellent. I prefer Magic, but... Okay, let's hope that works. Okay. So now by pressing this button, I'm going to go through and do the transformation, and I'm going to write it out here to the console. So let me just clear the console there, so keep me honest. Press the submit button. And magically, there you are. We've taken an XML document-- I'm sorry, we've taken a NSDictionary, and we've converted it into an XML representation of a plist. So let's look at some code real quick.

This is the serialization portion for taking an NSDictionary and converting it to an XML representation of a plist. Pretty straightforward to the point. And we want to kind of focus on this line of code here. Let me get to it right now. He's the guy that does the quote unquote "heavy lifting." And to do the XSLT transformations that we saw previously, there's a code there. Pretty straightforward to the point. And that's it. So pretty much it's very simple, very little code that enables you to do transformations inside of WebObjects using XSLT. And with that, I'm going to call up Bob Frank so that he can demo XMLRPC and WoXMLCoder.

Bob? Thank you, Mike. Very good. WoXML node and XML RPC. What is WoXML Node? WoXML Node, if you're not familiar with it, is a graphical way that you can use WoBuilder to create XML documents. It allows you to use all of the dynamic elements that you're familiar with for building WebObjects HTML documents. You can use WoConditional, you can use WoSwitch, you can use repetitions, etc., and so on. And instead of producing a pure HTML document, it will produce an XML document.

It has a very tight integration with WebObjects Builder. You can drag and drop. You can drag relationships from EOs, from objects that are in the bottom part of WebObjects Builder, and use them to populate your values for your WoXML nodes. And the document format is under your precise control.

From a verboseness perspective, compared to some of the automatic tools that you get to do the heavy lifting, like NSXML, Object Input Stream, and Output Stream, it's probably going to give you a more compact representation when you build it yourself and you specifically specify what you want the document to look like. On the other hand, when you use the automatic tools that you get with Object Input Stream and Output Stream, they have a bunch of other automated facilities that allow you to serialize, for example, an EO and serialize it back in in another application easily.

When you do use WoXML node, though, one thing that you need to do in your component that's generating your XML document, your page, is you need to set the header, the response.setHeader, to text XML as your content type. What this does, and I'll show it to you in the demo, it tells the browser to realize, or whoever's receiving it, that this is an XML document. IE happens to be very intelligent when it comes to receiving XML documents, and they have a little XML browser built in.

You're all familiar with the typical WoW HTTP application. Well, okay, so maybe this isn't quite a typical application. This is a fairly complex application. You have the browsers communicating via HTTP, going through the firewall, hitting the web servers, sending all sorts of messages all over the place to a variety of application instances. Well, it's a very nice application. What XMLRPC does, it is a method that allows servers to communicate directly to each other over HTTP, typically, and it allows you to execute remote procedure calls.

So, What you'll see is a simple communication between servers to allow them to generate requests on another machine, perhaps running WebObjects, perhaps not, and send a request and get back a response or a fault. A fault is like an exception or an error. What is XMLRPC and SOAP? They're both technologies that are used in the coming popular buzzword of web services. We have an entire session, session 705, devoted exclusively to web services, focusing primarily on the SOAP aspect, so I'm not going to touch very much on SOAP.

XMLRPC is an earlier and a much more simple approach to web services. It's a parameter marshalling mechanism that focuses very much on the metaphor of a remote. SOAP stands for Simple Object Access Protocol. It's much more robust, and it has a lot more buzzword momentum going for it, with a lot of large players in the web services industry. It has much more typing specifications, as Han-Min pointed out earlier, regarding namespacing for schema documents, and therefore it is typically more compact for certain types of representations. And, once again... C705 for more than you ever wanted to know about web services and the SOAP aspects of it.

One other comment about SOAP, it's a W3C note. XML RPC is not. But both are focusing on remote communication between servers so that you don't need to do something, for example, like screen scraping. If you wanted to get data from a remote server, typically many people have implemented a variety of screen scraping mechanisms in order to get data, whether data stock data, et cetera, et cetera. Now, with web services becoming more and more popular, none of that's necessary. And when neither of these protocols focus on remote object activation or garbage collection, those are implementation details of the implementation on either side of the communications channel.

XML RPC. What do I mean when I say strict RPC concept? It means that you have a method or a function name on the remote server that you wish to execute. And you're going to send an XML-based request. Your document is going to be a request, please execute this method for me, and give me back a response. Very much just like traditional functional programming.

All requests in the XML document are falling under a method call XML tag. I'll show you the document structure in a second. All responses are wrapped in a method response document tag. XML RPC uses faults to represent error conditions. And in Java, it is handled very similar to an exception, but in most XML RPC representations and what most error codes mean, they are typically less severe than the error codes. an exception in Java.

To build up a method call, you specify the method name that you want to execute on the remote server. And as you build that up, you add the parameters that you want to pass along to it. And those are passed to the document, depending on the library that you're using.

In my demo, you'll see an implementation wrapping, the Apache XMLRPC jar files. And they take a vector of your arguments. I've written a simple wrapper that maintains the array for you. And you don't need to necessarily build an independent vector or an array and pad all of it with the parameters that you want.

XMLRPC supports a very simple set of base primitive types, boolean, double, date time, integers, strings. They are typically getting more and more support from underlying XMLRPC parsers to support Unicode. Originally, the XMLRPC specification, I believe, specified only ASCII, but due to the fact that more and more XML parsers support Unicode, you get that for free nowadays.

Additional types for encoding binary data, it specifies a base64 encoding, which transforms binary data into a character representation. Additionally, it has data structures to contain complex data, arrays-- I think everyone understands the concept of arrays-- and structs, which is their representation of a dictionary. Names are strings used for keys, and values may be of any type. Obviously, it's unordered.

The values in the XML document are exactly as I specified them in the previous slide. An int is an int tag, and the content goes inside the tag. Boolean is a Boolean specified by 0 or 1. String is a string, any content. Double is a double, and datetime follows this ISO format.

And in the XML RPC jar file from the Apache jar file, it has a convenience formatter that takes a Java date and formats it in this format. All values, oh, and base64. All values are wrapped with a value tag. For example, if you have a string, hello world, everybody's first program string, it's wrapped with the value tag. An array looks like this. You have an array and it contains its data, and the data contains an ordered set of values. So this value is serialized into the XML document and un-serialized in this order from the client to the server.

And the dictionary, each member of the dictionary is a member tag. That specifies a name-value pair. Your key are your names and your values are your ints. And you see in a name, it doesn't specify a string. In XMLRPC, if you do not specify any data type, all data types are implicitly assumed to be string.

But it's best, just like in Java, to specify your types, it's always best to specify exactly what type you have. This is the whole tamale of what an XMLRPC request looks like. You have a standard HTTP header specifying where it's going and what the path to the method on the server is. All XMLRPC requests are done via POST.

And the content type is text, XML. Content length must be accurate, must be specified. And you have your XML header. The method call tag begins the body of the XML document where it specifies your method name. In this case, examples.getStateName. On the server side, you will be looking for this method. And the value is an int specifying 32.

The response comes back. What is the 30-second state? You can see here the answer is Minnesota. The response is a standard HTTP packet with an HTTP response code connection, content length, which again is mandatory, must be specified and accurate, content type, date, and server. You have your XML header, and then your method response makes up the body of your document. A method response has a single params tag, which includes a single parameter. The parameter can include a compound type, an array, or a dictionary, a struct, an XMLRPC vocabulary. And what this does is this gives you the ability to return any value you want from your function.

A fault is a method response, includes a fault and a value, and unlike the method response, it includes a dictionary with two values, a fault code, which is a numeric value, and a fault string, which is a descriptive term for what the error is. There are several common extensions in XML RPC that many servers implement.

System.multi-call is commonly implemented, and it allows you to include an array of dictionaries in the body of your payload that allows you to execute multiple methods in a single request response loop. And a few introspection methods are also commonly implemented by many servers. List methods, method signature, and method help.

Other key features, because it, by default, goes over HTTP, it's very easy to go over HTTPS if your web server supports it. And also it has built-in support for HTTP user password authentication. Likewise, since it's not encrypted, by default, standard HTTP user password authentication is more secure if you run it over HTTPS.

At this point, I'd like to go to demo three to give you an example of XML RPC and blogging. Let me quick fire up the server here. I'm going to show you a quick screen of what the application looks like, and then we'll dive in and take a quick look at the code.

Blogging, by the way, is a very popular thing, popular use of XMLRPC. And in addition to other popular technologies like Jabber, it's also based on XMLRPC. So let me quick log in. First, if you want to take a look, using WoE XML node, I created a WoE component that demonstrates what the request is going to look like.

And since I set the header content to type text XML, Internet Explorer receives this as an XML document and realizes, hey, this is in fact an XML document. I have a little handling built in to show how this works. Here is the structure. Here is the method that we're using. Get user blogs is a login function. It returns empty if there's no blogs for this user. And a temp app key is another parameter that I'm requiring. So let's go ahead and log in.

And you can see it's a very standard WOAP. This is a client application. Boy, am I happy to be here. and we've successfully submitted it to the server process, which is running on the same box. They're communicating over TCP/IP using XML RPC. The request that went out looked like this. Boy, am I happy to be here. And the method was new post.

So, just so that you can see it works, let's take a look at what the blog looks like. Rather than actually publishing a static HTML file, I cheated and just made a little direct action. But, boy, am I happy to be here. I'm very happy to be here. So, what is involved with this application? I made a little core framework wrapping the Apache XMLRPC jar files.

The one thing that I've done that is not--well, two things that I've done. The first thing that I did that was not standard or does not come with the Apache XMLRPC file is I wrote a little converter that converts NSDictionary's and NSArrays to vectors and hash tables and back and forth again. So that way, I don't need to modify the Apache code, and I can still use all of the native types that come with WebObjects and come from my EOs and EOF and just have to call one static method to do a conversion of my array.

And you can see here, depending on the various types that they are, instance of, I convert it one way, and then I convert it back another way. The second thing that I've done is I've wrapped... Hmm, what are you doing here? The second thing that I've done is I've wrapped... Well, it doesn't seem to be happy.

I wrapped the XML RPC code with a woe method call. The machine appears to be spinning, so I will talk for a second while I try and get back the machine here.

What? I think actually you'd probably want to pay me not to sing.

But at this point, I have one last wrap-up slide. Maybe if you have some time at the end of Q&A, I'll show some more demo later. I just wanted to summarize a few things about XMLRPC and compare it with SOAP in one more way. It really is a very simple protocol. It says to the remote server, go ahead and do this one function for me and give me back this one result. The spec for XMLRPC, if you go to userland, this is it. It's only about, let's see, six pages long.

But if you were to go to the W3C and ask them, well, the simple, this is like in SOAP, is like the green in Greenland. Because if you print this out... It's like 50 pages long. And so I just wanted to point out that it's good for doing very limited tasks, but I think that that'll cover a lot of what people want. At this point, I think while the demo machine comes back to life slowly, we could probably take some Q&A.