WWDC2003 Session 624

Transcript

Kind: captions Language: en good morning everybody hope you guys had a nice lunch a good nap or a session depending on how awake you were and hey that wasn't a joke so we're going to talk about web objects and creating web services this is session 624 if any of the above sounded wrong you're probably in the wrong room alright as our nice friendly voice of God introduced me I'm Carl sue i work in webobjects engineering and i'll be doing the first half of this presentation the second half the presentation will be done by my compatriot rondo sang he's the friendly Jamaican Chinese guy so we have to have the obligatory what you will learn in this session slide because they told us all right so web services we're going to talk very briefly about what a web service is in our case when we talk about web services we're going with a stricter definition I mean technically web services is anything where you invoke services over the web but we're going to specifically talk about the standards based web services that webobjects provides and uses we'll talk a little bit about practical applications of web services why you would use web services in lieu of just a regular HTTP connect or korbo or anything else like that then finally we get to the meat of the matter we'll talk about web objects and web services what objects is a server web objects is the client and finally about the crown jewels for web services in web objects direct to web services hopefully that will be a relief to those of you who have been going to the web object sessions and not actually hearing a whole lot about what object so in a single sentence what our web services web services are remote procedure calls for the Internet era and their xml-based the goal I think in that one sentence was to hit as many little buzz words as you possibly can it'll sound great to managers IT people it's fantastic there are a bunch of standards in specs in the official web services sphere there is description of the web service in wsdl which the web services description language there's discovery of a web service how you find what web services exist and how do you find the information about them and that's the uddi which answers something I can't remember Universal discovery definition and interface or interrogation something like that nobody calls it that nobody remembers what it's called everybody just says uddi so when you hear that buzz word floating around you know what it is ah that's discovery the encoding of the web service itself when you send XML back and forth you have to agree on a particular way that the XML will look that's soap the simple object access protocol and finally the transport when you send the XML and receive it you have to do it over something over the wire or whatever and those very that's probably the most flexible part about the whole thing but the two most common the two that are defined in the spec itself are HTTP and smtp web bob jects in particular mostly deals with HTTP so let's go over a little bit over the parts of a web service when people talk about a web service they typically talk about three major parts there's the wisdom and the wisdom the wsdl is a contract it defines everything about your web service you can sort of think about it as the interface to a class when you publish a web service you publish the Wizzle to it and that's what the client uses to know how to talk to the web service there are a number of tools out there that can also use the wisdom to generate stub classes and and so on and so forth the service itself consists of a set of operations and invocation information it's the again in an analogy to the class itself it can hold state or whatever you needed to do the operations exist within a service so that's something to keep in mind a single service can have multiple operations it's sort of a grouping because the service exists at a certain point it exerts exists at a certain URL and then you can invoke multiple operations at that point those are analogous to methods let's take a quick look at the wisdom the web services definition language it's also defined in XML and it basically defines everything you need to invoke a web service it's the structure of the web service itself it defines data types that are used in the web services not only the standard set of data types in strings dictionaries whatnot but also custom data types that you may have for your web service yo global IDs whatever it defines message types requests responses error messages anything that you might send what you're supposed to send and what you might get back it talks about the available operations on that web service what can you do with it can I add something can I you know invoke a particular method that will return some status whatever it's all in there it defines where that service is actually located the URL or address that you would invoke that web service at and finally it talks about the transport bindings most of the time for web objects insecure that will be HTTP ok let's talk a bit about soap it's the simple object access protocol this is basically the protocol when you send the XML across the wire you can think of this a little bit like the meta schema for what you're actually going to send across it defines the language in which you will define your web service ok it's split it splits up the message layout itself so each soap envelope will then have a header in which you can stuff ancillary information about the the web service itself in a particular invocation for instance it might include routing information or session based information and then the body itself which is where the bulk of the data that's going back and forth across the wire is kept the souks standard defines several transport protocol HTTP and smtp but it leaves it open for plug-in they're not tied to a particular protocol you could conceivably write a web service that required somebody to write down the XML on a piece of paper run to your neighbor's house and give it to them and run back it wouldn't be very effective but it would technically be with things back just to show you just because it's a spec doesn't mean that it works it's not you know a lot like statistics it supports synchronous and asynchronous mode you can do the standard sort of HTTP way you send a response the service it does whatever it's doing and then it sends you the record I'm sorry you send a request I'm sorry I'm not worthy you send a request it gets processed and it sends a response there are also asynchronous modes in which you know the server may pull a client for a request or for data and so on and so forth an interesting thing at this point is that there are two major styles of web service there's an RPC style of web service and there's a document style of web service most people I think would like to be using an RPC style the RPC style is invoked very much like a remote procedure call that would be our PC you invoke a method you pass arguments in a particular order and you get back a response document Styles a little bit more flexible but it's also more annoying it's more work you essentially say I'm going to send you XML soup in some privately defined format you meup with it and send me back more XML in a privately defined format and we'll kind of negotiate it there this actually negation agates a large point of web services which is easy negotiation and easy understanding of what you're actually sending and receiving so this is a really quick example I mean you can sort of see if I wanted to find an RPC service it's very analogous to a class and a method you receive optional arguments you return something in in the case of a document service you just get basically in our case you would get a dom tree and you would have to return something very similar so problem solved by web services the major bonus of web service is that it's very clean information transfer there are a number of services out there Watson for instance where at least initially I'm not sure about now the whole point was that it would screen scrape it would hit a website get back the HTML and it would have to then parse its way through the HTML looking just for the information that you're looking for that's bad because it means but it means that if they decide to change the look of the site if they say you know what we're going to do something nice we're going to put an ad here we're going to move this search field around or something like that you're totally bored right and sites change all the time part of the point is that you know the display is fluid it also means that it doesn't dictate any sort of display or usage you can expose the information you expose the service and the client can do whatever they want for it they can present it directly back to the user they can aggregate it they can they could do whatever you want another important thing is that its implementation dependent the spec tries to be as clean as possible so that the server doesn't have to know anything at all about the clients and this is what really separates it in large part from custom solutions things where you just agree on a private format between you and the client in this case you don't need to know anything about the client if you're the server or vice versa it tries to be fluid in a way that the spec tries to income pass pretty much anything so you can have webobjects written in Java running on Mac os10 talking to pearl running on Linux or C sharp running in a.net cause the dotnet client on a Windows machine and you don't have to know what that is as long as you can talk the web services talk it goes back and forth and everybody's happy and finally one of the reasons it was created this way is that its firewall friendly unlike older iterations of things like carbon such you don't have to open up any funny pork you don't have to do anything interesting to make your system administrator really unhappy you basically punch a hole you know you no longer have to punch a hole through anything you can just route it right through your web servers a way that you would normally and because it fits that well that well onto this distorted internet standard it makes things much easier to use the best part about it though is that it's human readable this is actually isn't a very complicated thing I think the best description that I've ever heard of this is the fact that the soap XML is human readable does not actually guarantee that it is readable by humans so you could in fact it could conceivably encrypt it or something like that it doesn't really matter I mean the goal is that you wouldn't actually have to look at it one of the goals of things like web services is that the XML is well defined XML is well understood the soap spec that defines how the XML is structured is well understood and it becomes very easy for you to write tools so that machines can talk to machine it doesn't it it's built written in XML it's done in XML so that there are a number of tools available to read and write it not so that you can actually do this by hand please if you do though it would be really interesting to hear about it okay hold on a second it should be obvious by now participants in a web service you have a server and you have a client often they're called a provider and a consumer it's just a different name for it shouldn't have to worry about it theoretically what ends up happening is the server will write the web service they then register with some sort of universal directory and then they publish the wsdl set to in a way that's described in the directory so you would go to the directory and you would look up i want web services that do let's say something really lame add two numbers together and you would get a list of urls for contact information and whizzed alok ations for those services then you could hit those services take a look at the wisdom that came back run your client automation thing and now you can talk finally of course the server has to provide the web service itself the client does the opposite it has to look up the web service in a directory it will then configure itself using the wsdl and it can invoke the web service the configuration using wsdl can be either dynamic or static there are a number of tools out there that will generate stubs web objects the default implementation for what objects doesn't do that in fact it just retrieved it wisdom and then tries to be sort of nice about it very quickly we'll go over this this is a little bit more specific this sort of is looking at the web service event flow from a web objects point of view and I'm not going to talk about the client side because it's essentially a mirror image of what happens on the server so the client sends its wsdl request the server returns the wsdl to the client the client will then I mean this can happen offline you can cash the wsdl we can keep in a file use it to generate stubs or whatever that happens could happen right before the request and have the client dynamically do something to generate the the proper soap request sometimes it happens or much earlier so now the client sends a soap request the server gets it as XML in web objects we unmarked the XML into a set of objects native types we process it we marshal the response back into XML and we return the response to the client again it's very simple so let's begin talking about what objects and web services webobjects uses access for its engine to do web service it's the apache extensible interaction system I don't know why it's called that because it doesn't seem to have anything to do with what it actually does it's written by the Apache group it's open source it has support for both the client and the server and it has automatic wsdl generation we basically stuffed it directly in web objects does do some nice stuff for you it has plugins for both session support and custom serialization and deserialization of objects in particular all the basic objects that web objects is likely to use all of our NS collection classes and the EOS themselves and of course on top of the access engine we wrote in our coup de Gras the director web services and we'll talk about that later actually he'll talk about that later so things that we do to you specifically the DC realises that we have our four NS array data dictionary range time zone Enterprise objects and global I be in a web objects application and on the client they are automatically registered for you we also provide wisda for these we also provide this is actually one thing that we do that should be really nice it's session support we have the custom session handlers installed on both the client and the server side one major lack in the soap 11 spec is that it doesn't talk at all about transaction semantics there's no way to carry on a conversation about web services when they define the suspect they sort of assumed that each web service would be nice and sort of self-contained that the answer from one invitation would have nothing to do with the request of another one we felt this was a major lack particularly when we were trying to deal with databases so what we added was we extended the session support in what objects to support sessions through web services so that you can invoke a web service and habits and stores that server-side state can anybody else say that three times fast I can't so it's okay the other thing we add and this is pretty minor is just dynamic registration access is configured typically through a set of XML files and we typically don't like to do that so we provided the low web service registrar it's a single call that you can use to register a web service okay so really quickly I'm just going to run through the demo so we have a demo server and you can see session test services the name of my service the service class itself is not terribly complicated it's called state test what I'm going to do is it gets the current session oh sorry then we remember ought to change the font on this thing preferences text editing in touch coloring oh here we go sorry about that please forgive me I know not what I do ah there we go all right this is about a simple of a services you can get we get the current context the web objects context we get the session and in our session we just store an array of strings basically so that as we send each time we add to that list and finally the application here's that single line that I was talking about to register I've actually registered the session under a different name session test just to see you know it's doable okay the client is going to be a little bit simple what the client is going to do is it's just going to be a front end is going to be a web app webobjects application with the text field you're going to add in type in a string hit enter and as a response we're going to send back the list of previously submitted strings this is obviously a very trivial application okay so web service client we can get the web service client so on and so forth alright so let's run these suckers one thing to keep in mind at this point is that the client because what i want to do is I want to show you what's happening on the client through something called TCP monitor just to prove that we're actually going across and so you can see what the what the state looks like I've actually stored the wisdom locally on the machine and it looks like this ok you can see here state test response state test return it returns an array the request takes a string the name of the service is the session test service the operation is named state test and it takes a string which turns the response which takes a request returns a response those are the message types that I was talking about alright so let's hook this up and let's hope the network is kind to us and it is okay and here so our first request is this one sorry if the fonts still too small for this you can see it's a very simple one you have the soap envelope itself which defines all of the namespaces you have the body and the string itself encoded on the way back again the envelope here's where the session support comes in we start sending the session we send the information in the header you can see that we have the session ID for those of you who are familiar with webbed objects in the instance ID in our case at this point since we're running directly there's no instance ID at all so we return if you walk through the rest of them the same request you can see that we're simply returning an array ok back to slice all right talk a little bit about the client really quick it's basically a very thin convenience convenience API on top of axis while on the server side we added director web services we didn't add anything quite that complex on top of the client side the custom DC realises and sterilizers are available they're registered the session support is registered for security you can do HTTPS on the client side to connect using the standard Java API going forward talking about security currently the current state of the art for web services security in terms of secure connections is pretty much just HTTPS that's fine it works pretty well there is an industry standard ws-security it's been basically Microsoft IBM all the big people are behind it web bob jects doesn't support that at this point unfortunately we do provide a security delegate that will get invoked at pretty much every single phase before the response is sent after the responses sent before and after marshaling so that any at any point you can hook in and ask webobjects to do whatever needs to be done and finally so I'd like to introduce ron was saying he's our Jamaican Chinese webobjects engineering cowboy ki ha Mon see humma come on come on come on mon on you know the your hats out of date it's already obsolete yeah it's panther time now i can only find a panther colored cowboy hat so thanks Carl now that Carl's told us everything we need to know about web services and how webobjects leverages access to support web services I'll just take the next 20 minutes or so and tell you about our kick-ass technology director web services so let's see actually goes to black first so I'll just talk a little bit about three things three things basically first what is it that direct web services is trying to address what problem is are trying to address and also what technologies went into director web services and then I'll give you a cool demo about that has a web objects application talking to a cocoa desktop application via web services so what problem is it that direct web services solved basically we in the web objects department believe that our developers write too much code and by that I mean they write too much application specific code they should really be we want our developers to have simple lives and simply work on fine-tuning their business logic so to that end we've come up with these rapid development technologies and if you're familiar with director web or direct to Java client then you're probably familiar with the rule system that we have in web objects with director web services we've extended that and added to it the axis and webobjects support for web services and also our fantastic enterprise objects framework and wrap that in the rule system that we have if you haven't heard of our rule system it's basically a question-and-answer system that lets you infer values from a set of rules and some contextual info that way you can have a really dynamic application where a set of rules instead of lots of code defines your application behavior so the problem that we're trying to solve is most sure it's right now you can build a web objects application pretty easily that will vend your business logic as a web service using access web objects and eof but you still have to write some code and usually that code does one of four things create read update or delete a bunch of rows from your database typically called the crud operations so we'd rather have our developers skip doing all that crud and leave the work to us so that's what director web services tries to solve keeping you guys productive working on your business logic and leaving the crud behind so ya know all right and so then on to what technologies went into director web services so Carl's already told you about axis which does all the heavy lifting of silk messaging for us he's also told you about how webobjects ad session support and of course all the load balancing that you expect from web objects as an application server so between access and web objects we already have a great way to talk web services then on the low end we also have the enterprise objects framework for which we believe is the best way for accessing and modifying interacting with business data in your jndi or JDBC data sources so and of course again wrapping all of this in the smarts that is the rule system we put together our kick-ass crown jewel technology director web services so I'm just going to go to the demo now we get demo two please cool just going to start a new project just like all of our direct to star projects we have a project template called director web services and we'll give it a cool name and we'll add a business logic framework that I've already built all right navigational problems sorry okay and we'll just go ahead and build and launch the application so along with the project templates we also have assistance every director web application director Java client applications and now also direct to web services have assistant applications that you use to configure the rules for your applications as a first step for for specifying behavior of your application so while that's starting up see so it'll bring up a little web browser which isn't entirely useful for weds objects for a web services application but it tells you that it tells you you should really put this URL in the web services assistant which I'll do here so now the assistant is going to connect to our application and it can already look at all the models that are in our application as you can see here and it can also see all of the services that are already published by default we have an aptly named service the whoa default web service at already set up for us we'll go ahead and enable it and we'll make one of these entities public and over here you can see the service is already populated by default every time we add an entity by we add few operations that do all those crud all the crud work I talked about earlier specifically inserting searching updating deleting and we also look through the vet specifications for your model so we find things like my name fetch sophistication yeah that's specification for find user and login user just so you can see what I'm talking about here so let's let's just give it a try we'll do a search for users and we only want to have to specify somebody's first name and I want all the first names to be case-insensitive like and we can also change the return values so that we return so we don't return some random person's passkey we just get their address first name and last name and I want to change the public name for the operation the return type so that it's a user name so this is an important thing right now we're exposing your business logic as a web service so clients can go and examine the Wizzle that's generated from the service and you don't want them to necessarily have a really good idea of how your data is modeled so you can change the names to be something less sketchy for public consumption so now we'll test the cept this operation and we'll send the changes that we've made in the assistant back to the server and it will be updated in the rule system there so now we can look for all users with the first name starting with our poof we do get one user some of this text may be a little hard to read but you'll see that there's a key value coding null value here don't worry about that what's actually happening is we're sending back a serialized EO without the pass key as you saw me configure earlier on the client side here because this is also using libel objects technology we can actually create a real EO on the client side but it doesn't have the acute the passkey set yet so if we don't want to see these values in our in our client or especially if our client is in a web object application we can go ahead and turn on returning soap struct this makes it a little bit cleaner for non with objects clients alternatively it makes it a little less efficient for web objects clients so there's a trade-off there actually let's go ahead and add messages as a public operation you can see we've created some operations there and let's go ahead and turn on the insert message operation we don't want clients to automatically create the creation date for the messages that they're inserting so we'll take that out we'll just say we need a subject a recipient to send it to buy a dress and let's add the sender's address and a message and then for return values we don't really need to return anything just insert it and be done with it and will enable the operation turn on soaps trucks returning just for the heck of it and let's try this out okay forgot to change this because we've gone and reverse engineered kind of the fetch specification in my model I actually choose the names for the key value bindings in the model which are not very kosher as far as web services names go so I'll go ahead and change these as well and so you notice there we can actually do a little bit of validation for you to make sure that you're not going to end up publishing a Wizzle that isn't valid so again let's go back and test the insert message operation let's take a look at the Wizzle for this service the entire service just for fun this is the sort of thing that we don't want you guys to have to worry about this is precisely the sort of thing that direct Web Services handles for you will dynamically figure out what parameters you set as input and output parameters and merge those into a Wizzle for your service let's say hello to Karl from me wait for it Carl okay and we get an exception so what's happened here is it claims that the creation date is yeah so we got an exception so now we know that we need to start debugging our app all right yes I believe this was expected but this isn't the exception I expect so in any case I can move on to starting up an application that I no work no we have a mess server message server rather gone ahead and turned off whoa Otto open and browser and set the port I'll also add a couple of rules to our role model file oh this part i want to emphasize for editing rules in your application please add a new file and name it d2w model file like I've named it here so you'll get this edit this file do not edit the user BTW model file which is edited by the assistant for you there are two separate files you should edit the dtw model file with rural editor so what i'm going to do is change the location that my web service application claims it's running on i have it actually running on port 8888 but through this rule the service location URL which is a rule for we're like how we publish the wisdom we can change where clients will go to invoke our web service and the reason that i'm going to do that so I can show you all of the cool XML that goes back and forth through TCP monitor okay so but clean build and run and we'll go back to the assistant connect we'll still connect through 8888 we could connect through 7777 but then you'd get a little bit more gobbledygook alright and here we can search for all of our users okay so one of the things that I've already gone and done is change the return type for arrays you can change how things get serialize doubt simply by adding a call to the low web service registrar what I've done is make the XML that we return simpler and more cocoa web services friendly that's why the client here didn't like it so heck let's see so I'm going to add this to one of the download sites after this conference so you can actually try this code out basically we tell it that if we're serializing out an array should see realize it out with the you are type instead of as soap enkore so we can dynamically change how things are serialized and deserialize as well as which serializers get used and another thing we can change thanks to our dynamic deployment stuff we can change how the response is encoded as far as the entire silk message one of the things I'm going to do in order to make this more friendly for cocoa web services is add my cocoa response handler here into the response chain I do that by by copying this line into the response bit here what this handler does it's simple simple piece of code that runs through the soap element that we return to the client and make sure that the the return name for each element is just returned so stopped up and run it again and I'll bring up my cocoa application and hide some of this stuff we cool okay so i have a few classes in here that were generated by WS make stubs which is located in flash developer tools which takes a bunch of wisdom and generate some objective c or applescript or one other i believe just CF code that lets it that lets you invoke the web service really easily you don't have to write as much of this stuff i'm going to make sure that i use a valid name and it please and i'll build and run this so here our server is running so we'll hide that will get rid of this basically what the what this cocoa application will do one of the things that can do is log in to log into our web service using a just a simple name and password and find a global ID this global ID then you can pass back as a key sort of to other web services indications similarly you could conceivably return a session ID or something else like that that lets the up the following operation in vacations do something more intelligent kind of contextual information so here's my app and I'll do is I'll check my email there's nothing there it's fine let me try sending Carl a message hmm let's take a look at the important debugging tool tcp monitor oh I've done something very silly and not included this is my bill target yeah so we'll give this one more try and that definitely seems to have worked let me check first okay so here we've gone across let me check again so you don't miss it and sent a clear text name and password don't do this and replied with a bunch of messages that are encoded for specifically for cocoa you could do this for any other client net has worked we could do this for regular applescript clients as well see and if I send myself a message you can see that we first log in finding the name or finding the name of the recipient here and getting it getting the global ID this is an encoding of the global ID so that we can use it later when we send the actual message so this is a two parts two-step process for for this specific web service here you can see we've sent a global ID for the recipient and defender and I can check my mail again and see that we indeed did get the message one of the other things that Carl alluded to was session support and how that enables transactions for director web services and web objects web services in general you'll notice when I check the service panel here we have a little check box for allows transactions or not with that enabled we can go and check any of these and look in the wisdom there will be two extra three extra operations begin and commit and rollback transaction operations this way a web service client can explicitly ask for session state to be kept on the server for the remaining transactions once they initiate a begin transaction operation sending simply begin transaction to the server we keep the session of lives reply with some session headers in the soap message which the client hangs on to simply forwarding those message headers to the server will awakens the correct session for the client so you can do things like keeping a bunch of changes in the editing context on the server going keep making changes without committing them to the database until a commit transaction is sent so that's and I think that was 00 as far as extending the frameworks here how much time doing okay extending the framework you can see we have all the default services and default operations you can also create your own you can see you can create a new service and change its name as well as creating a new operation for it we bring up a new operation dialog name the operation and define which entity it works with all of these changes are saved in the rule system so that simply by invoking a operation by name web objects will automatically know what entity the operation is meant for and whether it should be inserting or deleting or updating new records in in the editing context so we can add a search user operation named have fun change the parameters and this play will play with any of these settings until we get it just right at which point we might want to actually make some small tweaks into how it's working at that point we can actually freeze the operation this generates real source code we can name the operation source and then we go and generate the source for you for everything that you would need for actually doing what is done by default and we also generate a static liz'll page that you can edit so we've generated a lot of code and it does the same thing boring next I'd like to simply I'd rather just subclass the existing operations and only tweak the little things that I need rather than having to manage a set of source if I really needed it this would be useful but in my case I typically just want to change the return object by one little amount so instead of freezing an operation I can create a new operation here name it a simple subclass and same settings and you'll notice that once we froze the previous operation we can no longer edit any of these arguments and return values so you have to get it right before you freeze it it can unfreeze but you still have to throw out your original source when we subclass you'll see we still get the dynamic system here in order to configure arguments and return types now subclassing involves one little thing there is a template that ships with web objects and it lives in developer documentation webobjects web services templates blah i'm going to simply copy that with this cute little script pirate yeah i'm going to copy that into developer project builder extras file templates webobjects just read the directions doesn't read me here so now that I've copied that template there I can go and create a new director web service operation subclass will name it and you can see now we have something much simpler than this but it does pretty much the same thing all you need to do is tell is tell the or define your operation to subclass one of our other operation types search or insert or delete operation this one is going to be a search service search operation and here i can print out a little extra debug information one of the things that we get when we r invoked when an operation is invoked is a set of input part values these are the values that the client has actually sent to the server and will also have to register this service this operation with the rule system the way we do that is editing again the d2w BTW model file and we'll say when the operation name that's invoked is say hello don't ask me where i come up with these names i don't know either then the operation class that should be invoked is my happy happy class and a very similar rule needs to be used in order to tell the rule system that it is a dynamic operation well I didn't need to do that copy paste is a wonderful thing okay so operation class name is set it is operation for frozen is set to false save stop and build and then we can go back to the assistant disconnect wait for the application to warm up again and then once we've connected we can start configuring this neil operation that you'll see there so in my simple service we can actually rename this to say hello and you can see we can still edit the arguments return types and which services associated with whereas the frozen one is still just frozen we'll go ahead and add subject and a recipient as input parameters and change fees and the creation date and the sender so lots of little parameters oh I have to make these public another security feature reminding you that you must make these things public before anybody can invoke them okay so we can at least set the subject will probably get an exception saying that we don't have the serializer for the response type but here you can see on the server side that we didn't get in fact get some input part values that we can flux with before invoking super so this way we still don't have to do all of the work of actually inserting or searching or deleting or whatever we can just tune little parameters of the operation to suit our needs and with that I'd like to go back to the slide so that's it direct web services web services made easy based on the axis and webobjects support for web services using eof so that you don't have to write any of the crud code and using the rule system to define the parameters and the behavior of your application with that I'd like to bring Carl back up stuff yep another demo but I did that one there we go thank you Ron so running a little short on time that's ok let's talk really quick there are some deployment considerations when you're deploying web services through web objects he talked about a little bit about session support and load balancing we do support multiple instances of webobjects vending web services and then load balancing between them the key to that though is that the load balancing is based on cookie support the client we basically send which instance you should be talking to back as an HTTP cookies so the client has to be able to understand that and bend it back to us properly otherwise the whole transaction session thing breaks down entirely so that's one thing to keep in mind the Wiz the location you generally want to simply publish your single wisdom it's nice that we dynamically generate it and it means it's easy to change but it's probably best if you simply put it up on a web server and then reference it directly from there it probably shouldn't change all that often because a lot of people do things like generate stubs off of it so if you change it you will break the client finally we talked about registration uddi was designed to be this sort of analog to DNS or the phone book we're all sorts of web services operations would register in this gigantic directory that was you know all over the world and everybody would look up stuff there so far it hasn't really caught on it may beginning to build a little bit of momentum it's in the j2ee 1.4 spec and so on but it's still not this giant phonebook thing that the original authors had intended in lieu of that a lot of companies use web services internally and in in order to publish their web services they either have an internal uddi server there are a number of free uddi servers out there or they do something simple like the web page or something like the way ex.message would do it or just word of mouth you send an email out saying hey guys I published a web service the way Stoke it is available at blah so web services in two words even less than the one sentence internet RPC it has lots and lots and lots of acronyms hopefully you know a little bit more about them now but that's okay the goal for us of course was that you know much of that could be skipped that we would try to do as much of that as possible for you they would like it to be located and registered in a uddi server and because we're talking about standards we're kind of going to go in that direction it's described by the by the wsdl it sent a soap encoded XML over HTTP or smtp snail mail carrier pigeon whatever hey don't knock the carrier pigeons they were very efficient and cheap you try laying a t1 line versus getting a bird so webobjects itself at a very fundamental layer very basically adds transactions and type support and that's good that's helpful the big thing for us is that we add directed web services and this is something I really want to stress web director Web Services provides you with automatic comprehensive and very easy to configure web services for your entire database right you no longer have to do go through and figure out what you need to write how do i access this how do i you expose it you basically point direct web services at your database bring up the assistant do a little bit of clicking and pointing and checking and unchecking and you can expose your entire database with transaction support it looks transparent to people they can say let's start a transaction add some stuff modify some things set up some relationship when you're done check if everything is in a good state if so commit if not roll it back it's beautiful I believe actually that it's even better than something like director web when you build something like director web you're generating a UI and then you have to tweak the UI so it looks good so it fits in with your site and everything else like that with director web services it's just the information your throughout your database is exposed directly it can be used by multiple clients it can be used by clients you've never heard of in languages you don't know or don't recognize can't read right it's that easy and it's something that we would really really like people to take advantage of