Good afternoon, everybody. I'd like to begin with a couple of announcements. One, anybody who is interested in being considered for the beta program, we would encourage them to sign up at applec.apple.com/webobjects. And I believe we have the URL posted in our lab in Room L, and you can probably sign up online there.

And also, one of the things that we're doing is we're collecting business cards of developers of websites that would like to be included as kind of reference sites or reference customers. And so after the session, I'll be on over there if anybody's interested in that as well. So with that... I would like to introduce Melissa Turner for our WebObjects and Web Services session.

Thanks, Bob. Hi again to those of you who were here last year. I'm still Melissa. I'm still in WebObjects engineering, and I'm still a female engineer. It still happens. I'm here today to talk about web services and WebObjects. A lot of you probably know that there's been a lot of hype in the industry over the last year or so about web services, and we thought we should do something about that in WebObjects and help you go in a direction that a lot of people seem to be wanting to go.

This session is going to introduce basic web services technologies, and I'm going to talk about using WebObjects to vend and consume web services. What we expect you to learn from this is a little bit about some of the buzzwords that are out there in the industry now. SOAP, WSDL, UDDI, Apache Access.

We expect you to have a basic grasp of how to vend a web service using WebObjects, both using the traditional model where you get to write all the code, and using direct-to-web services, which some of you may have heard about during the tools overview on Monday, and how to consume a web service using WebObjects. I'm not going to talk about any WebObjects technologies in depth. If we shipped it last year and you don't know about it, this is the wrong place for you to be. And I'm not going to talk about .NET, which is Microsoft's entry in the Web Services Fair.

What are web services? Well, I could give you a great big long dissertation on what web services might or might not be, but I think a picture's worth a thousand words. Web services aren't really defined. Everybody's got their own entry. For discovery, you've got Disco, WSDL, WS Inspection, UDDI. You've got Crimson, Xerxes, the Jax-P parsers. Everybody has come up with their own standards, their own specifications, and the industry's currently trying to hammer out which pieces are going to be used.

Parts that people seem to have come to a consensus on are that web services are web pages for computers. They're basically intended for application-to-application communication. There's not intended to be any human being in the link, except possibly you as developers who are going to have to, well, debug this stuff.

The information transmitted is commonly agreed that should be XML encoded. This usually means using SOAP over HTTP as a communications protocol. We'll talk a little bit about SOAP later. Web services are described using WSDL. We'll talk about that later as well. And we'll talk about how they can be located using UDDI.

Why are web services? This is a really big question since it seems to be so big and so hyped in the industry. Web services, well, they're intended to be an integration technology to allow people to move data between all of the very strict vertical silos that are out there. You may have a database that you've built for your customer end using WebObjects that serves web pages and serves as your online portal for customers to come and purchase stuff from you.

You may have a separate customer relationship management system that's independent of that. You've probably got a purchasing and fulfillment system. You may want to automate your business processes and get all of these things talking to each other so you don't have either people or demons moving data from database to database to database, which is what tends to happen nowadays.

How can you do this? There's a few types of web services. There's RPC-based web services, which essentially involve making a remote procedure call. You're all familiar with this. Using either SOAP RPC or XML RPC seem to be the big contenders. There's also SOAP document-style services, where you simply pass a wad of XML, and it's up to the receiver on the other end to figure out what to do with that large wad document. You can have synchronous or asynchronous services.

The most common ones are: currently synchronous with a request-response loop, that may be followed from the fact that it's done using HTTP, where you naturally expect to have a request-response loop. What people are starting to talk about as well are asynchronous web services where you may register using one particular call and get, at some later point, one or more notifications from a web service. A good example of this would be a list-serve type of thing where you make one web service call to register for a mailing list and you subsequently get lots and lots of messages from that list.

Technology-wise, I've already mentioned SOAP. SOAP is a lightweight XML protocol for transmitting data in a distributed environment. What does this mean? Well, it means it defines the contents of the package you're passing around, but isn't bound to a wire protocol. You can pass SOAP messages over HTTP. You can pass them using SMTP. And if you want, you can go all the way down and do SOAP over TCP. A few people have done it.

So SOAP defines what the messages should look like, but doesn't define how you transmit them around. An example of this would be, here's a SOAP message. You can see that it's got an envelope that basically delimits the data that's being passed around as part of this message, and specifies the encoding that's used to read data out of the message. It has a SOAP body that says, okay, here's the payload. And it has a payload. This specific example that we see up here is for an RPC request.

