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 slash 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 Web Objects 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 web objects. 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 web objects and help you go in a direction that a lot of people seem to be wanting to go.

This session's going to introduce basic web services technologies, and I'm going to talk about using web objects to produce, 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 basic grasp of how to vend a web service using web objects, 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.

not to talk about any web services tech any web objects 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 dot net which is microsoft century in 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 it 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 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. eyes. 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 listserv 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, that 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 out did root elements the soap body is the name other so per quest that you're trying to pass and its 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. And 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. 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 also appears-- 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 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-- is Google search results. 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. Tells us all we could possibly know about that type. Google search result is essentially a structure, structured data type containing all of the following elements. 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. Oh, 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 red histories where various businesses can go and enter information about the business about the service this web services it's offering all kinds of stuff or company can run a private registry that contains information only about the business partners they actually deal with you d_i_ 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 web objects, whys and hows. Why do we have web services in web objects? 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. I mean, 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 Woe 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 Axis, think Apache Axis, not EO Axis. Axis 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 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 WSDL 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 name of the first element, the root element of the SOAP body is the name of the RPC method that 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 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 WebObject 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 well component. You can do this. 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, Type registry returns the serializer. In this case, it would be a Wo 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 Wudge. 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 sort of 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 serializers 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 woe 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 woe-session ID into the SOAP response. And, well, this is the inverse of what it did on the other end. And then it returns... 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. All right. 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. It 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. Thank you.

Now you want to deploy these services. There's a couple ways to do this. Access provides a WSDL 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 Lue-Sang, who's going to tell you all about direct-to-web services. Ron, around somewhere? Thanks, Melissa. Hello, everyone. I am Ron Lue-Sang. I'm an engineer with the Direct-to-Web and Direct-to-Java client team in Web Objects Engineering. So on the note of Direct-to-Web services, we're going to go over... going to go over three things today first why we develop direct web services in the first place men are talk a little bit about what direct web services is and then i'll go into how direct web services works in tracks when 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. Thank you. 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 web services, where we add direct-to-web services on top of the general web services support and web objects, 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, uh... and general information updated 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 these operations map really well two things that we can do it you left stuff.

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 where you wanted to publish existing data as a web service or you have a new web objects application or existing web objects 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 EO Modeler, 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-to-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 leverage the existing business logic and model in your application you had 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 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 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. Thank you. 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. Thank you.

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 WoW 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 how this works give you a quick demo i'd like to ask my lovely assistant francois up on stage they'll give you a quick demo of direct web services So time changes. Two years ago, he was my lovely assistant. Still am, Fred. He's grown wings and implemented crazy things that I get to demo. Thank you.

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? OK, a few people, so it's worth going back. I'd like demo three, please. Three. 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... Uh... he'd done in the framework because there is a little bit of business logic associated to it it's a real estate model so 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, it's 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.

We have added a wizard for building web services. it's a usual web object application result here's the JDBC adapter selected for us, it's fine you can see in this list of frameworks that you've got the access framework that Melissa was talking about earlier or Ron I think and the direct web generation framework and so on so the reason we could come up with this technology so fast is because even though it's in alpha the underneath is already 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?

Cover it. Go to the build favorite. Oh, build, okay. This one? Yeah. Okay. OK, 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. Oron, I've got something for you. I brought a whistle in case I make any mistake. Perfect. preempted i don't know if i should blow this into the mic 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. - Magic.

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 uh... 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 four matters associated with the argument.

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. Thank you. 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 the test interface which is taking a while to come up 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.

no we figured out to build it automatically for you so hopefully you will not have to wait if i do a search on two bedrooms i get back a set enterprise object actually an array of them So this is not a fancy demo. You're not going to see your clients.

There are other sessions that will show you clients. I just want to show you the functionality on how you can build services. Thank you. you can actually do pretty fancy things already with this uh... alpha version for example let's say i want to search to calculate some uh... 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 earnings. Total sales because OK, 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 because these operator functionality on uh... u_f_ where you can a few operationally it's actually extensible you cannot not more operationally business for the for example at some is an operation at averages another one so here are going to some yes in price of the distant listing return and i'm going to change its name As usual, it's a good idea to rename your public names that you don't expose the names you don't want to expose. Your ugly gook.

test so it's creating a WSDL and creating a small client interface here I will search for, I think Tony is in there so T* will get me Tony's listings. And here it is, the sum of the-- the total of what Tony could make in sales would be almost three million dollars. I think he should change jobs. OK, so that will be it for this first demo. And I'll let Ron get the stage again.

thanks for its law didn't even get to use the whistle so you can see that this whole thing of rules-based program you can see why it's such a good idea we can get going with a real working application very quickly without writing any any nasty code they really jump starts your development your application development cycle and the coolest thing of course similar to with direct web and direct to job a client So then that's what direct 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. So... 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, 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 Access and given to the rule system, and everything is handled there for you. Thank 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. Thanks.

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 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 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 web services and web objects, 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 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 uh... 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. Thank you. okay i'm back uh... one thing i forgot to show you earlier is this uh... nice little tool that comes uh... i think it comes back to the right cup 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 agent dot last name and the name of the function called being total sales and here is a response we returned here total sales response it's fairly big because we are still oh here is a summer variable that we are returning that was computed for us. Okay? So we are not cheating. This is real SOAP data.

so i'm i am going to attempt to free the service so that i do it was a complicated one Thank you. okay let's freeze it, I'll call it total sales 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? i'm not blind yet i usually don't do that on my uh... from fit okay so it's a fairly them uh... 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 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 supplier a few convenience method in the 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 and add it to your handmade WSDL if you want to Thank you. session management so for the session let's say you want to uh... do transaction based services and your uh... you're going to want to who several operation in a row operations in a row before actually committing to the that that is your uh... assistance that you create i believe uh... some a set of uh... begin transaction maybe you can come help me of a big in transaction call and uh... and transaction call that lets you open a session once it creates a session it will embed the session i_d_ in the response of your first service on the client side you'll be responsible to embed the session i_d_ 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. Thank you. summary building on a i had a lot to make sure that it's actually my frozen component that is involved another dynamic one by frozen that didn't work on the the If I now look at total sales, it is disabled. But I can still test it.

okay no i wouldn't look for you see here that the actual frozen service was involved and not the dynamic one and some result for return 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 wisdom 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 provides... 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 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 web objects by leveraging your existing web objects 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. - Yeah. 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 on 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 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. Developer documentation is online. You can access our professional tech support online. There's a list of other places. You can subscribe to WebObjects and Ounce. 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. Thank you.