Welcome back, everybody. It is my pleasure to introduce Christopher Friesen. Good morning, and welcome to session 709, Deploying WebObjects Applications. Let's see what we're going to cover in this session in the next hour. First we're going to do a deployment overview. Then we'll talk about configuring your WebObjects deployment. And then we'll go on to system monitoring. Cover typical deployment, and then take your questions and answers.

Here we have the basic architecture of a WebObjects deployment. You can see at the top, we have your client that's going to make a request to your HTTP server. Your HTTP server will then forward that request to your WebObjects application, which will then create the dynamic content, usually using data in your persistent data store, which is your database. That request will then be returned back to the client. Usually on your development system, you might have all this running on one machine. But for a good WebObjects deployment, you'll often have each of these pieces on a completely separate host.

Here we have the deployment architecture in more detail. In the upper left, you have the client browser, which is making a request to your HTTP server. On the HTTP server, we have this piece of code that knows how to recognize, it knows what to do with your WebObjects requests, with requests to your client requests to your WebObjects application. This piece of code is called the WebObjects adapter. It's not really purple.

And it will go ahead and figure out that the request is going to a specific WebObjects instance and send it on to your killer application. Your application will create the dynamic response using your database and then return it back to the client. There are two basic deployment methods for a WebObjects application.

You have your standard WebObjects application that you're used to writing, and you can now use JSP and servlet containers. Your standard WebObjects application has the benefit that you can use our monitor and Wotacity for managing your deployment. This lets you deploy multiple instances of your applications across multiple hosts. and it lets you use the WebObjects HTTP adapter, which has some benefits we'll talk about.

For deploying using JSP and servlets, you can use--we've tested Tomcat and WebLogic. Now, when you use those servlet containers, you'll have to use their management tools. So you won't be able to use monitor and lotacity, and you won't be going through the WebObjects HTTP adapter. And for more information on JSP and server-led integration, you should see session 7.10, which is in this same room after lunch.

Now when you deploy your WebObjects application using the HTTP adapter, you usually end up with what is called a split installation. The split installation gives you public and private resources in two different places. You'll have public resources on your HTTP server in your document root. This will include things like images, sounds, and your client side Java.

Generally things that it's okay if people get to if your HTTP server is misconfigured and your document root gets raided. Now you have more important things, like your executable, your business logic, your important data, and server-side Java. That can all live on your application server host, and this is called your private resources.

Now let's talk about some deployment details for your WebObjects deployment. The supported operating systems are Mac OS X Server 10.1, Windows 2000 Server, and Solaris 2.8. And these all require JRE of 131 or higher. Now, if you read through some of the WebObjects mailing lists, you'll see that some people have gotten it to run on Linux and FreeBSD, but you'll need to ask them what exactly they did to configure that.

There are some hardware considerations for your WebObjects deployment. You need to consider the processor capability. What sort of--you need to consider what sort of application you're writing, how much data you're pushing out, whether or not you can run this on a PDA running Linux and a 131 JVM, or if you're going to need a dual processor G4.

need to consider the number of processors. You can have many processors in one big box, or you can have many boxes with fewer numbers of processors. There's some advantages and disadvantages to both. And then you need to consider the amount of RAM you need to run your application. You want your application to run all in memory. You don't want to be paging to disk because of the large performance hit.

And then you need to consider the disk space for the installation, log files, and possibly your data. and finally redundancy. If you have multiple machines, it's easier to switch a machine in and out. If you've got one big box, often the redundancy is built into that one big machine. They often have multiple power supplies and ways you can hot swap power supplies, fans, hard drives, things like that.

There are location considerations for your deployment. What sort of network capacity do they have? You need to consider what network capacity you need. If you're going to be selling software over the Web, you're going to be pushing a lot of data through that pipe. You need to make sure that you can handle the client requests at the same time that you're serving content.

Network security. Is your deployment site, do they have firewalls already? Or do you need to get your own firewalls? Are you going to have to configure them? What ports are Physical security. This is your important data, your expensive hardware. Is somebody locking this stuff up? Is somebody watching it? Or is somebody going to be able to walk away with it? And then you have temperature control. I'm sure you've been in computer rooms that may or may not have temperature control. They get pretty hot. So your computers don't like to run hot. It'll actually save them if you run them in a temperature controlled environment. And then last, your uninterruptible power supply.

If you've signed a contract with a client, you need to be up 24 by 7. You might have to look into getting a generator. If you just need enough power to shut down your machines so that you can bring them up once the power comes back on, you still need to calculate how much power you need to get around all those machines.