So, The root element of the SOAP body is the name of the SOAP request that you're trying to pass. And it's children. are the parameters to the request you're making. In this case, we have a--this is the canonical stock price request example. So we're passing across the stock symbol and the company name.

Here's the response for that request. Again, you see a SOAP envelope containing the same information that was there in the request. A body. In this case, we've got a response element, again, containing the payload, which is all of the information that's being returned by that request. In this case, it's a data structure containing the last trade price and the day's volume of the stock, the stock trading.

That's pretty simple. That's SOAP. That's one of the main web services technologies. Next would be WSDL. WSDL is the Web Services Definition Language. It's used to define interfaces for web services. It sets out such things as the location, the data types in use, and the messages that can be passed. If we could go to demo machine one, I'll actually show you a WSDL.

This is the WSDL for the Google search service that a lot of people have been talking about. Google announced it a couple of weeks ago. You can see that basically it's an XML document with a whole bunch of nodes. You start reading WSDLs usually from the bottom up where a service is defined. In this case, the service's name is the Google Search Service, and it defines-- whoopsie-- A port name, which is dealt with higher up in the WSDL, and a binding, which is also described higher in the WSDL.

And here we can see the location to which you send SOAP requests if you want to access this service. The bindings deal with the communication protocols in use for invoking a web service. In this case, it's the Google Search binding. We see that it's an RPC. There are some times I find Explorer extremely useful, and sometimes I find it extremely, extremely frustrating.

We can see that it's an RPC-style service, and that, again, its transport mechanism is SOAP over HTTP. We can see the names of the operations that this service supports. I'm going to digress a little bit here briefly to talk about the difference between a service and an operation. You might want to think of a service, a web service, as a class, and operations are methods on that class that can be invoked.

So, down at the bottom of the WSDL file, we talked about the service itself. And in the binding and port type segments of the WSDL, we talk about the operations. In this section, we see that there's SOAP operations, we see their names, and we see a little bit of information that we don't really need to know about because we already know that it's SOAP HTTP. If we go and look up at the port types, it will define the input message and the output messages for a given operation. The messages are also defined in the WSDL file.

Here we'll look at the Do Google Search message. Do Google Search is an RPC call that takes a number of parameters. We can see here, it takes a key, something called Q, start, max results, filter, restrict, and a few other things. We also see that the types of these parameters are defined. So a developer who's looking at this WSDL knows that they can make a SOAP RPC call with all of these parameters to the address that was specified down at the bottom of the file, and they will get-- A response.

We see here that the response is, well, it's a return value, and the type Google search result. Well, that doesn't sound like a type I'm familiar with. So if I go look up further in the file, well, here's a Google search result type. It tells us all we could possibly know about that type. Google search result is essentially a structured data type containing all of the following elements.

It contains whether document filtering is on or off, some comments about the search, The estimated total results and all the things you're familiar with seeing on the Google web page when you actually do a search. So that's a WSDL file. It's actually fairly simple, fairly straightforward, describes everything you need to know about a given web service and its operations. And now I need to go back to the slides.

So that was WSDL. Oops, that was the faux demo. Sorry about that, guys. Technology-wise, there's one more technology that's very popular and very discussed in the web services world, and that's UDDI, or the Uniform Discovery and Description Integration. Basically what UDDI is is a spec that describes how to build a registry for information about web services.

It can be a public registry. Microsoft and IBM both run registries where various businesses can go and enter information about the business, about the web services it's offering, all kinds of stuff. Or a company can run a private registry that contains information only about the business partners they actually deal with.

UDDI has three types of data in its registry, what they call... White pages, yellow pages, and green pages. White pages is essentially the information about the business, the business name, its contact points, the services it offers. Yellow pages is taxonomy information that is only relevant to somebody trying to locate a service. And green pages, which contain all of the information about how to invoke a given service.

The green pages are originally intended to be what the UDDI spec calls a T-model, but what seems to be happening is that a lot of the T-models contain only one element, and that's a link to the WSDL that describes the web services. And just as a point of note, Unity AI Server can be built as a direct-to-web services application. We're hoping to provide you with an example of this when we actually ship our next release. But we're just hoping at this point.

So those of you who have been sleeping through that part can wake up now because we're going to start talking about web services in WebObjects. Whys and Hows. Why do we have web services in WebObjects? Well, the most obvious answer is that we're one of the silos that people may be wanting to move data in and out of. We've got a very proprietary data model, proprietary interfaces. It's hard to talk to us.

