Good morning, ladies and gentlemen, and welcome to Session 405, Java Web Services. Waiting patiently on stage for his cue is Steve Llewellyn. Please welcome Steve. Thank you. Good morning. So I am the tech lead for Java classes at Apple, and today I'm actually going to talk to you about Java web services from the client perspective. Before I came to Apple a few years ago, I worked for a company that has a little bit to do with web services called IBM, and I did a bunch of client stuff, so don't get worried that suddenly there's a server guy, you know, doing classes stuff at Apple. But I did do some server stuff as well, including working on a project called UDDI, which is a business directory for services, and I'll talk a bit about that more later, with Microsoft and Ariba, as well as IBM. Those were the original founders of that. And it was interesting to be involved in that because that was when the original thinking was taking place. How are people going to use web services? What are they going to do with them? And it wasn't just all about B2B. But as I look out on the web today, if I go to a website and I want to learn about web services, I'm hit over the head with server stuff. I'm told how to set up my web server. I'm told I need this server and that server, and I need a configuration file and all these things. But web services is mostly about a client, hopefully. Hopefully there will be far more clients out there than servers. So given Apple's focus on clients, I wanted to give you a perspective of web services solely from the client's perspective, a developer building a client application. So I'm not going to set up a web server. I'm going to use web servers out on the web, live, that Apple doesn't run. I have a couple of them in case these companies decide to take theirs down during my demo, which can happen in a demo. So with that, I think that the thing to do first is define what a web service is. A few years ago, when I don't know who it was coined the term "web service" came along and did that, everyone stood up and said they recognized the dollar value. This is the latest lingo. And so they said, "Oh, I have a web service. Everything I have is a web service. My web service is a web service. My email is a web service.

My phone is a web service. Whatever is a web service." It kind of watered down the meaning of it to the point where if you wanted to have a definition that covered everything, you'd probably have something like the following. You'd say it's just an automated application that's accessible via any type of protocol, HTTP, SMT, or whatever that you message with XML. In this presentation, given my previous background at IBM where we dealt a lot with SOAP, I want to focus the definition down to being this but with soap specifically and I'll talk about what soap is and in detail and how you use it etc.

So I also want to get across the point that Mac OS X is a great free, quote-unquote, client for web services. We have a lot of different technology to help you build a web services client. One of the best, a little prejudicial, but is J2SE built in Mac OS X. And with 1.4, we're moving ahead with that even more where an XML parser is included by default with J2SE 1.4.

And, of course, you have a great network stack accessibility in J2SE on Mac OS X. And it's also, of course, fully compatible with open source. One of the drivers for web services is the Apache community. And, in fact, I'm going to be demoing some of their code here today called Access. And this is just a SOAP SDK. It's a really good one. I like it for a number of reasons, one of which is its protocol independence. and that's a theme I'm going to hit a few times during the presentation because the protocol aspect of SOAP by many is believed to just be HTTP just because that's de facto the first protocol people are using. But there's others that you can use as well. And I just want to point out that SOAP access is also used by our WebObjects group for their client and server web services. But I also want to point out that you can do all of this on J2SE 1.3.1 as well. You just need to pull across, sit down in your machine, an XML parser like the Xerces parser is a great, great parser.

So, to build a web service, you, again, taking this definition further where you actually need SOAP, you start with SOAP. That requires an XML parser, a good network stack, and protocol support, whichever one you want to run your SOAP requests over, which in this case would be HTTP, SMTP, et cetera. So, to define what SOAP is, SOAP stands for Simple Object Access Protocol. And this is a definition that I copied from the folks did so by added XML-based, but basically this is the official definition, lightweight XML-based protocol for exchange of information in a decentralized distributed environment. It gets a lot of buzzwords in there. And what this really means, when I was involved in this work a few years ago in establishing these standards in UDDI especially, the problem that was really... uh... they were trying to solve is in the world today i i would imagine that any device on any sub network there's some hop of protocols whether you need to go wireless for a while and then you go to another network somehow some way uh... one devices eventually connected to another device But all those devices and the protocols that you use to get from one to the other are disparate. There's all kinds of things going on. So you can't use the traditional middleware of Corvo over IOP or straight HTTP, piggybacking on HTTP, which a lot of us have been doing to get through the firewall issue. So you need something that captured the meaning of what you wanted to do, but was independent of all these protocols to connect all these different devices together. It's sort of like the analogy that I like to give is if I write a letter today, if any of us write a letter, we write it in the language of our choice. I'd write it in English. And all I can guarantee is the content of that message, and I pretty much have an idea that whoever's eventually going to receive it knows the same language.

