Good morning ladies and gentlemen and welcome to session 405 Java Web Services. Waiting patiently on stage for his cue is Steve Lewallen. Please welcome Steve. 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 the thing to do first is define what a web service is. A few years ago, when I don't know who it was that coined the term web service, came along and did that, everyone stood up and said, they recognize 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 server's a web service. My email's a web service. My phone's a web service.

Whatever's 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, specifically, and I'll talk about what SOAP is and in detail and how you use it, et cetera.

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 it's protocol independent.

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 are 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 the down-to-earth machine an XML parser like the Xerces parser is a great, great parser.

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, etc.

To define what SOAP is, SOAP stands for Simple Object Access Protocol. This is a definition I copied from the folks who did SOAP. I 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. 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

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 Corbo 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 is going to be the one that's going to receive it. And whoever's 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 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. All that matters, then, is that package, the SOAP payload that gets across the meaning of what you're trying to do.

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 via, over the phone, you know, you just press the buttons, you know, press one for the class schedule, press two 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 the student ID. Eventually, SOAP message will be packaged up and off it goes to some system and gives them some results. The United Kingdom. Steve Lewallen 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. And 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. 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 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. I'll discuss optional attributes in a bit. 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. That has formed a good RPC mechanism that people are used to.

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. 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, etc. There's an anonymous role, which is just a final destination. There's a non-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 non-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.

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 application. 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. It 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.

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 a 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 7th 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 this echo string response in line 4. In line 5, 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 you can do that.

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 WSDL to Java or WSDL to .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.

This is a typical WSDL scenario. Again, 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.

and his team. 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, 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, 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, they're at the bottom. Southcentral.com, xmethods.com, those are two good ones.

If 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. 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. The latest inspection I mentioned, and Disco is a Microsoft legacy version they had. I believe they still support it, but they've also embraced UDDI.

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, etc. 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, Microsoft's and HP's and SAP's, 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. You can also implementations of it that you can get from different companies. In fact, our WebObjects 5.2 will include an Internet 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, the WebObjects 5.2 is the name of your business, the type of business it is, so it can be categorized, a 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 the document.

So, this morning I was messing around and I downloaded Google's WSDL stuff. It's really cool. Just worked 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.

So, the WebObjects 5.2 is a great way 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. Here are a few UDDI SDKs. There's a UDDI for Java, which is done by IBM HP and SAP. 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. Web Objects 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 built it.

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 they're 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 gets back a bunch of XML. And then it reparses that XML, transforms it into... To 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 at that plane 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.com. 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...

is the director of the Java Virtual Machine Center at the University of California, and he is the director of the Java Virtual Machine Center at the University of California.

I'm going 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. In the case of Google, I had to first go out and register at Google's site, and I got back a key.

Don't copy this down. This is my secret key. 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. 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 the key. Then to call the service, you need to pass that key along. They have a couple of services. One is neat. They just allow spelling. That broke off when I did more.

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. 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. 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. You can go and grab that. They have a bunch of great tutorials at Sun as well about web services and how to use the Jack's API.

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:00 today, Web Objects and Web Services. That'll be a real 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.