We're also one of the silos people want to move data out of. You build a web app for your customer purchasing, you have to move it into your purchasing system somehow. We're hoping to allow users to leverage existing WoW investments. I mean, you guys, a lot of you, have spent lots of time building EO models, lots of time building business logic. We don't want to force you to rewrite that in another environment. We want you to be able to leverage what you've already got.

For people building new applications, we want you to be able to leverage EOF. I mean, we think EOF's a cool technology. A lot of you guys seem to think EOF's a cool technology. We'd like to let you use it in the web services space as well. And we're hoping to let you leverage the web services session model. Sessions are something that haven't been really well dealt with in web services to date. We think we have a pretty good solution, and we'd like to let you use it.

So what do we do in WebObjects to support web services? Well, we're providing support for web services being used as either a client or a vendor of web services. We're providing direct web services, which Ron will talk about later. And we've built our product around Access, which a couple of weeks after I started research into web services, one of my coworkers asked me, why do you keep talking about EO Access? It's like, I'm not.

Works better in the verbal than visual realm. But for the rest of this presentation, whenever you hear Access, think Apache Access, not EO Access. Access is an open-source SOAP stack being produced by the folks over at Apache. It's their next generation of Apache SOAP. It's completely rewritten. It's a lot more modular.

They've broken the dependencies that the Apache SOAP had on running inside a servlet container. All kinds of good stuff that we thought made sense. But we've made it very fitting to put inside WebObjects since, well, the world really doesn't need another SOAP stack. There's a lot of them out there.

And it, like I said, is at the heart of our implementation of web services. So how does our implementation work? Well, a request comes in. If you're running in standalone mode, it'll come in through a web server. If you're running in servlet deployment mode, it'll come in through a J2EE server. And it's handed off to the WebObjects application server.

Request comes into the runtime and is sent to the WoWebServiceRequestHandler. This is similar, but not quite like all of the other request handlers you've seen, because instead of calling into specified WebObjects classes, it calls into Access. Access does a couple of things. First, it checks to see if there's a session associated with the SOAP request that's incoming. And if so, it goes to the WoSessionManager and pulls the session out and associates it with the incoming request. And then it figures out how to call your web service code.

How does it do that? Well, Axis takes the request. The Axis engine basically goes off and looks at its web service registry, which can be specified in a WSDD file or dynamically, to figure out which service is being invoked. It does this first by looking for the HTTP SOAP action header.

If it doesn't find a SOAP action header, it goes off and looks at the URL. If it can't find the information it's looking for in the URL, it will go actually parse and examine the body of the SOAP request to find the namespace in the application and match it up that way. That will give it the service.

We talked earlier about SOAP RPC and how the root element of the SOAP body is the name of the RPC method it's trying to invoke. So it takes that and figures out which provider it should use to invoke that service. The provider is something that basically knows how to take a SOAP service and a SOAP operation and convert that into a Java web service. a language method call.

Figures out what it's supposed to be calling and it calls it. This is the source code you have to write. And what you write can call anywhere you want to go. It can call off into EOF, it can call off into somewhere in the WebObjects stack. It can call back out of WebObjects if you're using your WebObjects application as a web service aggregator.

But once your processing has happened, you need to return something. Because this is WebObjects, we figure one of the major things you're likely to want to return is a WoE component. You can do this. The component gets returned to the provider that did the calling, and Axis tries to build a SOAP response. It does this by going off and looking at the type registry. The type registry basically contains mappings of classes to serializers. If it finds a mapping for the class of object you've returned, turns.

Type registry returns the serializer. In this case, it would be a WoE component serializer. Access then takes that serializer and asks it to serialize the component you've returned and stuffs the result of that serialization into the SOAP response and passes it back to the web service request handler.

Likewise, you can return any random object. We've just special-cased for components because they're useful. You can return any object. Again, the object is returned to the provider that did the method invocation. The provider asks the type registry for serializer. At this point, any serializer is returned. We have serializers for a number of the WebObjects classes you're likely to care about. We have serializers for NSMutableArray, NSDictionary, a bunch of stuff in WebObjects, or in WODGE. And we provide--this is the important one for most of you--a serializer for EO Enterprise objects.

Why do we have a serializer for each class rather than just one glorious serializer to end all serializers? What it comes down to is, it's a lot easier to control the information that you're passing in and out of your application. We could build the serializer to end all serializers, but the problem is you get everything, including stuff you may not actually want to expose to your customers.