There's some administrative considerations. What accounts are your applications going to run as? You don't really want them to be running as root. Your application logging. How much application logging will you be doing? You may want to do some when you first deploy so that if there are any problems, then you'll have the logs there immediately. But that can start to eat up a lot of disk space.

And the last is access control. How are you going to access those machines so you can manage them? Are you going to be on site, or do you need a secure remote connection? What do you control with your deployment? Well, you can control the WebObjects adapter. You can control settings like socket timeouts and the type of load balancing that you've chosen. You can also configure the WebObjects adapter yourself because we give you the C source code.

Next is your application. You're writing your application. You need it to provide a certain service to your clients. If you choose the wrong algorithms, that can adversely affect the performance of your application. And last is your database. You choose which database you're deploying with. They have different performance. It also depends on what hardware you deploy it on.

So again, the WebObjects adapter, it forwards requests from the WebObjects, from the client to the WebObjects applications. What does it do for you? Well, it gives you better performance. With the split installation, public files, like images and things, can be served directly from the web server. You don't have to make that extra round trip to your application server. You also get better performance because the WebObjects adapter does load balancing. So that means you can have multiple application instances deployed across multiple machines, or even into one large machine.

You have validation of client requests. The WebObjects adapter makes sure that the request is well formed so that your WebObjects application doesn't have to deal with that. and finally security with split installation, public resources, Your private resources are on your application server, and they aren't in your document root, where misconfiguration of the HTTP server can make them vulnerable.

There are two basic types of WebObjects adapter. There's CGI and API. The CGI adapter works everywhere, but it's slow because it requires forking a process for each request. And on Windows, there's no load balancing using CGI, using our CGI adapter anyway. With API, it's faster, but you can only use it with specific HTTP servers, such as Apache, NSAPI, and ISAPI. And it supports load balancing on all platforms. As I said earlier, we give you the C source code. So if you need to change the load balancing scheme, you can do that. All you need to do is recompile and then redeploy that plug-in.

Here's a matrix of the supported platforms and supported HTTP server adapters. So we see that Mac OS X Server and Solaris both support Apache. Solaris supports the NSAPI adapter, and Windows 2000 Server supports the ISAPI adapter. And all three platforms support the CGI adapter. So what is load balancing? Well, it's the distribution of client requests between multiple instances of your applications.

So the first time a client makes a request to your application, WebObjects adapter will notice that you haven't started a session on a particular instance of your application. So that'll then get load balanced using one of the three types of load balancing. The first is random, which is pseudo-random. It's difficult to get completely random, but it should be good enough.

The second is round robin, which is taking turns. So if you have four instances, the first request to go to instance one, then two, three, then four, then back to one. And the last is load average. And what it attempts to do is measure the load of your applications by the number of sessions that are running on each application instance. And you can change that by changing the source code.

So if you have a different scheme you think might work better, then you can do that. Most big sites seem to find that using random works the best. So here's an overview of what's happening with the adapter. Your client browser is making a request. It already has a session.

That request is received by your HTTP server. It notices that it's a request to a WebObjects application and is configured to handle-- configured to pass that to the WebObjects adapter to be handled. WebObjects adapter notices that it's a request to killer app, instance number two. WebObjects adapter then looks up in its host configuration and sees that KillerApp instance 2 is running on host omega port 4002.

WebObjects Adapter then forwards that request to that particular instance running on host omega. where the instance then processes the request and passes it back to the client. The adapter site config. It maps the application name and instance ID to an application server and port number. So as you saw, KillerApp instance one and two are both running on host omega, port 4001 and 4002. KillerApp instance three and four are running on host gamma, ports 4001 and 4002.

The same port numbers are okay because they're completely separate hosts. The additional options that it keeps track of are the load balancing types configured for those applications and the number of persistent connections allowed to that application. There are also socket options that it keeps track of. You can set buffer sizes and socket timeouts, like we talked about.

There are three basic ways to configure the WebObjects adapter. The first is flat file. This is a URL to a file on the file system of that machine running the WebObjects adapter. The second is host list. It's a list of hosts that it's going to go out and talk to to find out what application instances are running. And the third is multicast. This is a dynamic way of finding out which hosts are available, which hosts are hosting WebObjects applications.

This information is updated every 10 seconds. So the adapter tries to--should figure out that you've started up a new instance on one of your application servers within 10 seconds. The flat file configuration. It's in XML format. There's a great example of how to set it all up in the Deploying WebObjects Applications book. And here we see an example of the XML. See that there's an application called KillerApp. The load balancing is round robin. The instance ID is 1. The host that it's running on is omega. And the port number is 4001 if you're talking to that particular application instance.