They can read English. But once I put that letter in the mailbox, I don't know how it gets to its destination, plane, train, or automobile. I don't know. All of the above. Maybe it's carried on foot. Who knows? But the same is true of soap. Again, most people have an idea of it just running over an HTTP protocol, but it could go over all sorts of things. SMTP is one of my favorites that's not used yet, really. So all that matters then is that package, the soap payload, that gets across the meaning of what you're trying to do.

So then, you know, the prerequisite statement here for this diagram is, no, SOAP does not have some subversive way to go through all the firewalls. The meaning of this picture is that we finally have a way for a server on the inside of some company's firewall to safely message a user's machine or a user that's several firewalls beyond. their touch. Before, there really wasn't a way to do this safely and securely. A lot of companies tried different things. The Corba companies years and years ago tried to establish a firewall port so that Corba IOP could go through firewalls, but that was just totally rejected out of hand by the security administrators of companies because they couldn't see what was really going on. That was too much for them. So SOAP was designed to embrace the existing infrastructure that's out there and the de facto rules that have developed and the desires of those who administer the firewalls, the security administrators. So SOAP is transparent. You can write a firewall program or another scanning program that is will scan your SOAP content to make sure, okay, a SOAP message is coming into my company, but I can tell exactly who it's destined for. I can see its content.

If its payload is digitally signed, I can tell who it's from, so it's a bit safer. I could set this scan up on all of my incoming protocols, even scanning, you know, email for SOAP messages, et cetera. So now SOAP, now we have a protocol that finally, It's not as fast. It's not as compact as IOP, for example.

And that was one of IOP's goals, was to have the message be as compact as possible so it was as fast as possible to shoot these transactions off. SOAP is answering a different set of needs, so it's fatter, but yet it allows more flexibility. - Definitely. So it means independence. as well as freedom. So from any source, handheld device, desktop computer, big mainframe, any of these can end up packaging a common SOAP message.

And this SOAP message then can be routed out to its destination via any number of protocols. Again, the protocol independence theme is something really important. So this freedom and independence enable something that's not just B2B? Because in B2B, companies were setting up firewall IP tunneling between their companies so that they had some contractual agreement amongst one another. Only they could message the other company through this method.

It was all secure. That's hard to do with customers. You can't go to each of your millions of customers and say, okay, I want to set up this tunneling mechanism and all these things. That wouldn't fly. But this freedom and independence in SOAP means that now we can get things like a business-to-consumer.

You can really imagine now where you buy something, and the company ships it to you through some shipper, and part of their customer service is they want to contact you and make sure you receive that package. Today, you can imagine with SOAP, in fact, you could take what's on OS X today. You could have a program in your email that runs in AppleScript when it receives a message that has subcontent signed by this company, the receiver that has certain attributes about it, so that this company emails you this message. It says, did you receive this? You click yes in your email when you get it. Pardon me.