And we figured it's relatively easy to write a serializer. We can provide packages that'll cover the basic classes you're probably going to be returning. And we don't want to force you or inflict trying to figure out how to change the XML produced by the serializer to end all serializers. So instead, we let you register individual serializers on a class-by-class basis and a service-by-service basis that let you do exactly what you want them to do. And again, The serialized XML is taken, stuck into a WoW response, and sent back out into the big wide world.

Back in Axis a little bit, before it sends the response back out, it basically checks to see if there's a session associated with the processing it's been doing. If there is, it stuffs a SOAP header with the WoW session ID into the SOAP response. And, well, this is the inverse of what it did on the other end.

The response to the Web Service Request Handler. At this point, there's a last chance if you want to do some kind of transformation on the data that's going to be returned. We have a hookup that allows you to register an XSLT spreadsheet, or XSLT transformation with a given web service. And at this point, if you have registered an XSLT transform, we'll run it. Then we stuff the results in a woe response and return the woe response.

So at this point, you might be asking, what a web services request looks like. Well, our PC services are pretty simple. It's any method, any parameter types, any return type. Something as simple as that. We've got a Hello World service. It's one class, say hello, you'll notice it's not a subclass of anything in the WebObjects universe. It doesn't have to be. It can be a subclass of, well, object in this case. It has one method, say hello, that returns a simple string. Again, you don't have to return any special type of object.

Document-style services are a little bit trickier. You have to do a lot more processing, and they have very specific interfaces. Document services, again, they can extend any class in the Java universe. But the methods that serve document services have very specific prototypes. They have to take one or more WC3 DOM elements, and they have to return a WC3 DOM element.

These elements are simply converted using the standard DOM mechanism into XML strings and stuffed into the response. Access doesn't try and figure out what you want to be doing, doesn't try and read your mind. It just says, "We trust you know what you're doing. We're sending this out." This implies that the request and response is better be well formatted.

Now you want to deploy these services. There's a couple ways to do this. Access provides a WSDD file, which is a web service deployment descriptor. It's fairly complicated, as all such things should be. Or we decided that we'd make it a little bit simpler and do dynamic deployment.

In your application constructor, you can simply call the WoWebServiceRegistrar, register web services for class, and enter the class--passes a parameter of the class name whose methods you want to expose. This particular method will expose all of the methods on the SayHello class. We actually provide methods that allow you to restrict which methods on your web service class are going to be exposed to.

The Web Services World. And on the note of dynamic deployment, we're going to pass this presentation off to Ron Luu-Saang, who's going to tell you all about direct-to-web services. Ron, around somewhere? Thank you. Thanks, Melissa. Hello, everyone. I am Ron Luu-Saang. I am an engineer with the Direct2Web and Direct2Java client team in WebObjects Engineering.

So, on the note of Direct2Web services, we're going to go over... Going to go over three things today. First, why we developed direct-to-web services in the first place. And then I'll talk a little bit about what direct-to-web services is. And then I'll go into how direct-to-web services works and try to explain how you can use it.

So first, why did we develop direct-to-web services? Well, a bunch of WebObjects engineers were sitting around one day, as we pretty much always do, and somebody brought up web services. And sure, it's a lot of hype, there's so much hype behind it, but we all agreed that web services is going to be a really big technology, so we should be there when it is big.

So some of us actually even agreed that web services might be a cool technology, and none of us thought that building a web services application would be easy. So we thought about it and thought, well, if web services are cool, and everyone knows EOF is cool, right, well, we could put the two together and develop something even cooler.

And being able to do that, though, making it a really compelling solution would mean that we'd have to make it easy for our developers to use. And part of our idea of how to make things easy for our developers is that our developers should write less code. And this is the same philosophy that's gone into a lot of innovative products in WebObjects.

This is the same philosophy we applied to HTML web page, HTML-type web applications using direct-to-web, where you can get up and running with a web application really quickly with very little code. And the same thing with Java Client, where we brought direct-to-Java Client to the three-tier distributed Java Client application space.

In the next version of WebObjects, we're going to do the same thing with WebObjects. We're going to do the same thing with WebServices, where we add direct-to-web services on top of the general web services support in WebObjects, making it really easy for developers to publish web services using EOF without writing much code.

And in being able to do this, we wanted developers to make useful business-type web services. And most of the really useful web services out there today, the 80% that we're trying to target, 80 to 90% we're trying to target, do things like searching of random data sources, like the Google example, or Barnes & Noble's web services.