The second is host list configuration. The adapter requests dynamic configuration information from a list of hosts that you specify. This information is supplied by WOTASTI, or the WebObjects task daemon. This information is supplied in the same XML format as the flat file uses. And this allows the dynamic addition of the application instances on the listed hosts.

The default mechanism for the adapters is a host list pointing to the local host and WoTasty running on port 1085. So let's look at how the adapter and host list works. WebObjects adapter, in purple there, and you have your two application servers, omega and So your application instances start up. They send life beats to Wotasty running on each machine, saying, I've just started.

WebObjects adapter within 10 seconds. We'll look at its configuration and see that it's configured for host list. It's supposed to talk to host, omega, and gamma on port 1085. So it sends out two separate requests to each host. Here it's drawn as one request, but it's actually two. So it asks each Wotasty, what application instances are running on your machine? They respond back, and the WebObjects adapter then builds a list of the known application instances.

The multicast configuration. Broadcast UDP to a specific IP address and port number. In this case, the specific IP address is a multicast address. This means that you can send out a single packet and applications that are configured to listen on the local subnet will hear that. Multicast is limited to the local subnet by default. Most routers are configured not to pass this information, and most system administrators or IT departments won't want to configure it otherwise. That's probably for the best.

This dynamically builds a list of the available hosts running with hosties that respond to the multicast query. The configuration proceeds exactly like host list, once it has the list of application servers. The default host rediscovery is every 100 seconds. It's actually ten times whatever you set the default application instance, which was ten seconds previously. Let's look at how this works. So the adapter is configured to do multicast. Your application instances start up and register with Wotasty on their machines.

WebObjects adapter sends out a multicast query. It's one query out on the wire. And Wotacity has been configured on host, omega, and gamma to respond to multicast. You have to explicitly do this as it's turned off by default. I believe it's an option called woe responds to multicat. No? I don't remember. Anyway. It's in the documentation.

So, Wotasty will respond back and say, "I'm available." WebObjects adapter then builds a dynamic list of which hosts are available and listening. WebObjects Adapter then sends out a separate query to each Wotacity running on those machines, saying, what applications are running? It responds and builds the list of known application instances that are running. Wotasty. It started at boot time on all platforms. It is watched over by another process called Woservice. This is in case Wotasty crashes. Woservice will automatically restart Wotasty so that your deployment stays up.

It supplies the adapter with dynamic configuration data. This is the XML data that we saw. And it's usually listening on port 1085. That's the default. and it registers running instances on the same machine. It watches, cycles, and restarts those configured instances. And it's configured using Monitor. What is Monitor? Monitor is a WebObjects application. It's basically the web interface to Wotasty.

It allows you to configure application instances. You can configure them across multiple hosts. And it lets you manage the scheduling of those instances as well. and it lets you configure the WebObjects adapter with various timeout settings and buffer settings and load balancing schemes for each application. Monitor can be password protected so other people cannot take control of your deployment, but you should only be running one instance of monitor. If I run an instance of monitor and say I want to configure applications on the host omega and somebody else runs monitor and adds host omega as a host they want to manage, then we'll be pushing two different configurations to the same machine.

Instance scheduling. Each instance can be scheduled independently. So, a scheduled instance is restarted periodically by Wotasty. There are three types of scheduling. There's hourly, daily, and weekly. So you can choose an application instance to restart once a week if you choose. And that's often useful if your application has a memory leak or seems to perform better once it's been restarted if it's been running for a period of time.

Application instances can be terminated immediately, which means that if the client user has a session open on that particular application instance, it'll get terminated. Now if you have session storing back behind all that, which is an extra step, then the user would be able to connect to a different instance and get their session back.

If you don't have that configured, then you might want to go with graceful termination. What this does is it tells the application instance to start refusing new sessions. So it'll continue to process requests from clients that already have a session started. And then once all those people have logged off of your application, or the sessions have timed out, then your application instance will restart. And now we have Karl Hsu, the wonderful Karl Hsu, up to give us a great demo.

Good morning, everybody. So, all right. The first thing I'm going to do is--and we are up. OK. I just want to double check that Wotasty is running. Easy way to do this is to just hit 1085 and you'll get back Wotasty. So it'll tell you a bunch of information and it'll tell you what its site configuration is and then the various adapter configurations.

