---
title: WWDC2001 Session 611
framework: wwdc
role: article
path: wwdc/wwdc2001-611
---

# WWDC2001 Session 611

## Transcript

Kind: captions Language: en hi my name is Carl Hsu I am a web objects engineer and just before we begin I'd like to tell you that I don't have any jokes I'm not funny I don't sing I really can't play the guitar but I am Canadian so welcome to session 611 this is deploying web objects applications and this is really an introduction to deploying a web objects application we'll give a little overview of how the deployment architecture of web objects is structured we'll talk about things that you can configure in your deployment we'll talk about some system monitoring tools we'll go over a typical deployment and then we'll do Q&A a so this is the typical deployment architecture for web objects we start with a browser which could be a web browser or a java client or something along those lines and it makes a TCP request to an HTTP server a web server that's known as the presentation layer okay the web server then forwards the request to your application your application is the heart of web objects it's your web objects application it's what Ben's dynamic web pages back to the client it's where all your logic is that's your application layer the application is dynamic and it serves data it does things with data so usually it talks to a database using UF that is the database layer one thing to remember is that when you deploy resources are split between the web server and the application itself so why do we do this okay the first thing is that we want to make public resources available easily things like images sounds client-side Java that sort of thing and you want to make those available because it's faster to serve them through the web server than it is to go through the web server to your app and have your app serve it your app should be only should only be spending time on what it does best your business logic the web server should be doing what it does best which is serving basically static objects out so all the other things that your app has the executable itself server-side Java files which for web objects 5 is everything pretty much components the EO model file all that stuff should be private it shouldn't be accessible directly to a client ok and you want to do this for a number of things again security is probably the most obvious one so that if somebody doesn't accidentally get ahold of your yo model or something along those lines if the web server is badly configured and this is known as a split install because you take the resources you divide them into public and private and you install them in two different places so let's talk about deployment configurations what are the supported deployment platforms for web objects Mac OS 10 server the new one Windows 2000 Solaris 2.8 Mac OS 10 server comes with a Java runtime 1.3 Windows 2000 Solaris 2.8 we require that a JRE of 1.3 or higher already be installed what sort of hardware should you run on what kind of processor how fast how many how much memory how much disk space whether you have more than one machine where is the server located network how fast is it how secure is it what about the physical security of your machines what about the temperature of the room the machines are in UPS's that's particularly important if you're in California software it's important to know what kind of account your applications will be running on you could run them all with this route this may not be a good idea to let your you know to have unrestricted access to your filesystem and the rest of everything what about application logging you're deploying an application you need to be able to figure out what's wrong if something breaks what about access control who has access to the application who's allowed to configure things these are all things that you really want to think about so we're going to talk about what can we control the areas that we're going to talk about today and it's this deployment dependent and typically the things that you can tweak or control are the web objects adapter the application itself and the database well tweaking the database is really something that's an entire profession unto itself so we're really not going to go into that here we're gonna talk about the web objects adapter and the application so what is the web objects adapter we saw the deployment architecture from before and the web objects adapter is what Ford's the request from the web server to your application what does it do for you why do you want to do this rather than just having a client connect directly to your application it gives you better performance it lets you load balance it between multiple instances and it provides other things such as pooled connections etc it validates client requests a nice thing about the adapters is that it can do some things with cookies to help you validate sessions it can also validate that it's a well-formed request so that your application doesn't have to deal with badly formed requests that may be designed specifically to crash the app or even accidentally and it's more secure not giving people direct access to your applications makes things a little bit nicer for system administrators it also separates things out so that the only contact that people have with the outside world happens to be your web server so there are two types of web objects applicate web objects adapters the CGI adapter common gateway interface and the API adapters which are plug-in modules why would you want to use one of the other CGI works anywhere all of our supported platforms probably on some that aren't but it's slow every time a client makes a request you have to fork a new process and it doesn't support load balancing on some platforms windows in particular VAP on the adapters are plugins we have plug-ins for Apache ans API which is for netscape's I planet and is API which is for Microsoft Internet Information server they're fast but they can only be used with those specific web servers and only on specific platforms their major advantage is that all of the API modules support load balancing and we'll talk about load balancing in just a second all of the web objects adapters are written in C we provide the source code so that you can modify them you can adapt them you can tweak them if you make them better tell us and hopefully we'll incorporate the changes which adaptors do we support if you can see on all three of our supported platforms CGI works with pretty much everything on OS we support oh I'm sorry this is slides been modified so on OS 10 we only support Apache we do not support NS API on Solaris we support Apache and NS API on Windows 2000 we support NS API and is API so just in case y'all are taking notes we do not support NS API on OS 10 so let's go back to an earlier slide what's load balancing I talked about it this is really a performance thing this is a big performance win for you in your applications what it does is it distributes client requests between multiple instances of your application why would you want to do this because even though you're slowing down a little bit the actual transit time because you to pass the request through in any immediate your app is doing all the work your app is doing all of your logic it's dealing with the EOS it may be doing enormous amounts of work against the database and so even though the the cost of passing requests to the application and back from the application is negligible so the idea is to have more applications you can have multiple machines with multiple applications running on them they do all the work and all the adapter does is pass requests between them because of the way that web objects deals with sessions we only load balanced requests that don't have a session once you have a session you're typically assigned to a particular instance running on a particular machine and you'll stay there until the session is gone there are three types of load balancing there's random and in random the adapter basically for a new request just picks and arbitrary instance round-robin where the adapter will pick the instances in the sequence if you had three instances it would go one two three one two three are you feeling sleepy yet load average tries to pick the instance that has the least number of sessions there's it's a slightly tweaked heuristic but essentially that's what it boils down to let's take a look at the adapter overview what happens specifically well the browser makes a request the web server will pass it to the web objects adapter and the web objects adapter will look at the status request line the URL that the browser requested and in this case we see look it's requesting the application killer app okay and if you can see killer app dot Walla / - the - indicates that we're looking at instance two we probably have an existing session on that so the adapter has a sort of a map and it says killer app - it's tied is located on the host Quaglia and it's running on tcp/ip port 4000 - so it's found that it then forwards the request to your application the application will process the request returned the response to the adapter the adapter hands it back up to the web server the web server hands it off to your client and we're off the adapter site configuration so I alluded to a mapping that's the adapter site configuration and what it is is it Maps an application number name and an instance ID to the application server and the tcp/ip port that that instance happens to be running on so I'll just give you the examples from before killer app 1 running on the host Quaglia port 4001 the site configuration also has some additional information what kind of load balancing you should use for this particular application the number of persistent connections to make to that application tcp/ip sockets that sort of thing there are three ways that the adapter gets this configuration information the first way is from a flat file basically it'll just read a file off of the disk the second way is a host list it'll get dynamic data about application instances from a series of hosts that known hosts that you pass it and multicast which is sort of a broadcast mechanism for discovering what hosts are available we'll go through these one by one in just a second the configurations for these are updated every 10 seconds so every 10 seconds the adapter will check to make sure that instances haven't left or new instances haven't been added or new applications whatever so let's look at flat file flat file is in an XML format and the DTD that defines it is in the documentation it's also I believe in the adapter source code that we provide so we give an example and it's pretty simple I mean we have an application named killer app it's being scheduled using round robin and it has one instance with an ID of 1 running on qualia port 4001 host list configuration so again this requests dynamic configuration information from a list of hosts the information is normally supplied by something called the web objects task daemon or boat asti for short this will caste daemon runs on each application server or a host the information that will tast e supplies to the adapter upon request is in the same XML format that the flat file requested the flat file file uses and the reason you want to do this is because it allows for really easy dynamic addition of application instances on a set of known hosts this is also the default mechanism that the adapters use the adapters are pointed at the local host by default so you'll see 1085 come up probably 1085 is the port that what asti is running on by default and that's where the adapter requests information that's the port that the audacity will return information on so we'll take a quick look at how this works what has T is running on the two hosts Quaglia and ploy cout four instances are started and they register with low caste so that what asti knows that they're running in the meantime the adapter has this pre-configured host list to look at these two hosts and what it'll do is it'll send a request to the two hosts and ask them for configuration information and from that it'll generate its site config what it does is it actually will merge the xml returned by the various Matassa T's into a complete list so let's talk about multicast really quick multicast is kind of interesting what we do is we broadcast a UDP packet a request to a specific IP address and a TCP IP port we broadcast it to a multicast address and what that address does is it sends it by default to every machine on your subnet you can configure routers to pass it beyond that but in general that's how routers are configured by default to stop the packets at the subnet and what happens is all the low caste that are running and listening for that broadcast will respond this allows us to dynamically build a list of hosts once you have the list configuration proceeds exactly like host list did and we look we do this broadcast about once every 100 seconds because we don't really want to be doing this all the time so how does multicast work same thing we had before we had the two hosts with what a sneeze running on them and the web objects adapter pre-configured to look or rather to send on that multicast address applications start and register with what asti the web objects adapter will then broadcast get the responses from quale employ cout and build our dynamic host list and finally it does what it did in hosts list which is to send the request directly to the known hosts get back the reply and generate the Sai config so I alluded again to the web objects Testament boot asti let's talk about this really quick what has T is a web objects daemon that started at boot time on Mac OS 10 and Solaris and at login time on Windows 2000 it's watched over by another daemon process so that if what has T dies it should be restarted and that way if what asti dies you don't suddenly lose an entire host and nobody can connect to it and its major job is to supply the adapter with that xml dynamic configuration data and again it does this on port 1085 by default to do this it registers running instances on the same machine the other thing that it's allowed to do is that it will monitor and cycle and restart configured instances on that machine so how do we get it to do all this well what asset e is configured using an application called Java Monitor Java monitor is a web objects application and its major purpose is to provide it a web interface for what a steam you can use it to configure individual application instances or entire applications you can use it to manage multiple hosts you can use it to configure the web objects adapter and finally you use it to set up scheduling for instances Java monitor can be password protected but is not by default and it has a new interface in web objects 5 before we gone I wanted to mention something about instance scheduling the idea behind instance scheduling is that a scheduled instance is restarted periodically by what asti so after a certain period of time wood has tea will tell an instance that it should shut down and when it has it'll start start up a new instance of it you want to do this in case you're expecting to bring them down so that you can put up a new drop of the instance if you have known memory leaks anything along those lines new in web objects 5 is that each instance can be scheduled independently rather than grouping and scheduling by an application so we have three types of scheduling we have hourly where you can reboot the application every X number of hours 2 hours 4 hours daily where an application will get rebooted every day in a particular time and weekly where an application will be rebooted every week in a particular time and we can terminate instances immediately where it'll just exit or gracefully where we set something called refused new sessions and what will happen is that instance will stop accepting new user requests but will continue processing existing user requests once all of the existing users are finished then it allows it and start over this is nice because you don't kick users off the plateau off of their session so let's take a look at Java monitor and I'd like to ask Josh Behnke to come up and do a demo [Applause] so he's not wired with the mic so he doesn't joke or sing or dance either alright so this is the first screen that you should be presented with when you start java monitor and because we're gonna use it later on let's go to the site tab and what we're gonna do is set the URL for the adapter and we're really doing this this doesn't actually choose which adapter you're using you can have one or many adapters and you can switch them on the fly to point to different instances but this is what we use to generate URLs all right so let's add the host so in this case the webserver and Java monitor are running on the same host and we'll add this host if you can see we have three different types of hosts Mac OS 10 Windows and UNIX you can choose the type of host that that happens to be and we'll add it one of the things that's useful for debugging for seeing what's going on if you're having trouble is under available it's now a hyperlink so if you click on yes you get a bunch of information about that particular host you have the site configuration as it's written to disk the adapter configuration as it's being sent back to the adapters by request and all the way at the bottom you just have some information about what what asti thinks is going on all right so let's add an application we're gonna add an application hello world ok we're gonna name it hello this doesn't this name in monitor doesn't need to match the name of your application proper the this is so that you can have multiple sets of an applications scheduled independently through the adapter so we're gonna get the path to the application and we'll use the path wizard here we select a host and then we navigate it's in developer examples Java web objects leave hello world hello world whoa whoa one thing to note there's some confusion in the past you have to select the executable inside of the watch just selecting the woma isn't good enough all right one thing we're going to do is turn off to recover autorecover is the setting that says to monitor if this application instance dies restart it automatically don't wait for me to tell you or anything just started as soon as you can and we're going to turn that off because we're going to do something with the demo later so let's go to the detail view and this is the page where you will actually end up doing most of your monitoring we're going to add two instances to the hosts that we've just added okay and we'll start them so this page by default refreshes every 60 seconds you can either turn that off or you can set it to a different number depending on how you want it to go and you can start and stop instances independently as a group you can turn on and off auto recover independently as a group same thing with refused new sessions and you can turn off and on scheduling from here as well once the application is running we show some basic statistics number of transactions number of active sessions some timing statistics we also keep track of how many times the application is died so that you know when it's dydz because if you have auto recover on you may just look at it and be oh my application is still there but it might have died every ten minutes for the last hour the whoa stats link is basically a link to the applications view of its own statistics they're fairly detailed okay so if we refresh the page hopefully the instances are alive at this point in the are so the hello at the top is a link through the web server adapter to those instances as we can see we have hello world alright we've already split installed hello world into the web server document root so we get images and that sort of thing normally you would either copy them in manually or you could I believe you can modify project builders so that it'll install them for you okay excuse me so what we're gonna do now is we're gonna show you about multicast the web server right now is configured by default it only looks at the localhost all right and we can actually prove this Josh if you could go to the wou adapter info page okay so this is the what would after info page and what it is is a view into the state of the adapter at the moment we have links to existing applications as well as information and if you see this line we're only looking at we've only got that one host that we're looking at we also have a bunch of configuration information about the adapter itself so what we're gonna do is we're gonna go back and we're gonna add a second host and that's our second demo machine and then we'll go and we'll add two instances to that host so what will happen at this point is we've added this host but the host that we've added isn't on the known list of hosts that the adapter knows about and what will happen is even though these instances are there the adapter won't see them and we'll fix that using multicast so let's refresh and see okay so you see that the adapter really doesn't know about them monitor if you refresh should know about them there you go so you the applications are running the adapter doesn't see it so what we're gonna do is we're going to stop the webserver and edit the configuration file and we're going to change it from looking at the localhost only to doing a multicast broadcast okay and we'll start the adapter back up and we'll see what we get and there we go so all four applications are now showing and what you can do at this point is just keep adding hosts on the subnet the adapter will just keep picking up hosts and picking up whatever instances happen to be running on those at the same time so one of the things we're gonna do is show we're just gonna show shutting down an instance and watching the adapter pick that up so let's shut down instance one give it a few seconds refresh sometimes the timings not quite right so that monitor knows that it's dead and it happened immediately we refreshed that means that the adapter knows about it immediately but what happens if an application crashes if an application dies so Josh can we go to the command line and kill whatever our most recent thing happens to be okay so this gives me a chance to segue into life beats how does the what have see on a particular machine know then an instance is alive well the instance sends life beats tcp/ip life beats to load a ste and it tells it I'm alive I'm still here it does it about every 30 seconds and what happens is when you shut down an instance you either terminate it internally by calling terminate or you send a shutdown through monitor the instance knows it's going to shut down so it sends a special life beat to loot asti that says I'm shutting down right now if it doesn't what asti has to wait until it's decided that the instance really isn't alive because it hasn't responded for some period of time so in the meantime what we'll do is we'll take a look at failover we can try to connect to instance two which is what we just killed directly and you click on it and somehow we've come up with hello world even though we've killed it but there's actually something interesting going on if we type in a name and we hit enter and you can see that we're actually on instance three we're not on instance two anymore so the adapter tries to be smart about it if your instance if the instance you specifically request it is dead you'll move to a different instance I believe the XML sessions showed that if you have a persistent session story you can do some really interesting fallback failover mechanisms with that so we refresh the monitor page okay so monitor has decided that it's dead and at this point the adapter should be able to pick it up and it's also dead okay so that was just a quick demo of monitor and what Asti and how to do a very very basic deployment we go back to slides so the adapter info page is actually really important the adapter info page is accessed the same way you would normally access a web objects application but instead you use the application name low adapter info this is really good it provides a lot of information about how the adapter happens to be configured you can see which hosts it's looking at which instances it knows about what the settings for various timeout options are set to it provides links direct links for all of those available instances and that's really useful if you have an instance started and you don't know where it is that adapter info page will tell you it's disabled by default for security reasons we had it enabled during the demo you can either password protect it or you can have it for public access during the demo we had it for public access what will happen is in fact any unknown name application name will cause it to come up we don't suggest you deploy like that but it's useful for development the other thing for looking into how the adapter is working is adapter logging you create a file named log web objects spelled just like that in the temp directory of your system so C colon backslash temp I think on Windows or slash temp on UNIX systems and what will happen is long file named web.xml to it logging is slow and so what we do is we allow you to start and stop it without restarting the web server you can have your web server and the adapter running and you just create the file in a few seconds later we'll start logging to it when you delete log web objects will stop logging to it okay so now we're moving on we've talked about the adapter and how it gets its configuration we're going to talk about configuring instances so those of you who went to the moving for two web objects five session know that instead of the defaults database which we used to have we now do configuration using standard Java util properties and very roughly from our point of view we see the properties file from all your included frameworks the properties file from your application itself and then command-line arguments in that order of precedence so the properties file is named properties and it's located in the resources directory of your boa or your framework and it's in pretty standard Java format you multiple lines each line is key equal value you can also pass command-line arguments and those are passed this dash D property name equal property value again we also support the old method of passing arguments to web objects which is the - whoa debugging enabled space yes or true and that works as well but is deprecated so what are some useful deployment properties for configuring an application we have well port will host whoa debugging enabled will output path will cache enabled we'll listen queue size will allows concurrent request handling will work our thread count min and Max some of these are new some of these are old so what port forces the application to listen on a specific tcp/ip port if you don't set it it'll just ask the system to choose one which is why you typically get if you start an application from the command line you get ports that are like fifty seven thousand something woah host is new and you pass it either an IP address or a host name that has dns resolution and what it'll do is bind that application to a specific IP a specific interface this is really useful if you have a host that happens to have multiple IP addresses you have to two Ethernet cards in a machine one pointing one direction and one pointing the other direction and you can't figure out why your application happens to bind to the wrong one and no one can see it this is what you would use you would bind to a particular address and all the requests will forward to that one if you don't we just default to grabbing the first host name that we find this isn't necessarily consistent it sort of depends on the Java platform there's some support for logging now so though it's whoa debugging enabled and you turn on and off basic web objects logging there's also I think a Oh adapter debug enabled and some other stuff really C NS log for details it's best that you can customize this for your particular application by enabling or disabling specific debugging groups and it's specific debugging little levels in any case what we provide now is whoa output path whoa output path redirects all of your debugging output from NS log to a particular file normally we dump it all to standard out in standard error this lets you this lets you set up instances in monitor and have the output redirected to independent files rather than having them all mashed into well used to be mashed into the wrote a steal output and now in Java doesn't go anywhere so now we're on to performance properties low caching enables this tells the web objects application whether or not it should cache the web objects components in memory basically the dot whoa files by default for deployment installs it's true and it's false for development so in development you should be able to tweak HTML and the next time you hit that page it'll show up for deployment for speed reasons we don't check every time the listen queue size is the number of outstanding requests at any given time so your application may end up having a lot of long running Quest's all at once and it doesn't have any resources available to process new requests when that happens things start piling up in the server socket and the bolus and queue size lets you set how many connections we allow to sort of wait to get accepted whoa allows concurrent request handling is a little touchy what it does is determine whether or not requests are processed in serial so by default we will read requests from sockets and write responses out to sockets in parallel we can have dozens or hundreds of threads doing that at once but all the requests are processed one after another and the reason we do this is because it's safer in order to do in order if you set this to true your all of your code all of the code that you access and call must be thread safe if not bad things will happen so the last thing is what worker thread count-- man and will worker thread count Max and this is just the number of threads well worker thread count is the number of threads that we use to process incoming requests we start at 16 we default to grow to 256 you can allow to grow infinitely for those of you who familiar with four five or four or five one we've changed this a little bit the number of threads used to be set we try to take advantage of Java's heavy threading model and rather than pooling threads we simply have a number of them waiting and accept which if anybody went to the Java performance session works really well alright so what are potential bottlenecks that we should you should look at when you're doing a deployment the application logic itself could be a bottleneck you could be doing something amazingly stupid sorting of 40,000 element array using bubble sort you could be using the wrong database wondering why despite the fact that you have hundreds of connections doing you know dozens of megabytes worth of transaction processing why isn't it working until somebody points out that you're using the flat file adapter what kind of CPU well hey we're running say my big honking story calm on a cellar sometimes it's not a good idea you own a big CPU if you can get it you want more because of the threading the heavy threading that we have now them will take as much advantage of multiple CPUs as you can reasonably get do you have enough memory please swapping is bad I'm sure you've heard this but really swapping is really bad ok Network you want a fast Network in particular I mean you can't really control the network to your clients because that's up to them but you can control how big of a pipe you've got between your application server and your web server and you really want that to be big we make a lot of assumptions that you have an essentially unlimited pipe between the two because you should alright so if you're interested you should see optimizing web objects applications I think that's coming up on Friday and they'll talk about specifically how to look at your application itself so let's talk about the system's then so how do I tell how much memory or CPU I'm using on Mac OS 10 there's the CPU monitor there's the process viewer and vmstat the image that's a command line thing it'll tell you basically how you're paging how many pages you've got free how many swapped out locality or that sort of thing CPU monitor tells you how much CPU you're using in process viewer lets you view processes so Solaris says PS and top PS is basically a process listing and top will give you sort of an overview of how your system is behaving at the particular time Windows has the task manager which sort of does a number of different things it's both the process viewer and a CPU monitor as well network monitoring tools Mac os10 has the network utility lets you do things like net stat and ping and that sort of thing Solaris says the net stat directly at the command line and Windows as a Network Monitor driver for its networking stack all of these basically try to let you see what sockets are open on your system are we are they doing good do we have too many open and then you have packet sniffers give them in hardware you have them in software and they basically let you actually look at exactly what's going across the wire between you and clients between the app server and the web server and sometimes you find out really interesting things so this is going to be covered in optimizing but I wanted to touch on it really quick application monitoring tools we're now in pure Java and one of the big big advantages of being in pure Java is that we can now use third-party tools you can use je probe optimize it optimize it is now available on Mac OS 10 the job of performance team uses it and that's really great Objective C sort of had this problem of looking into the code we have any number of profilers things that will instrument all sorts of stuff now you have external load generators we ship with playback manager and the playback client and they basically just you record a set of actions and it'll play it back silk performer is a third party product that does something very similar these are good for determining your actual real world performance it can say how many requests hit your application and see this is really good for seeing specifically what's going on how does the application perform overall rather than at a very small detailed level and finally the web objects frameworks themselves provide some sort of feedback there's the whoa event stuff which will be gone over in detail and optimizing web objects and the most stats page which you can access from monitor and that'll give you statistics on which components were called the average transaction time for that particular component how long did it take that sort of thing so let's take a quick look at a typical deployment and the thing I remember is we're going to try to show that all the deployment principles are the same it doesn't matter whether you're a small home-based application going over a DSL a mid-sized small business app going over part of a t1 or ISDN or a large enterprise app going over multiple T ones all the deployment principles are the same web objects doesn't really distinguish between them and systems monitoring doesn't really change so we start with a very simple deployment you have a small number of applications they go to your web server Mathilda in this case and they pass requests to quality which is talking to a database cabby so one of the things we start by doing is adding a little bit of security so that people don't have free access to your web server we add a firewall we only allow requests to Matilda 80 to pass through but then the number of clients grows and we do some monitoring and we discover that it's actually the web server that's at fault this time it's unusual but it does happen so we add a second web server and we round robin DNS them so that requests get passed between the various web servers and they all talk to the same set of instances we do a little bit more monitoring the number of as the number of clients grows and we discover all right so our web servers are holding up pretty well now our bottleneck happens to be the application the application we don't have enough instances so we add a second instance or sorry two more instances on another host and a lot of people will do this at this point it may be worth it to set up another firewall so that requests between the web server and the application instances also have to pass through a firewall and that's also for security so finally maybe the database all the way at the end is what your final bottleneck is and you may have a Mara database so that you can get data out faster so it's important to note that what these firewalls that we've set up as we've grown in this particular deployment is it separates us there's the intranet zone all the way on one side or the internet zone and that's totally insecure people can do whatever they want on the other end we have our completely private network and this is where all of your value is all of your data all of your logic everything important to you is on the far right and we have sort of like a DMZ border zone in between and again this is why that split install that split of public and private resources is important so that the only things in that border zone aren't that important they're just public stuff the things that people should be able to get anyway so that's pretty much an overview of how web objects deployment works you can have multiple instances and potentially multiple application servers and you have a web objects adapter and the web objects adapter passes requests to the ER instances and it can do that in a number of different ways the instances will process and return it we have a number of mechanisms available for you to tweak and we provide tools so that you can deploy and hopefully have a nice deployment and that's it okay thank you so the web objects lab is still open it's open from actually when this session started to 6:00 p.m. today and tomorrow for some limited hours so be warned about the limited hours don't wait until 4 o'clock tomorrow because it's not gonna be able then we have a road map and it may seem a little strange that we want you to go to the java performance because even though that was yesterday but you should all be getting DVDs this year sooner and when you do that's certainly something to look up to because try to take advantage of the language try to take advantage of all the work that's being done on the job of EMS optimizing web objects applications specifically is tomorrow at 2:00 and then of course if you have any comments or questions about deployment or anything else please come to the feedback forum on Friday this is I'm sure you've seen this slide before this is who to contact Tony Bob I services URLs you