Then of course there are also purchase order, invoice management-type web services, and general information update and information synchronization web services. Being able to do all these things very easily would be an important point for direct web services. And it happens that all of these operations map really well to things that we can do in EOF.

And another point to trying to make this easy. We wanted to make the--taking a look at the current equation for web services, it's pretty much do a lot of work and then get a little bit of functionality out of it for your web service. With direct-to-web services, we wanted to rearrange the equation a bit so that for a little bit of work, the minimum amount of work required to get an app running, you'd get a lot of functionality out of your business logic as a web service.

The two use cases that we saw as the common cases here were where you wanted to publish existing data as a web service, or you have a new WebObjects application or an existing WebObjects application that you want to add web services functionality to. And it should just be four steps. Pretty much for an existing data source, you reverse engineer it with EOModeler, our fantastic ER relationship diagramming tool. And add that model and any business logic you build around it to your application. Add a few frameworks that enable the direct web services technology.

And start your application and then configure it using our Web Services Assistant. It should be that easy. And even easier is if you've already built a WebObjects application and you just want to add some web services functionality to it. We just leveraged the existing business logic and model in your application. You add a few frameworks again, start your application, and then configure it.

So that's why we developed Direct-to-Web Services. We wanted to give developers the opportunity to build really meaningful web services very quickly without doing too much work. So then what is direct-to-web services? In truth, it's just a set of frameworks. It's a technology based on a set of frameworks and an assistant. The frameworks that we require for direct-to-web services are the Java Access Framework, which is just a wrapper around the Apache Access Jar that Melissa told you about earlier.

Then we have the Java Web Services Generation Framework, which not only has a lot of syllables, but is also where all of the magic for generating dynamic web services comes from. And then the two other frameworks there, Java Direct-to-Web and Java DTW Generation frameworks, hold the rule system that allows the web services generation piece to be fully dynamic.

So those are the frameworks of direct-to-web services, but we also offer an assistant, a swing-based application that you can use to configure and manage your direct-to-web services. And very important when you're building these applications, you can also test right in this assistant, making it very easy for you to get work done.

So in addition to offering the assistant, we also offer a lot of default functionality that you can customize. This is how we get you up and running really quickly with a web service. We offer a default web service, which is named a Wode default web service, and we also offer operations for each entity that you specify as a public entity.

When you say that an entity should be allowed to be vended as a web service out to the big world, we create an operation, four operations actually, for each of those entities. Insert, delete, search, and update the basic operations that you would want to do on any entity. Don't worry, they're not all enabled by default. You won't be able to just delete somebody else's entire database from a random web service.

And because you can configure everything very dynamically, we also offer generating WSDL for you, so you don't have to go through and muck with the WSDL for your service. We generate that dynamically. So with that, to show you kind of how this works, to give you a quick demo, I'd like to ask my lovely assistant Francois up on stage. He'll give you a quick demo of Direct Web Services.

So time changes. Two years ago, he was my lovely assistant. Still am, Francois. So he's grown wings on implemented crazy things that I get to demo. I think most of you have already seen the demo I did at the Developer Tools Conference presentation earlier this week. Anyone hasn't seen it? Okay, a few people, so it's worth going back. I'd like demo three, please.

Three. No, not yet. Three? Trois? No, it's three. It's really three. Okay, it's nine. Okay, so we've got a model. It's a model everyone has seen this week. It is... Are you still thinking about the hidden in the framework because there is a little bit of business logic associated with it? The Web is a real estate model.

Think about this as your private information that you don't want to show anyone. It reflects the database. You've got a lot of strings in there. Names for entities, names for attributes. You want to build an interface on top of this. Your web service will be the public interface on top of your model.

What the web service assistant will do is, around this house with tinted windows, is going to clear up a few windows and make a few things seeable, and paint some windows pink also, so that it looks rosy inside there. So I will create a new project from this model.

It's the usual WebObjects application wizard. Here's the JDBC adapter selected for us. It's fine. You can see in this list of frameworks that you've got the AXIS framework that Melissa was talking about earlier, or Ron, I think, and the direct web generation The reason we could come up with this technology so fast is because even though it's in alpha, the underneath has already seen years of exposure in the form of direct-to-web and direct-to-Java client. And I will add my real estate framework.

I know Ron has prepared me one. Where do you put it, Ron? "Favorite?" "Go to the build favorite." "Oh, build, okay. This one?" "Yeah." Okay, so if I click next, this product builder assistant is clever enough to find the model that is hidden in this framework. And it will, I can now build and launch the project.