So before we go into this actual demo, I'm going to really quickly discuss this. In WebObjects, we have fundamentally three different ways to hit an application. The basic way, which you use in development all the time, is called direct connect. You're connecting directly to the port that the application happens to be running on.

When you deploy an application, you're going through the web server. Chris mentioned a number of reasons that you would want to do this: performance, security, the fact that you can have multiple applications all being accessed on port 80. And then you don't hit it through the port number, or you hit it all through the port number 80 through the web server.

In WebObjects 5, we added development instances where you can hit it through the web server, but you're doing it in a way that it's not really publicly accessible. In order to access the instance, you use a negative instance number. And it's not load balanced along with the rest of them.

This allows you to have applications running, and you can test it through the web server even if you're actually deploying other applications on that web server and you don't have the problem with people accidentally getting to that app. All right. So let's start monitor. So while Monitor is starting, you can see in the terminal window on the bottom right, I'm inside of System Library WebObjects Adapter's Apache, which is on Mac OS X, where you would configure the Apache adapter by default.

and what I'm going to do is edit the Apache conf. The reason I'm doing this is because Later on, we want to be able to see the WoW Adapter info page. Okay. The way we do this is by setting the WebObjects admin username to public. And that will let us take a look at it later. You can see down here that you can actually set it to a username and password. You can pass it as a key value pair, or a form value, whatever you want to call it, on the command line.

So up here, you can see the examples that Chris had talked about. Our default configuration is HTTP localhost 1085 with a refresh interval of 10 seconds. That's a standard. We have commented out examples for you. WebObjects configuration, this is the multicast address which you saw earlier. And this is the file configuration that you saw earlier. All right, so now that we've done that, let's bounce the web server. Okay. All right, monitor's up. So monitor starts up and you're totally blank. The first thing I'm going to do is I'm going to give it the URL to the adapter.

This doesn't actually do anything. What it does is it lets Monitor create HTML or hyperlinks properly later on. It's useful. And the reason it doesn't really do anything is because Monitor may not be monitoring apps that are accessible through a web server. It could be monitoring applications that are accessible through multiple web servers. It doesn't really know. So the two are actually independent. A side effect of this is that just because you've configured an application in Monitor does not mean that it's automatically accessible to your web server.

Your web server only looks for applications on localhost by default. So if I have hosts 1, 2, and 3, and I configure applications on all of them, web servers on host 1, it will only see applications on host 1. You have to explicitly point it at the other hosts or you won't get to those instances. So that's the side effect of this. It's a common mistake. It's something to keep in mind. All right, the first thing before we do anything else is we should add a host. I'm not going to try to type this in because it's quite impressive, really.

You can type this in as a--you can try localhost. That works for a lot of deployments. I would not suggest it if you have more than one host. Otherwise, all of the hosts will think that they're localhost, and everything will go completely AWOL. In newer versions of monitor, we prevent you from adding more hosts once you've added a localhost.

You can also type in an IP address if you don't have a DNS name. One of the things is that you should choose the type of host, because we use that to find the application later. You can choose Mac OS X, Windows, or generic Unix. The only other generic Unix we support now is Solaris, but people have used it for other things.

So this has come up now. One of the interesting things is that you can actually set a password on Wotasty. And if you do that, you won't be able to get any information back from just hitting localhost:1085. It'll tell you that your password isn't set properly. But what you can do is go to the host page, and if it's available, it'll show yes. If you click the yes link, you'll get back that page that we saw earlier. Okay. Let's go to applications. And let's add an application. We're going to add Hello World, because I'm boring.

All right. Remember how I asked or I mentioned that you can have hosts that are of different types? This is why. You can see the path, and we allow you to set, for a single application, a different path for each type of host. So if in case you happen to be deploying, you know, some of your applications are on a Solaris box, some of your applications are on a Mac OS X box because you're trying them out or whatever, you don't have to keep reconfiguring it or set up different application instances or different applications that are actually the same with different paths. It should be much easier. So let's browse for... This host. Oops. All right. Let's not browse for this host. Let's type this host down.

One interesting point, you have to specify the launch file inside of the WOA. Inside of each WOA you have two script files. So if you have hello world dot WOA, inside of that will be hello world and hello world dot cmd. Hello world, without the cmd, gets used on both Solaris and Mac OS X or any other Unix system. The dot cmd file is for launching on Windows. We're going to turn off auto-recover for now. All right, one other thing is we are going to-- Set the statistics page password so we can take a look at it. And I'll pick a really tacky password, secret.