And it sends a note back to the company all electronically saying he received it. If they don't get that message back or they get a no, then they call you up and they say, gee, sorry, whatever, take care of it. It also enables more user-to-user. A lot of people, there's a huge IRC chat community out there, and now we have iChat on OS X. But you can imagine in the future where you have chat going on with SOAP. Any sort of device is just packaging up this SOAP message, chat going back and forth over all kinds of protocols, expanding the world of who can contribute to the chat room discussion. You can also imagine device to device. And again, I think you're going to get sick of this theme by the end of this, but transport independence, protocol independence again. You can imagine where you have some software on a handheld device that wants to sync up with any number of other hardware devices. Say it's transferring its address book or something else, and this device has USB inputs and it has infrared, it has all these different things, it also has wireless.

and it wants to get that information to another place. Well, to some degree, the developer who writes that syncing software can just worry about if he used SOAP, he could split his problem into two pieces. He could say, first of all, I'm going to develop my messaging part of my program where I'm going to package up my address information into SOAP messages. And then the second part of my problem is I'm going to have an infrared protocol and I'm going to have a wireless WAP protocol, et cetera, to then move that data across to the other machine. So it's useful in many different areas, not just what a lot of people think of today, which is, say, some car company is buying tires from a tire company or something, something kind of worth a lot of money but a little boring to the average consumer. summer.

So I wanted to just touch upon a few real-world applications, and a month or two ago I stumbled across these. UC Berkeley is deploying a unified messaging system using SOAP. I don't know how far along they are with this program, but the gist of the idea is that they have their student records, class schedules, all these different things, and legacy systems, and they want to provide access to this information over the phone. You just press the buttons, press 1 for the class schedule, press 2 for whatever. And they also want to provide access through the web as well. So with SOAP, they can have these systems package up these SOAP messages. And someone calls on the phone and they type in a certain number, their student ID, or they go on the web and type in a student ID. Eventually, a SOAP message will be packaged up and off it goes to some system and gives them some results. The United Kingdom has an e-government interoperability framework. And the theme of this, the desired structure of this, is that central and local governments would share all their information via SOAP and UDDI, the Universal Description Discovery and Integration, kind of the business directory type thing that I worked on a few years ago. So those are real world things people are really getting their work done. They're not going with other traditional things, Corbar or RMI or something. Those are great, but because of other limitations, they're scaling for what customers and things they can connect is more limited than soap.

So now I want to go over just a soap technical overview. I'm not going to plunge very, very deep, but I do want to show you the structure of soap and a bit about how it works. Thank you. So, again, SOAP is XML-based messaging. If you look at a SOAP message, and I'll show you a few, it's in XML. It's all in XML, which is great because anyone can get out a parser, and they can parse it, and they can build XML. You can even just, you know, you could construct a SOAP message by hand even and just send it across with a put or something over HTTP. The SOAP message itself, again, being transport neutral, just defines the contents of the message, who it's eventually intended for, and optional attributes that can be used, and I'll discuss optional attributes in a bit. And, you know, no method of how to send or receive the SOAP message is comprised in the SOAP message itself. SOAP is inherently actually one way. It's just a message.

It gets sent off. That's all there is to it. But the de facto way people have been using it over HTTP, that's request response. so that has formed a good RPC mechanism that people are used to. So they have a response format that comes back, and we'll talk about more of that in a minute. SOAP also defines a fault reporting system. So eventually, if something goes wrong, you want to know what went wrong, where it went wrong, get some description or something you can tell your user.

So graphically speaking, containment-wise, on the right-hand side, you have the SOAP envelope. In it, you have the SOAP header with these optional elements and the SOAP body, the actual meaning of the message. With the SOAP headers, you can define optional attributes. Some people are sticking transaction IDs in them and doing other things, and that is going to be leveraged as other standards for SOAP come along. It's the generic holding place for these other things. You can also specify something in SOAP that says, when my message gets somewhere and I have some extra optional header, since I don't know exactly how it's going to arrive there, it might go through some other node, and I'll describe what a node is in a minute, I want to make sure that that guy can understand what I'm saying, that he's just not parsing it, ignoring what he doesn't understand, and sending it on. So there's an attribute there that says you must understand this if you don't generate a fault. And again, the soap body contains the actual message.