It's going to take a little while. Oh Ron, I've got something for you. I brought a whistle in case I make any mistake. Ron Lue- Perfect. Preemptive. I don't know if I should blow this into the microphone. Okay, in the meantime, the app is ready. So here is the assistant. And the assistant is connecting remotely to the web services server that is now running.

And as Ron said, it comes up with a default service called WoDefaultService. This tree view on the left-hand side is a list of your services, and each service contains an operation. I can click on "New Operation" and now I have an operation in my default service. The more important thing to do is to decide which entities in my model I want to make public.

As usual, I'm going to make the listing entity public. It's the most interesting one in the model. Because it's in alpha, I've got to save, close, and reopen. That won't happen in the shipping product. And you see the default services that were created for me. Search, insert, listing, update listing, and delete listing. This is all nice, but most likely not what you actually want to do. So I can use that as a starting point and clone the search listing operation. Call it listings with bedrooms.

So, you see that on my operation panel I've got four tabs. One is for specifying the arguments this operation, this function is going to take. One for specifying the values that will be returned. One for specifying formatters associated with the arguments. and one for specifying in which services this operation should be executed.

You may want to have an admin service that contains all operations available, and then a user service that has a subset of these operations. And you can change an operation globally across services. Okay, so I'm going to edit my listing with bedrooms and do a search as the title says on bedrooms.

I will switch the operator to show you that it works. And return everything. That will be a good starting point. We've got a test interface up here, which is taking a while to come up. Here it is. It has a tab to show you a real-world WSDL file.

You see that you do not want to have to write this by hand. It's crazy. I don't understand it. A few people in your team do. Had to learn it, I'd say, reluctantly. I know we figured out to build it automatically for you, so hopefully you will not have to edit them. If I do a search on two bedrooms, I get back a set of enterprise objects, actually an array of them, three, four, five, six, seven, So this is not a fancy demo. You're not going to see a client. There are other sessions that will show you clients.

I just want to show you the functionality on how you can build services. You can actually do pretty fancy things already with this alpha version. For example, let's say I want to search to calculate some... I'm an agent and I want to see how much commission I can get if I sell all the houses I'm listing right now.

So I'm going to call it total... total what? Total... Total earnings. Total sales, because Okay, it's still based on the listing. And I actually cloned the listing for bedrooms, so I don't need the bedrooms. Here I'm going to use a plus operator. Ultimately, when all is done and said, and written, all the code is written, we will have a preview here where you can drill down relationships and access the attributes below.

For the moment, you have to enter the keypath. If you remember James Dempsey's song, these are the keypaths he was talking about. I can type here agent.lastname. That's a key path. I will search on the last name of the agent. And for return value, I don't want any of these. I actually want another key path.

So it's going to return me listings. I know each listing has an asking price. We've got this operator functionality on EOF where you can ask a few operations and it's actually extensible. You can add more operations in your business logic. For example, @sum is an operation, @average is another one. So here I'm going to sum the asking price of the listing return. And I'm going to change its name. As usual, it's a good idea to rename your public names so that you don't expose the names you don't want to expose. Your ugly gook.

Test. So it's creating the WSDL and creating a small client interface here. I will search for, I think Tony is in there, so T-Star will get me Tony Listings. And here it is, the sum of the... The total of what Tony could make in sales would be almost $3 million. I think he should Okay, so that will be it for this first demo, and I'll let Ron get the stage again.

Thanks Francois. I didn't even get to use the whistle. Curses. Okay. So, you can see that this whole thing of rules-based programming, you can see why it's such a good idea. We can get going with a real working application very quickly without writing any nasty code. It really jump starts your development, your application development cycle. And the coolest thing, of course, similar with direct-to-web and direct-to-Java client, your services here are synced with your business logic.

So then that's what direct-to-web services is. But how does it work? How does it do all of its magic? The magic is in the rule system. It's the same thing that you've heard of from direct-to-web and direct-to-Java client. It's really just an inference engine with a question-answer mechanism to it. All of the inferences are done based on rules that are held in rule files.

In general, you would ask the rule system a question, like, is the audience sleepy? Once you ask it that question, it looks through its rules and sees, oh, I can figure out the answer based on the time of day, so that if the time of day is in the afternoon, then yes, the audience is indeed sleepy.