So now we go to detail view. And this is where you'll probably spend a good chunk of your time once you've actually configured your initial instances. What we let you do here is add instances. And you can see it's the name of the application, what host and what port it's running on, whether it's on or off. You can start or stop them individually or all together. Autorecover is the ability for WOTASTI to automatically start and then manage an application.

So if you have autorecovered enabled, WOTASTI will check every 30 seconds or so. And if the application isn't running, it will start it, which means that if your application crashes, the next time WOTASTI notices, it will start the application back up. Refuse new sessions, Chris talked about. It's the easy way for you to transfer loads, swap in new ones, swap in a new instance, whatever you want. And then scheduling just tells you whether scheduling is enabled for that application. So let's start these applications. Okay. Give it a minute and we'll see what we can see.

All right, so they're started. What we're showing--well, let's refresh this. And you can see that they're now showing. So this first link links through the adapter. The second link is directly to the application. This may not be applicable if you've turned off Direct Connect. What we're looking at on this page is the WoW Adapter info page.

This is the page that we set the password on. We changed it to public so we can hit it. And what it is is basically the adapter telling us as much information as it happens to know at the time. So you can see here we have Hello World running. We have three instances. It tells us the host and the port. And there's a whole wad of information. It'll tell you the number of actively processed requests, or the number of requests in processing, the number of total requests served.

If you're using connection pooling, It'll tell you how many... How many sockets are in the pool and how many times they've been reused. These are the connect, send, and read timeouts in seconds, and they're set to defaults, the size of the TCP send and receive buffers, whether something's refusing timeout, and whether something's been marked dead.

I'll show you an example of how the dead timeout works later. So here we can see, we can click on this. Oh, no. Okay. We're going to have problems because this is the wrong license. Well, it's Hello World. If we can take a look, let's find an image.

So it's Hello World. It's very simple. Yay. If the licensing permitted, what would happen is you could actually hit this URL, and you can see there's no instance number associated with it, and what it would do is it would redirect to the appropriate URL. Okay, so... Oh, yes, I remember what I wanted to show.

Let's take a look at this. So let's go over some of the other things in the adapter page. It'll tell you what server you're running, the name of the adapter, and the reason it shows 451 is because actually 451 and 5 share the same adapter. They're pretty much exactly the same thing, and it's the same source, blah, blah, blah. What this shows is the list of hosts that this application, this web server is talking to.

This is where it's giving what instances to load, which instances to vend, and so on, and it'll tell you when the last time it asked for it was. Generally, this will always show the most recent unless the application hasn't responded because hitting the WoW adapter info page forces it to refresh. Oh, sorry. My bad.

So you can see, this is the XML that Chris was talking about. This is the XML that a Wotasty will respond. And you can see, you know, we have the application hello world. It tells you the instance ID, the port, and the host. And then it has Java Monitor.

Java Monitor is running in development mode, the one that I talked to you about before. And you can see that, strangely, it doesn't have a positive ID number. It has a negative ID number. It happens to match the port. Right? And what this means is that I can hit monitor through the web server.

And so now Monitor's running through the web server. The thing to remember about this, though, is that it won't be load balanced. I can't get to Java Monitor by just doing this. Well, I can't anyway because the licensing's broken. But if I could, I couldn't. Did you all follow that? I'm just checking if you're awake. OK.

So we can show this. This isn't just for Java monitor, though. In fact, I can actually just start, like, a completely random instance of Hello World. and you can see it will start, see, creating life beat now, blah, blah, blah. It'll spit. What it's doing is it's contacting Wotasty and saying, I'm here, I'm here. Wotasty will get the life beat, inspect it, see it, and say, that's odd. You're not registered. Nobody added you to me explicitly. You must be a development instance.

This also works if you launch it in Project Builder or wherever else. Unless you've registered it in Wotasty, it'll treat it as a development instance. The converse is true, of course, as well. If you've registered an application, you don't need to use Monitor to start it. You can register an application with Wotasty using Monitor and then start it by hand if you want to do anything particular or you want to see the output directly instead of redirecting to a log file.

OK? So both will work. So let's take a look and let's refresh this page. You can see Hello World has now been added with a negative port number. Hello World, through the web server, not accessible through load balancing, assuming load balancing works. OK. Let's kill that and it'll go away in a little bit.

Okay. All right. Let's go back and take a look at monitor. All right, you can see that after we hit these applications, we have a little bit of statistics, right? Number of transactions, active sessions, and some other stuff. You might be thinking, well, that's okay. That's not a lot of information. It's very bland. So you can always go to the WoeStats page for a particular instance. And I think I used secret.

