My name is Karl Hsu. I am a WebObjects 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 WebObjects Applications.

And this is really an introduction to deploying a WebObjects application. We'll give a little overview of how the deployment architecture of WebObjects 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.

So this is the typical deployment architecture for WebObjects. 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. The web server then forwards the request to your application. Your application is the heart of WebObjects. It's your WebObjects application. It's what bends 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, 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? The first thing is that we want to make public resources available easily.

Things like images, sounds, client-side Java jars, 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 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 WebObjects 5 is everything, pretty much, components, the EOMODO file, all that stuff, should be private. It shouldn't be accessible directly to a client. 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 a hold of your EO 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 in the 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 WebObjects? Mac OS X Server, the new one, Windows 2000, Solaris 2.8. Mac OS X Server comes with a Java Runtime 1.3. Windows 2000 and 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? UPSs, 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 always as root. This may not be a good idea to have unrestricted access to your file system 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 this is deployment. So deployment-dependent, and typically the things that you can tweak or control, are the WebObjects 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 going to talk about the WebObjects adapter and the application. So what is the WebObjects adapter? We saw the deployment architecture from before, and the WebObjects adapter is what forwards the request 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 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 WebObjects adapters. There's the CGI adapter, Common Gateway Interface, and the API adapters, which are plug-in modules. Why would you want to use one or 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.

The API adapters are plugins. We have plugins for Apache, NSAPI, which is for Netscape's iPlanet, and ISAPI, which is for Microsoft's 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 WebObjects 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 adapters do we support? If you can see, on all three of our supported platforms, CGI works with pretty much everything. On OS X, we support Apache. We do not support NSAPI. On Solaris, we support Apache and NSAPI. On Windows 2000, we support NSAPI and ISAPI.

So, just in case you all are taking notes, we do not support NSAPI on OS X. 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 and 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 have to pass the request through an intermediary, 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 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 WebObjects deals with sessions, we only load balance 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 an arbitrary instance.

Round robin, where the adapter will pick the instances in sequence. If you had three instances, it would go one, two, three, one, two, three, are you feeling sleepy yet? LoadAverage tries to pick the instance that has the least number of sessions. 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? The browser makes a request. The web server will pass it to the WebObjects adapter, and the WebObjects 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 KillerApp.

and if you can see killerapp.wola/2. The 2 indicates that we're looking at instance 2. We probably have an existing session on that. So the adapter has a sort of a map, and it says KillerApp2 is located on the host qualia, and it's running on TCP/IP port 4002. So, it's found that. It then forwards the request to your application. The application will process the request, return 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. KiloRap1 running on the host Qualia 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 socket options, 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, 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 I'll give an example, and it's pretty simple. I mean, we have an application named KillerApp. It's being scheduled using RoundRobin, 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 WebObjects Task Daemon, or WOTASTI for short. This Wotasty daemon runs on each application server or a host. The information that Wotasty supplies to the adapter upon request is in the same XML format that 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 Wotasty is running on by default. And that's where the adapter requests information. That's the port that the Wotacity will return information on. So we'll take a quick look at how this works. Wattacity is running on the two hosts, Qualia and Ploiku. Four instances are started and they register with Wotasty so that Wotasty 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 Wotastis 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 WOTASTIs 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 hundred 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 Wotacities running on them, and the WebObjects adapter preconfigured to look, or rather to send on that multicast address. Applications start and register with Wotacity. The WebObjects adapter will then broadcast, get the responses from Qualium Ploiku, and build our dynamic host list. And finally, it does what it did in Hostless, which is to send the request directly to the known hosts, get back the reply, and generate the site config.

So I alluded again to the WebObjects task daemon, Wotasty. Let's talk about this really quick. Wotasty is a WebObjects daemon that started at boot time on Mac OS X and Solaris and at login time on Windows 2000. It's watched over by another daemon process so that if Wotasty dies, it should be restarted. And that way, if Wotasty 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, Wotasty is configured using an application called Java Monitor. Java Monitor is a WebObjects application, and its major purpose is to provide a web interface for Wotasty.

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 WebObjects adapter. And finally, you can 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 WebObjects 5.

Before we go on, I wanted to mention something about instance scheduling. The idea behind instance scheduling is that a scheduled instance is restarted periodically by Wotasty. So, after a certain period of time, what has to be will tell an instance that it should shut down, and when it has, it'll 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 WebObjects 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, two hours, four hours. Daily, where an application will get rebooted every day at a particular time. And weekly, where an application will be rebooted every week at a particular time.

And we can terminate instances immediately where it'll just exit, or gracefully where we set something called refuse 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'll exit and start over. This is nice because you don't kick users 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.

So he's not wired with a mic, so he doesn't joke or sing or dance either. All right, so this is the first screen that you should be presented with when you start Java Monitor. And because we're going to use it later on, let's go to the site tab.

And what we're going to 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 web server 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 X, 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 with 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 Wotasty thinks is going on. So let's add an application. We're going to add an application, Hello World.

So we're going to 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 WebObjects, leave Hello World.