And it's this kind of question-answer thing that happens all the time. You ask it questions, it gives you answers. And the cool thing is that the rule system can actually ask itself questions. So that in order to figure out what time of day it is, It can go ask itself, "Hmm, time of day." And one of the ways to get answers back from the rule system is through assignment classes. It's a special class, it's a direct-to-web class called an assignment. And you can actually put your own code there to put some funny logic for how to answer questions like the time of day. Like this, which I'm not sure actually works. But you get the idea.

So all the heuristics for direct web services live in these rules, in a set of predefined rules that come in the frameworks, and also in some rules files that are generated for you in your application by the web services assistant that Francois showed you. And so all this happens, all this magic happens, and you have code-free services, services where you've got actual usable web services without having to write any code. Messages are just passed through Axis and given to the rule system, and everything is handled there for you.

And as far as how everything works with a web service request, this is similar to the diagram that Melissa showed you earlier, where a request comes in and the Web Service Request Handler hands it off to Access. Access looks through its registry and figures out, "Oh, this is actually a direct-to-web service call.

I'll hand it off to our framework that does all the magic for direct-to-web services." And here we pull in a lot of information from your EO model, your business logic, and the rules files that I told you about. And we figure out what to do, whether to do an insert, a search, a delete, update, and on what attributes to do searches and perform all of these operations on. And we return an array of results. For instance, in a search, returning an array of listings.

Once we give that back to Axis, Axis then tries to serialize it and runs into a few of the EOs, for example. So the EO Enterprise objects get passed to an EO Enterprise object serializer, which knows how to serialize out objects fine, but gets hints about how to serialize the object by asking a serialization strategy for what attributes to serialize.

And similar to Java Web Services Generation, it knows what to do based on your rules file and your EO model and business logic. So the serialization strategy can tell the object serializer, the EO object serializer, to only serialize out the price and the agent name for a listing. This way you only expose the attributes of your EO that you want to. And then the serializer returns the serialized result, the serialized object, back to Axis, which hands it back to the WoW web service request handler and returns it to the client.

And as far as customizing this whole process, you saw that using rule models, rule files, and your EO model is the simplest way to customize this, the whole process. And this is similar to what we've done before in Direct-to-Web and Direct-to-Java Client, where you start off with the assistant to get all of the easy customizations done really quickly. And then if you want to do some tricky customization, you can go into the rules files themselves using Rule Editor and make custom rules or custom assignments.

And then if you run into a problem where you still want to use direct-to-web services and WebObjects, and you know there's just one little thing that you need to add, and the rule system can't take you there, you can freeze code. With code generation, you have to make sure that it's what you want to do, because it's kind of a pain to go back once you've frozen the code. Now, freezing operations starts off with the idea that operations are frozen across entire services. They live in one application server instance and are shared across services. So once you've frozen an operation, it's frozen for all services.

The WSDL for the operation is frozen as well. So you can get whatever chunks of the WSDL for that operation you need and plug it into, for instance, the dynamic WSDL that's used with direct-to-web services or in a separate service entirely that doesn't require direct-to-web services. The cool thing is, once you've frozen the operation, you can still manage the operation using Direct Web Services Assistant. You can't change any of the argument types and result types or anything like that. Those are frozen in the code that we generate for you. But you can still at least test and manage the operation with the Assistant.

And the coolest part is probably that you can actually rip out the code that we generate for you and have it do useful work in another WebObjects application that doesn't require direct web services at all. And to show you a little bit of this magic, I'll ask dear Francois back up on stage.

Okay, I'm back. One thing I forgot to show you earlier is this nice little tool that comes... I think it comes with Axis, right, Carl? It enables you to monitor what's happening on certain ports and to prove you that we are really carrying SOAP data around. Here is a request a client did. And you can see the SOAP envelope body saying agent.lastname, and the name of the function call being total sales. And here is a response that we returned.

Here, total sales response. And it's fairly big because we are still... Oh, here is a summer.

So I am going to attempt to freeze a service. Yes? Should I do it with a complicated one? Okay, let's freeze it. I'll call it Total Sales. Ooh, I want to open the right buckets in Project Builder to show you the magic happening there. At the same time, I click Freeze. The Java file was created for me. And I will make it bigger.

You have to do it in the preferences. Oh, in the preferences? Sorry. I'm not blind yet. I usually don't do that on my...

You see that it has a lot of static arrays passing the arguments that are now frozen, agent.lastname, passing the types of these arguments, the operator that we are applying to it.