Yeah, our high-tech little login here. All right. So you can get detailed statistics for any particular instance that you want. It'll tell you moving average, average transaction times, you know, split by component and direct actions, average over the top, number of sessions, all this stuff like that. It'll tell you specifics-- what pages you hit, how fast they were, how many you've served. Really useful information. And then a little bit of information about the Java VM. Look at that. It's powered by WebObjects. 'cause I never saw that before. Okay.

What? Yes? Oh, I'm sorry. OK, so I'll go back. He, this man asked where I set the password. What you do is, you can set it on the command line, but I actually set it in monitor. When I first configured the instance, configuring application Hello World, it's an application setting. And so what you do is there's this statistics page password, and I type in secret here. OK? All right, let's go back here. And so what I can do now is shut this off.

Give it a second. Look, and it's off. And if we go back here, We can see that indeed the adapter has now picked it up. It's also picked up the fact that that instance that I had started by hand is gone. That's actually not too bad. Oops, I just killed Java Monitor.

That was bad. I'm hoping this is one of the Hello World instances. So this will actually take a minute. What ends up happening is Wotasty tries to be, to err on the side of caution. People get very upset if their network hiccups or, you know, you have a lot of apps, something gets paged out and takes a few seconds to come back in, and suddenly an application disappears. So Wotasty will actually wait for a few seconds. What it'll do is it expects to get a life beat from each instance every 30 seconds by default.

Right? And if it misses more than a certain number of them sequentially, it then assumes that the application is dead. It usually takes about two minutes by default. These are all tunable parameters. They're all documented in the book. You can set them on the command line or in a properties file if you like.

And let's check if Wotasty has figured it out. Wotasty has now figured out that the instance that I just killed is dead. It will then pass that information over to the adapters. So let's see something else. Let's start this back up. The adapter knows that it's running. And what I'm going to do is kill it again. Except I can't see the bottom.

And it should be dead, and now I'm going to try to hit it. So that's odd. Last time I hit application one and it worked. If you actually take a look, Take a look. Served 0 for 1, served 1 for instance 2, served 2 for instance 2. And dead timeout is now set to 18. So what happened was, monitor hasn't figured out that the instance is dead yet.

But the adapter knows for certain, because it tried to send a request to that instance, to instance 1, and it failed. So what it automatically did was it tried to balance it to another application. It said, all right, application 1 isn't responding. I'll mark it as dead, and I'll send the request to instance 1. Now instance 2, licensing said you can't respond to it, but had it been able to, it would have.

Right? What happens is in the adapter, it really wants to trust Wotasty, because Wotasty says what should be happening. Right? It could just be a glitch, somebody's bouncing, or the application happens to be tied up for the moment and doesn't want to respond, but will come back in a few seconds. So what it does is it sets the dead timeout to 30 by default.

This is the number of seconds it will wait before trying it again. Okay? And then it'll redirect and redirect. The reason that you still see, well, it's probably, Yeah. The reason that you still see one up here, of course, is because the browser can't change the URL once you've typed it in.

If you actually go dig farther down into the application, you'll see that subsequently it'll change to a different instance number after the first. And all the links, if you view, if there are any in the source, will also be to a different instance number because it actually is, ta-da, a different instance number. OK. That's pretty much our ten minute tour of Monitor and Motasty. And just about now I'll give the mic back to Chris. Actually, I'll give the floor back to Chris since we're wired. It's a stage. Thank you, Karl.

Thanks, Karl. You're welcome. So let's go back and review the adapter info page that Karl showed us. It lets you view the adapter's status. This is great for debugging your WebObjects deployment. This way you know exactly what your adapter thinks are available, which application instances are available, and what sort of state it thinks they're in.

as you see, the URL for accessing the WoW Adapter info page is the URL to your WebObjects adapter on your HTTP server with WoW Adapter info at the end. It gave us some detailed configuration information. This included some socket timeouts. They were labeled CTO/STO/RTO. And the connection and send timeouts don't mean a whole lot in the current WebObjects adapter because we're using non-blocking sockets.

And that means that unless the system resources have run out, those will just happen. So the timeouts don't mean anything there. The only timeout that really means anything is the receive timeout. So if the receive timeout expires, the adapter will then assume that that application instance is dead and mark it so, like Karl showed us. Refusing timeout.