So, nodes, roles, and actors. If you really want to understand how SOAP works and how SOAP is envisioned to work more than just over HTTP, just a two-peer architecture, a client-server, you should understand nodes, roles, and actors. So, SOAP messages are processed by nodes. Everything in a transaction is a SOAP node. A client is a node. The final destination is a node. Anyone in between is a node. Nodes play different types of roles. There's three default roles, and you can define additional roles if you want yourself. The next role, it's called next, is just whoever receives the message next. Everybody implements the next role, and they must, by implementing that role, properly parse the message, generate a fault if they don't understand certain things, et cetera. There's an anonymous role, which is just the final destination of the node that is the final destination of the message. There's a none role, which is you may define custom roles and things and have additional header elements that really are just additional data to other header elements. So in that case, you just have a none role for that. And, of course, custom ones. So you could have a role that says logging. Let's say that you wanted your message to be logged at each site along the way that it traveled. You could define a log role, and you could say each node must understand that role if they don't generate a fault code. So that's the nodes, roles, and actors. And again, this diagram is just demonstrating we have three different nodes. They have different roles. The message is going over different protocols. Generally, the client only knows the first protocol.

He's not aware of whether the message travels along multiple nodes or he's sending it to its final destination. The question is, what are some of the key elements of this is We're going to be And by the way, I mean, SOAP can even be defined, the transport can even be defined as I copy, you know, I'm sitting in an app, I have two machines, and I'm sitting at one machine, and I do something and it says, please insert a floppy, and I insert a floppy, and it writes a SOAP message to that floppy, and it says, please eject floppy and carry it over to machine B, and I do that and I stick it in machine B, and I hit a button and it reads it in, and then it writes back a SOAP response on the floppy. says, please eject this and stick it in machine A, and I do that as well. And that's valid as well, because SOAP doesn't define the protocol. In that case, I was the protocol. Um... So this is just a nasty XML example. I mean, XML is pretty simple, but, you know, it's not all that exciting either. Just a few elements. We see the higher-level envelope element in line 2. We see the header elements and the body, and we'll show a more detailed version of that when we go to SOAP RPC. So SOAP supports XML schema data types. So you have your floats and your ints and your strings, your VNUMS, byte arrays, compound types, structs and arrays. SOAP has out and in-out parameters as well as in parameters. So let's say you built an application with SOAP that the web service was to validate email addresses or whatever information you have about people. Let's say you want to validate every month or so. You want to make sure that the home phone numbers of the contractors you're working with are still valid. So you have 1,000 contractors, you email them off to the contracting service. Not email them off, but use whatever with SOAP. You have a SOAP array of 1,000 employee structures, and only two of those are changed.

You certainly don't want to get all 1,000 of those back. So SOAP defines XML schema data types that have different ways to send that data back efficiently. You could say the last 50 elements of this array are different and only send those back. or you could say element 3 and element 27 are different and only send those back, so it's a bit more efficient. You certainly don't want to send that 1,000-element employee record structure around, forward and backwards, if you don't have to. So SOPARPC requires a valid URI that's a binding point for the protocol, a method name, parameters, the ordering, whether they're in and out. And additionally, you may specify optional headers, again, if, say, your application did define transaction IDs or something.

So this is a slightly more interesting SOAP RPC message. The additions here really are on the SOAP body. In line 6, we see the method name echo string. This is a very simple RPC. It's just echo back to me what I sent to you. It has a test parameter in line 7 that says hello, and then it gets a response.

And SOAP RPC replies the structure, first thing being the return value, and then the out and in-out parameters in the same order they were sent in, or a fault code with fault string, fault actor. So you want to know if there were 10 nodes within this SOAP message, how the SOAP message was processed. You want to know that the seventh node is the guy that failed, and you want to know why. You don't want to just know, oh, it went into the great bit bucket in the sky and died. So the SOAP RPC reply then for that is very simple also. We see the echo string response on line 4. On line five, we see the hello string back. Very, very simple. Obviously, you can do much more complex things, but that's what fit on the screen, so that's why I put that up there.