Here you see the entity we are doing the operation on, and building a simple fetch spec, invoking a search on the editing context and returning the result. We also We supply a few convenience methods in a utility class that is generated at the same time. This class is common for all operations. Once it's there, it's not created again. And we build the portion of the WSDL that corresponds to the operation that was frozen. You can now take this piece of WSDL, add it to your handmade WSDL if you want to.

Let's say you want to do transaction-based services and you're going to want to do several operations in a row before actually committing to the database. Your assistance lets you create I believe a set of begin transaction-- maybe you can come help me-- a begin transaction call and end transaction call that lets you open a session. Once it creates a session, it will embed the session ID in the response of your first service. On the client side, you'll be responsible to embed the session ID back in your next request.

And as this goes on, when you reach the end-- when you do the last end transaction call, the session-- the editing context in the session will be retrieved and everything will be saved in the databases. The editing context and the database will be synchronized. That's done in the SOAP headers. In the SOAP headers. Should we just save that to Q&A, actually? Yes, because people will be able to hear your question better. Okay, so save all. Oops, one thing I wanted to do is to add possibly a log.

So I'm rebuilding and I added a log to make sure that it's actually my frozen component that is invoked and not the dynamic one. My frozen service that is invoked and not the dynamic one. If I now look at total sales, it is disabled, but I can still test it. Okay, now I will look for Andres. And you see here that the actual frozen service was invoked and not the dynamic one. And some results were returned.

Question, is it Melissa? You want to conclude on the clients? I've got a few more things to say. We're almost done. In addition to all this neat and nifty stuff we've got on the server side, we also provide a little bit of client-side stuff. Mostly we use Access. They have a fairly good dynamic client.

We provide a bit of a wrapper to make it a little bit cleaner and to make it a little bit more intuitive to do introspections so that you don't have to dig through the WSDL the way somebody using an Access client would. We provide serializers, as I mentioned earlier, and deserializers for the most used WebObjects classes.

The client that we provide has built-in session handling so that if you're using it with a WebObjects server, it manages your sessions for you as long as you're using the same instance of the client. And it uses HTTPS on the client side if you want to use a secure connection to a WebObjects application.

Which brings us to web services and security. Currently, the state of the art for web service security is to use HTTPS. This is a really undefined area. Some of you may notice, know that last month Microsoft and IBM got together and came up with the WS Security specification. We'll probably try and do something along that front, provide some kind of support for it. Don't quote me on that because, like, well, this is forward-looking and we may run into problems when they change the spec in another month and a half.

We'll also track some of the emerging standards that are going to be built on top of WS Security and see if we can do something along those lines for you. But right now, like I said, state of the art is HTTPS. There's no authentication, really. It's just nobody can snoop. So in summary, you can create web services and WebObjects by leveraging your existing WebObjects applications. You can consume web services using our client-side frameworks. And direct web services rocks.

There's some resources that you'll probably get these slides off the web next week. Here's some resources that you might find useful if you're interested in web services. There's Apache.org, WC3.org, where you can find WSDL and SOAP specs, UDDI.org, where you can find more than you've ever wanted to know about UDDI, Webservices.org, which is a Microsoft-sponsored website that contains a lot of information about what is new and interesting in the web services world, and xmethods.org, which is a place you can go to find information about a lot of the web services that are currently sort of being served on the web. You've all heard about our lab at this point, I'm assuming. We have one downstairs. Here's the hours.

Roadmap. Some of the other sessions you might be interested in if you're interested in web services, there... I guess one was yesterday, so you'll have to get the DVD for Client Web Services Frameworks. There was a Java Web Services one this morning that's not in the roadmap. If you're interested in doing server-side stuff, you're probably interested in performance, so there's Session 407 Java Performance, which is running in Hall C on Friday.

And for those of you who are interested in rules-based programming, here next is going to be a direct-to-Java client presentation, and of course there's the feedback forum on Friday. The Who to Contact, Tony, Bob, our consulting arm, which is named Dilbert for reasons I really don't want to speculate on.

and places to get more information. The developer documentation is online. You can access our professional tech support online. There's a list of other places. You can subscribe to WebObjects announce. We have some documentation forthcoming, a book on developing web services and data serialization using XML that should help those of you who need to build stuff in this space.

There's a lot of these buffer slides on the end of this presentation. How to get the documentation? It's in PDF and HTML forms on the web. You can get print-on-demand. Some of it comes with a product CD. Some of it's in the box. And you can check the ADC News for the latest updates. And now we'll do Q&A.