If you're trying to restart an application instance gracefully, and we told it to refuse new sessions, the adapter doesn't know that until it tries to talk to that particular application instance. So you don't want your load balancing scheme to try and pound one particular instance because the session numbers are a lot less than the other sessions. So that tells the adapter, you know, quit bugging me for a while, go, you know, hit the other instances, come back and check with me later.

And it gave us links to all the available application instances, so it's easy for you to check to make sure that they're all responding. The adapter info page is disabled by default, and you can set it to either be public access, which means anybody hitting your web server can see it, or you can give it a password and a user name.

The adapter logging is another way to debug your WebObjects deployment. To enable adapter logging, you create a log WebObjects file. You can just touch this. It doesn't have to contain anything inside. It just has to exist as a file name. And you create that in your temporary directory. The logging will then start, and the log file is called webobjects.log. And you can stop and start the WebObjects logging by creating and removing the log WebObjects file in your temporary directory. So this way you don't have to restart your HTTP server every time.

instance configuration. For defaults for your applications, you can use the standard Java util properties. First, the properties file from all included frameworks are scanned. And then those values are overridden by the properties file in your application.woa. And then finally, those options are overridden by command line arguments that you might set. The properties file itself is named conveniently properties. And it's located either in the .woa or .framework resources directory. It's one property per line, name equals value. On the command line, you'll specify dash D, and then name equals and the value.

Here's some useful properties. There's woe port, woe host. Probably don't need to read them all to you. For configuration, WillPort takes a port number. It's the port that your application instance will listen on for requests forwarded from the WebObjects adapter or directly connected from your browser if you have that turned on. If you don't set one, then it arbitrarily chooses one.

Wo host takes an IP address or host name. And what this does is it binds the listen socket, which you can specify with wo port, to a specific Ethernet interface. This way, if you have multiple Ethernet interfaces on one machine, you can configure that machine as if it were two different boxes. This is only really useful, of course, on machines with multiple Ethernet interfaces. There are some logging properties. If you've done any WebObjects development, you should be familiar with WoDebuggingEnabled. True turns it on.

This sends your NSLogs. This allows you to print your various NSLogs, and you can configure NSLog to have different groups and different levels of debugging. And there are some that are already predefined, and they're talked about in the documentation for NSLog. And then there's woe output path. This will redirect the debugging output to a specific file, and it redirects those NS logs we talked about.

For performance, there's Woe Caching Enabled. True and false. This caches the WebObjects components in memory for deployment, rather than reading them from the file system. For deployment, this is set to true. It's set to false for development, because you want to be able to make changes to your project and see those instantly without having to kill and restart your application.

Well, listen queue size takes account. And it's the number of outstanding requests that your application will queue up at any one time. This defaults to 128. WoW allows concurrent request handling, true and false, determines whether requests are processed in serial. This defaults to false. If you set it to true, your application will be multi-threaded, and you better make sure it's thread safe.

Some more performance properties. There's will worker thread count minimum. This takes a count. And it's the starting number of threads processing incoming requests. This defaults to 16. There's a maximum. Will worker thread count maximum? Takes a number. You probably shouldn't try setting that lower than the minimum. Don't know what will happen. The maximum number of threads to create for processing those incoming requests. This defaults to 256. If you set it to negative one, it can grow infinitely, and you may run out of memory in your JVM, depending on how many requests you get coming in.

There are some potential bottlenecks for your deployment. The first is your application. Depending on how much data you're processing or what sort of algorithms you use, you may need to optimize your application to get better performance out of it. You can also deploy more of your applications to increase the performance of your site. The second is your database, which database you're using, what sort of hardware it's running on, how much data is in your database. Those can all affect its performance.

The third is your CPU. You may have plenty of memory and be able to run your applications completely in memory, but you may be pegging your CPU and therefore limiting how many requests you can process. So it may be time to add another machine or upgrade your processor.

Next is virtual memory and RAM. As we talked about earlier, you want to be running your WebObjects application on main memory. This will be a lot faster than if you start paging to disk, as disk access is orders of magnitude slower than reading from memory. And finally, network. If you have a small pipe and you're trying to process lots of requests, that can be a major bottleneck for you. You may need to upgrade your network connection or change sites where you're locating your deployment. And you should see session 710 for optimizing WebObjects applications.

Now for monitoring the memory and CPU usage of your deployment, there are tools that are available on the platforms. Mac OS X Server, there's CPU Monitor. There's also Process Viewer. And VMstat will give you an idea of the virtual memory system. Solaris, there's PS and Top. And on Windows, you can use Task Manager to give both CPU usage and memory usage.