So, this isn't worth a whole lot if you don't have some way to describe the interface to your SOAP service. And you do that by using the web services description language. And that's IDL, an XML schema. If you're familiar with Corbo or DCE or DCOM or something, you always had an IDL, some intermediate description language you wrote your interface in. Eons ago, people would sit down and write their interface in IDL first, then generate from that a skeleton for their server, stubs for their client, fill out the logic for their skeleton, and then implement the application with that. Nowadays, people like to start with a language they're familiar with.

One of the reasons RMI is so great is that its interface is Java. So you just write your Java RMI application and then if people want to using RMI-IRP, for example, they can generate IDL from that instead, kind of the reverse. The web services IDL, WSDL, specifies, again, what you'd expect in these other IDLs, method name, printer types, location of the service, which is kind of new. This is optional, but in WSDL, if you go grab some WSDL off the web, and I'll show you in a bit some places where you can do that quite easily, it has the DNS name for the web service that you'll be talking to, which is really neat. You just get the WSDL, and a lot of times that's all you need. So again, WSDL is typically used to provide client interface to existing web services. So what people are doing right now is taking legacy systems that are running in Corbo or something else, and they're using compilers such as Java to WSDL that reads Java and generates WSDL from it, and then they're giving it to their Microsoft and Net clients or other Java clients that are then using that with a WSdelta Java or WSdelta.NET or whatever. I haven't used the.NET tools, but that generates then the language-specific bindings that they need. And again, as I said, it may be used to initially define the interface as well. Thank you.

So this is a typical WSDL scenario. So, again, you know, people have their existing server in Java. They use that compiler I mentioned. They generate the WSDL, and they publish the WSDL to some sort of web services listing. Sometimes that's a UDDI type of thing, which is more like a DNS... People can use it almost as a DNS lookup or something. Thank you. Or they just put it on a web page, and we'll go into more of that later.

Somebody else comes along, they grab the WSDL again, they use it, and there is no such thing as WSL to Objective-C compiler, but if there was such a thing, you'd read in WSDL, generate an Objective-C binding, so you get an Objective-C object, bring it into your IDE and build your business application out of it so that then you can call the existing server up there at the top left.

So service discovery, then, how do you actually find these services that are out there? There are two basic ways right now. Manual, where a developer finds a service from web page listings. He just goes and browses around. Or assisted, you have tools to help you. The tools that would be coming along are tools built in your IDE, for example, where it's connected up to your UDDI server, and you can enter some information in your IDE. It will make the queries for you. That's just a bit of a step beyond totally manually browsing for this. There's also something called WS Inspection, which I think in practicality is going to be more successful, is my own personal opinion.

But basically, in a nutshell, if you know a popular URL, some company's URL like www.apple.com, there might be a standard that would say, okay, you can find the WSDL to their online store. This doesn't exist, but this is just fictitious, but this is an example, where you go www.apple.com slash WSDL. You type that in, and suddenly you get a listing of all the WSDL that they have. Thank you. So manual discovery is what I term the Yahoo approach, where somebody has manually cataloged this. Either a company is out there searching the web for web services, and they're publishing them. I'll give a couple examples of that. Actually, at the bottom, southcentral.com, xmethods.com.

Those are two good ones. Or someone adds to this service a search engine, an index, categorization. I'll give you a demo of what those web pages look like. The semi-automatic discovery is a well-specified lookup. That is, actually, a lot of people are providing web services to look up web services. An example of that is UDDI, as I mentioned before. This is an industry initiative for publishing web services and discovering them. WS Inspection, I mentioned, and Disco is a Microsoft legacy version. they had, I believe they still support it, but they've also embraced GDDI.