Hello World, WOA. One thing to note, there's some confusion in the past, you have to select the executable inside of the WOA. Just selecting the WOA isn't good enough. All right. One thing we're going to do is turn off auto-recover. Auto-recover 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 start it 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'll actually end up doing most of your monitoring. We're going to add two instances to the host that we've just added. 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 refuse 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 has died so that you know when it's died 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 10 minutes for the last hour." The Woe Stats link is basically a link to the application's view of its own statistics. They're fairly detailed. Okay, so if we refresh the page, hopefully the instances are alive at this point. And they are. So the "Hello" at the top is a link through the web server adapter to those instances.

So what we're going to do now is we're going to show you about multicast. The web server right now is configured by default. It only looks at the local host. All right. And we can actually prove this. Josh, if you could go to the WoW Adapter info page.

Okay, so this is the WoW Adapter 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 going to do is we're going to go back and we're going to 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'll 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 the applications are running, the adapter doesn't see it. So what we're going to do is we're going to stop the web server. and edit the configuration file. We're going to change it from looking at the local host only to doing a multicast broadcast.

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 going to do is show-- we're just going to 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 timing's not quite right. So, that monitor knows that it's dead and it happened immediately. We refresh, 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? So this gives me a chance to segue into lifebeats. How does the Wotasty on a particular machine know that an instance is alive? Well, the instance sends lifebeats, TCP/IP lifebeats to Wotasty, 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 lifebeat to Wotasty that says, "I'm shutting down right now."

There's actually something interesting going on.

If we type in a name, 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 the instance you've specifically requested is dead, you'll move to a different instance. I believe the XML sessions showed that if you have a persistent session store, 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 Wotasty and how to do a very, very basic deployment. Can 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 WebObjects application, but instead you use the application name, WoW 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 logWebObjects, spelled just like that, in the temp directory of your system. So, C:\temp, I think, on Windows, or \temp on Unix systems. and what will happen is a long file named WebObjects log will be generated. Quick warning that this log is really big. We dump a lot of information into 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 and a few seconds later we'll start logging to it. When you delete log WebObjects, we'll stop logging to it.

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 to WebObjects 5 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 WOA or your framework. And it's in pretty standard Java format. You have multiple lines. Each line is key equal value. You can also pass command line arguments, and those are passed as -d propertyName = propertyValue.

Again, we also support the old method of passing arguments to WebObjects, which is the -wo 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 WoePort, WoeHost, WoeDebuggingEnabled, WoeOutputPath, WoeCachingEnabled, WoeListenQueueSize, WoeAllowsConcurrentRequestHandling, WoeWorkerThreadCountMin, and Max. Some of these are new, some of these are old.

So WoePort 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 57,000 something. WoHost 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 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 there's WoE debugging enabled, and you turn on and off basic WebObjects logging. There's also, I think, EO adapter debug enabled and some other stuff. Really, see NSLog for details. It's best that you can customize this for your particular application by enabling or disabling specific debugging groups and at specific debugging levels. In any case, what we provide now is WoE output path.

WoE output path redirects all of your debugging output from NSLog to a particular file. Normally, we dump it all to standard out and 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 Wotacity output and now in Java doesn't go anywhere.

So now we're on to performance properties. Woe Caching Enables tells the WebObjects application whether or not it should cache the WebObjects components in memory, basically the .woe 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 requests 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 WoeListen Queue Size lets you set how many connections we allow to sort of wait to get accepted.

What 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

So the last thing is, what worker thread count min and what worker thread count max? And this is just the number of threads. What 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 it to grow infinitely. For those of you who are familiar with 4.5 or 4.5.1, 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 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 a 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, mybighonkingstore.com on a Celeron. 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, we'll 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. 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 WebObjects. You can control how big your web server is, 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 WebObjects 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 systems then. So how do I tell how much memory or CPU I'm using? On Mac OS X, there's the CPU monitor, there's the process viewer, and VM stat. VM stat's a command line thing. It'll tell you basically how you're paging, how many pages you've got free, how many you've swapped out, locality, that sort of thing. CPU monitor tells you how much CPU you're using. And process viewer lets you view processes.

So Solera 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 a process viewer and a CPU monitor as well.

Network monitoring tools. Mac OS X has the network utility, lets you do things like net stat and ping and that sort of thing. Solaris has the net stat directly at the command line, and Windows has 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 leaking? Are they doing good? Do we have too many open? And then you have packet sniffers. You have 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 JProbe, optimize it. Optimize it is now available on Mac OS X. The Java 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 will 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. You can say how many requests, hit your application and see. It's 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 WebObjects frameworks themselves provide some sort of feedback. There's the WoEvent stuff, which we'll be going over in detail in Optimizing WebObjects, and the WoEstats 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 to 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 T1s. All the deployment principles are the same.

WebObjects 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, Matilda in this case, and they pass requests to Qualia, which is talking to a database, Kaby.

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 and 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 as the number of clients grows and we discover, alright, 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 mirror 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 WebObjects deployment works. You can have multiple instances on potentially multiple application servers, and you have a WebObjects adapter. And the WebObjects adapter passes requests to your 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 WebObjects lab is still open. It's open from actually when this session started to 6 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 going to be open. We have a roadmap and it may seem a little strange that we want you to go to the Java performance 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 Java VMs. Optimizing WebObjects 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, iServices, URLs.