For network monitoring, Mac OS X Server has network utility, which is basically a GUI interface to many Unix utilities like ping, traceroute, whois, netstat. Netstat's also available on Solaris, and there are also the other generic Unix utilities available on Solaris. Netstat will also give you a list of how ports are being used on your machine. So you can get a list of open ports and what state they're in. So you can find out if you've set your WoW life beat to a very low number, you may start using up too many ports on your machine and run out of resources.

So you probably want to leave it at about 30 seconds, which is the default. Windows, there's Network Monitor. There are also packet sniffers for monitoring what is actually going across on the wire. There's hardware solutions. There are also software solutions like TCP dump and TCP monitor. Sometimes this is useful if you're trying to figure out differences between two different browsers and what they're doing with the requests that they're sending to your applications.

Their application monitoring tools. Seeing as WebObjects is all Java now, you can use standard Java tools, like JProbe and Optimizeit. for testing your deployment, their external load generators. We give you Playback Manager, which allows you to record client hits to your application and then play those back. There's also third-party solutions like Silk Performer.

WebObjects frameworks themselves have analysis tools like WoEvents. WoEvents is very low level. It's also a subclass of EOEvents, so you can get the same sort of thing for your enterprise objects. And then WoStats, we saw the output of that on the WoStat info page. Both WoEvents and WoStats are protected by passwords to prevent other people from seeing how your application performs.

In all these different deployments, the principles are basically the same, just that you may be running into the different bottlenecks at different times. For instance, with your small application, you probably only have a cable DSL modem. So you can't be serving large amounts of data across that. So you probably have plenty of processor and CPU and RAM for your deployment in that case, just a matter of how many clients you'll have.

As you get larger, you'll be running into different limits. As you get sort of mid-sized, fractional T1, that may be enough to start serving more clients, and you may need to start adding more application servers. Of course, when you get to a large enterprise, you'll need a large pipe and probably many application servers.

So here we have a sample deployment. We have just a couple clients. We have one HTTP server with an API adapter running. And we have one application server with two instances. Now, these instances could be multithreaded and be able to handle many requests. And you have your database.

You really want a firewall between you and the outside world. In this case, we've only opened up port 80, so the requests can only come in from the client to our web server. Actually, the request to go all the way through and talk to Omega at this point, our application server. But we're not listening on port 80.

So then we have even more clients because our applications become more popular or we have more customers. You might need to add a second HTTP server. In this case, we've added another machine called Matilda2. But we'd really like our clients to have one URL to go to. So we need a round robin DNS.

This way, there's a single point of access for your WebObjects applications, and the requests are passed between Matilda 1 and Matilda 2. It also gives you redundancy, and you can swap out one of the machines should one of the machines have a hardware failure. So your site will stay up no matter what happens.

With even more clients out there accessing your application, you may need to add another application server with some more instances running on it. And it's really a good idea to have another firewall between your HTTP servers, which are more vulnerable than your application servers. And it also allows you to protect your business data and your--possibly even your customer data, which could be even more important.

And for more performance, we can mirror the database. This also allows us to easily back up the database in case one of the -- you would have your database running on a completely separate machine. So you'd have two machines running databases. So if one dies, you can easily switch to the other one. And we end up with three zones. You have your intra/extranet, protected by your first firewall, your border zone where your HTTP servers live, and then another firewall that protects your internal private network.

And that's pretty much all we have for you today on deploying WebObjects. To be considered for the WebObjects beta... Please visit us at this URL. We have the WebObjects lab if you'd like to try messing around with monitor and accessing the adapter info page. And hopefully we'll have some deployment instances, licenses on some of those machines. And we're available through 6:00 p.m. today and 9:00 to 6:00 tomorrow.

Here's the roadmap. So for JSP and servlet integration, you'll want to see the session this afternoon in this room after lunch. And then on Friday, we have Optimizing Your WebObjects Applications, which is important for deploying. And then finally, you can give us feedback on our deployment strategies at the WebObjects feedback forum.

You can contact Tony and Bob at [email protected] if you have any comments. and Apple Professional Services has good training. They have a training program for WebObjects, which includes a deployment class if you want some hands-on training for this. They often have several different servers and some different platforms for you to try your deployments on as well. And for more information, there's the ever-evolving WebObjects developer documentation. It's getting better all the time, so come back and visit us.

and the Deploying WebObjects Applications book is a very good book. It has very good coverage of deploying your WebObjects applications. And apparently we also have books on developing applications using Java server pages and servlets. Again, for the most up-to-date PDF and HTML documentation, visit us at developer.apple.com, techpubs.com.