So universal description, discovery, and integration. This is two things. This is, one, a directory service, a virtually single directory service running on the Internet that is actually made up of nodes shared between Microsoft, IBM, HP, SAP, et cetera, that you can go to, you can publish your information about your business service, like I sell tires or something, and within, say, 24 hours, that information is replicated to the other nodes, Microsofts and HPs and SAPs, so that it virtually looks like one directory, and then anyone can go to any of those nodes and look that information up. They provide another interface, just a web browser interface, another categorization way to discover things. You can also have private implementations. You can just take the UDDI spec and implement it inside of your company. You can write it from scratch. There are also implementations of it that you can get from different companies. In fact, our WebObjects 5.2 will include an intranet UDDI server that they built using WebObjects and just implementing the interfaces to UDDI, which are SOAP interfaces. So that's kind of cool. So UDDI, again, you register it in any operator.

And what you register is several different pieces of information. One is the name of your business, the type of business it is so it can be categorized, the URL to the website. You get a unique ID from the registry to uniquely identify your business entity. You say what services you provide. You could say I sell widgets and specifications. In the end, the specifications would most likely be WSDL along with a document. For example, I'll show you this morning I was messing around and I downloaded Google's WSDL stuff. It's really cool.

Just work like a charm. And in that, they have a document and other things that describe how to use it. For example, it says you first must register at Google to get your account ID, and you must send that along with your request. So that type of information can't be described in WSDL, but they also then include the WSDL itself. And then you have service types and methods to categorize business and services. There are common industry taxonomies. The government has a taxonomy to define businesses. Even the UN has a taxonomy. So it's just a way for people to look up, to start to drill down and to find the service they're interested in.

UDDI operators, each operator, this is in the universal directory again, has a registry. They replicate that information. It's not real-time. Again, registration takes place at any operator site, so just conduct it at any operator site, as I mentioned. So here are a few UDDI SDKs. There's a UDDI for Java, which is done by IBM, HP, and SAP. And again, it provides the SOAP interfaces to look up things in UDDI. It's very easy to use. Microsoft Visual Studio.net also has a similar SDK. There are also various people out there that are just creating new web services to browse UDDI in different ways. And then WebObjects 5.2 includes a UDDI version 2 database and an EO model for that, which is really cool.

So I want to do a couple of demos. And the technologies for the demo, just J2SE, 1.4, XML parser, the Access SOAP toolkit, a little bit of Objective-C. So just to show you what the demo is all about, I'll switch to my demo machine here. And the first thing I want to do is basically what this service is, and I'll go and show you how I build it next. But what it is is if you're familiar with Mac OS X and application menus, every application has a services menu. And this is just how I happen to tie in my web service. It's kind of unfortunate that this is called services and I'm talking about services, but there are different things, local services versus web services. But I did tie it in, so I have something called Find News. And there's a company called Moreover News out there that has a WSDL interface to news sources all over the web. So what I did is I created a client that when you're in a Cocoa app, even in Terminal or something, and you go to Services and you say Find News, it looks at what you have highlighted, packages up a call to this service, calls out to the online service, and it gets back a bunch of XML. And then it reparses that XML, transforms it into HTML, and then pops up the web browser with information. So I looked up Darwin, so who knows if there'll be any Apple stuff. But if we just go to... I don't know. This is like a lot of... You have to be careful what you do here. I'm not going to click on just any one of these. a lot of drinking interesting Charles Darwin okay this might be safe so it goes out to the particular news story and it's that plain dealer and Charles Darwin you lose the game okay it's something about Ohio schools but anyhow it's pretty interesting and that all happened really fast again that's live I don't even know where this company is located they could be running a.NET server or a Java server I don't know I don't need to know it just works so how did we get there from here well the first thing I did was I downloaded a WSDL file and I did that actually from let me go to one of these places I believe it was xmethods So this is one of those web service listing companies that's kind of like Yahoo. This one, is this the one that lists what it's implemented in? Yeah. So this is really interesting. They have a bunch of web services listed here. And let me hide my doc here.

And one of the things they do, actually, is they say what implementation it is. And they also say how you can get to it. But in the end, they just provide WSDL and links to the companies who do it. Let's see if-- see if it's still on the front of the list. So here it is, more of a new service. Actually, it's implemented with MS.net, so that's pretty cool. So we called out to something that was using MS.net. We see Apache SOAP here, all kinds of different implementations, a lot of Delphi, which is really interesting.

I used to use Delphi. It was really neat. So then what you do is you go to one of these websites, and let's see, I think I lost my there. There we go. And it goes, in this case, X methods gives this type of view of the web services.

And it says, you know, a company, you know, who owns it, you know, the contact, the home page, the implementation, all sorts of different things. And also will show us the WSDL. So in this case, what I did was I downloaded WSDL and then I set up a little project here that will compile the WSDL just with a Java class that's a WSDL2 Java emitter, and that allowed me to then generate... Whoops. That allowed me to generate... Let's see. I think I opened it. A bunch of Java from that WSDL. It's just a bunch of binding code. It looks pretty nasty, but in the end, it has something called Get Custom News. And so I'm just calling this API, and the Access Toolkit is doing a bunch of things under the cover for me, taking away all the complexity, setting all the attributes, et cetera, making the call, and then returning the information. In this case, it was a big XML document.

In fact, if we go to, I dumped this file in Temp. So if I go to user temp, if I go to, actually, I think it's just temp. So if I do more on any of this XML, we see that we just get a bunch of XML back, a bunch of article IDs, et cetera. I just parsed this out using SACS, actually. SACS is really good to handle your XML results, especially when you're doing something like this because you don't want to keep the whole result in memory. You just want to fish through and get out what you need. So when I did that, I just wrote a really simple kind of, I don't know, it was a little cheesy. I just took a SACS parser example real quick for the demo. And then I go through, and as I get element callbacks, the start of elements, I just grab out, I just mark, keep some state as to what I am, like what I'm getting, headline text or source or what have you. And then when I read in the whole element, I just put that in a little array of results, and then I hand it back to another processor that creates some HTML for me, saves it out to the file, to another file, which we saw here. We saw in the temporary directory both HTML and XML files, saves it out in HTML, and then I return the URL to that element to a little piece of Objective-C, and I'll actually show you that just so you know how simple it is to do one of those service item menus. So in Java here, I turn the HTML file, and if I go to my little test file, this is basically a method that implements this menu item, the Find News menu item. Right now I have no text highlighted, so it's desensitized, disabled. But I just implement an Objective-C method that whatever text I have highlighted comes in, and I just do some things with it. I'm going to send it out to Java to do my parsing and to call the service, et cetera. So I get a JVM, I attach to it, I package up my string, and I locate my Find News class, I make the call. And then I use Objective-C, Coco's... Pardon me.

And it's Workspace. and I can open that URL in two different methods, open URL or open file, and I'm using open file right now. And that's what causes then Internet Explorer to open up with that file in it. And it's just opening up again the temporary file. If I go back here a few, it's just opening up this temporary file that that generated. So that's pretty neat. And again, pretty fast. I also want to show you another website that has a similar thing called South Central. It's similar to X Methods. I'm just trying to kind of be a tour guide to web services for you guys. So if you've seen this before, I apologize, but other folks don't know actually where to find these services. So here's another listing where I can type in anything.

There's a lot of things about stock and time and things like that, So I'll type in the word stock, and we'll see what services are implemented to deal with stock. So this is typically the best way, basically, to find services out there right now. So we have one that gives you a company profile. It shows what version of SOAP. Most of these are using 1.1 now. Some still use 1.0. Here's one that uses 1.0. Just a bunch of different services. And again, on South Central, I can go and I can get the WSDL, and I could copy this out. I can just look at it, et cetera, find more information. So that's how to call simple services. But I had mentioned earlier this morning I went out and looked at Google. Google is doing really neat things, and one of them is providing WSDL Web Services API to their search engines. So if we go down to... here. Navigate to that. Bear with me.

to go to the area where I dumped all the Google information. I just grabbed this, compiled it, and it ran. Again, just standard Java, standard XML, standard SOAP. So in the case of Google, I had to first go out and register at Google's site, and I got back a key. And don't copy this down.

This is my secret key. But basically, it's interesting. People are on the frontier of what to do with web services. These are some of the problems that I remember we discussing when working on UDDI with Microsoft and IBM, how people will get a guarantee of service, how you'll establish contracts and those sorts of things. So I've seen a couple of interesting developments.

One is this Google approach where you register, you get a key, and then to call the service, you need to pass that key along. so that then they have a couple services. One is neat. They just allow spelling. Whoops, that broke off in the... Pardon me. That broke off when I did more. Okay.

So if I do that again, this is just command line. It's ugly, but still interesting. So it's calling Google, and this service Google provides said, you spell Apple with two P's, dummy, not three. They have another service, which is interesting. So I could look up news again, another news thing about the iMac.

And again, it packages up XMLRPC like the moreover news example did. and I get back again a bunch of XML. And so then any XML parser can parse this. It's really, really interesting that this is so easy to do. Another thing that I've seen recently is people wanting to make sure that you read their copyright information text. And so I've seen a service, I won't name who they are, but I was using them to a point, and one day it stopped working. And so I looked at the XML I was getting back, and it said, notice this copyright statement may break your XML parser. Please pass this extra parameter to eliminate it in the future. So one, to get my service to work again, I had to have read that. It was an interesting approach. And two, again, it listed the rules and regulations, the license agreement that I need to use that service. So some of this is still in the frontier, but a lot of it is still really useful. So those are the demos. And again, very easy to use. I would actually like to show you one other thing when I think about it. I want to go to xml.apache.org. This is one of my favorite sites for XML in general. And there's all kinds of great things going on at this site, including non-server-based things.

We see the Xerces parser is out there. Another interesting thing is Batik, which is a graphical scalable vector graphics sphere. But we also see SOAP, the Crimson parser from Sun, the Exmo parser, and the toolkit that I used today, Access. So if you want to learn more about that, you go to their site.

And just quickly, one more time, on the transport neutral aspect, the best thing I like about Access is that it's broken up. It's division of labor between packaging up and unpackaging the SOAP message and the actual transport itself. So you can plug in other transport mechanisms. So you could do this over anything. You could plug in an IOP, a Corvo IOP protocol, if you wanted to. That really wouldn't make any sense, but you could plug in whatever you wanted to. So, again, this is another great, great source. They have, you know, it's all open source. You can grab their stuff. Compiles on Mac OS X easily.

not hard to do at all and then you just dump the jars and you stand in extensions directory and you're ready to go so back to the slides then So to review what that finder example was, you just went to that services menu item, you went to internal news process, and that went out over HTTP, in this case, a de facto standard, to the more news service. It packaged up XML for the result. Back to my news process, I put that in HTML, and I sent it to the browser. So these are some URL references, These are just interesting places you can go. The W3C has a lot of information about web services. The IBM and Microsoft have the WS inspection spec. You can go to uddi.org to get the UDDI information. Web services listings, again, my two favorites, South Central and X Methods. The SOAP Access Toolkit, again, xml.apache.org. And Sun Jack's API, which you can do all the same things with, and I think they have Early Access 2 out now, from their website. Just go to java.sun.com or javasoft.com, and it's right up there right in front, and you can go and grab that. And they have a bunch of great tutorials at Sun as well about web services and how to use the JAX API. And... Sorry?

unexpected slide. They slipped this in. I didn't see this. So I guess this is different ways to get the documentation and the slides, et cetera. And roadmap at 2 o'clock today, web objects and web services. That'll be a really interesting you-want-to-go-to session. And we've already had some other web services talks previously that I hope you were able to attend, such as Steve Zeller's talk.