Hi there. Thanks for coming. Boy, this headphone is interesting. I kind of feel like I should take it off and just, you know, use the force. But I'm going to keep it on. We'll see. Yeah, right, we're here to talk about WebObjects and J2EE deployment. Hope everybody's in the right room.

So, how are you all doing? Appreciate you hanging around all day. How many people have been to either of the other two WebObjects sessions today? Wow. A lot of dedicated people. We like that. We appreciate that. There certainly is enough, there are enough interesting things that are being shown at this conference, so that shows some dedication.

I got the clicker right. All right, my name is Ray Kiddy. I'm WebObjects EOF engineer. And session 610. What we're going to talk about is not development, because you're done with development. Now, maybe you're a developer and you now have to deploy your application. Maybe you're just a deployer.

And so, if you're a developer, you've thought about your app one way. You need to start to think about it another way. If you're a deployer, maybe you don't know WebObjects or you don't want to know all that much about the development process, but you need to know how to ask the right questions to get the deployment set up.

So, we're going to talk about that. We're going to start from the bottom, the data, configuring EOF. We're going to talk about some easy ways to deploy the application to get things started. Sort of set the alpha state, get it working. Other ways to deploy your applications and then some of the other pieces of the puzzle, scalability, troubleshooting, things like that.

So this is sort of the vocabulary list of the things you'll learn. You'll learn how to ask some good questions of developers, how to know if you're ready for your deployment, what the buzzwords are, what the classes are, and what the tools are. You'll know how to start deploying the application via Direct Connect and also via the WoW adapter, and then how to deploy another way using the J2EE container. Then we're going to talk about monitoring the application to try to find out what's going on.

You know, trying to get a sort of knowledge-based approach to dealing with your application. You know, we want to try to make it so that when you deploy your application and if something goes wrong, you know, you should know where to go to get information to make changes. You don't want to make changes based on your guesses. You want to make changes based on actual information that you've seen and actual knowledge that you have. And so we want to help you get that knowledge about your application. And again, the ever-present theme, don't panic.

So the vocabulary of WebObjects, just terminology. WebObjects applications are just, you know, Java servlet applications. That's in quotes because that's sort of management speak. They're not servlets, but they're close enough. You know, if somebody reads some of those magazines, you can say it's a servlet application. That's fine.

Ray Kiddy, Chris Pavicich So obviously HTTP server is on the system, MySQL and or Oracle. The server admin is used, you can, you know, we're using with WebObjects, J2EE, so that's there to administer those. Ray Kiddy, Chris Pavicich WoMonitor and Tomcat, also known as Apache, Jakarta Tomcat. They keep complicating the names. Ray Kiddy, Chris Pavicich Axis, aka Web Services Project at Apache, and then JBoss, aka Mark Fleury, PhD. Ray Kiddy, Chris Pavicich So if you know him, you know it's a... J Boss is his, so.

So, information is not knowledge. We're starting with the data. Now, this is actually a metaphorical thread, and I've been told I can't just throw these quotes out there without context, so I'm going to have to go through them. First, I want to point out, though, that given that you are concerned about data, think about going to one of these sessions, either the MySQL session or the Oracle session, and that's on Thursday and Friday.

So, tell me if anybody knows this quote. Come on, you know, be representing here. Let me know. Let me know I'm not up here alone. Information is not knowledge. Knowledge is not wisdom. Wisdom is not truth. I don't see any recognition yet. Truth is not beauty. The man in the back got it right, Zappa. Okay, truth. Beauty is not love.

Yeah, well, see, I wanted to use this. I mean, you know, iTunes is driven by WebObjects, really. You know, Steve Jobs, really, he loves us. You know, he doesn't know how much he loves us, but he does. You know, it's just, it's painfully clear. I mean, look at the music store, look how beautiful it is. It's, you know, one of the world's largest WebObjects deployments, and basically it wouldn't be there if it wasn't for the flexibility and power of WebObjects.

When you're deploying an application, you need to think more aggressively about undo-redo. It's very easy to not think about this when you're developing an application because you're just running a single instance and doing things. But then when you deploy, it can use a lot more memory. Everything you do in the editing context generates copies, potentially, in the undo-redo stack.

And so look at these methods in the EO editing context and see how you want to handle undo-redo. Find out how much of that state you really need to keep around. If your app is going to encounter memory pressure, you should know where to tune it to get it to behave, to get it to be smaller.

Freshness and synchronicity is actually a little bit of a complicated topic.

The fetch timestamp in the editing context is how you configure this. And so by default, the editing context will keep the data no more than an hour old. And so as you're deploying, think about if you want to change that, move it up, move it back.

It affects how the app behaves. It's very much a deployment issue because you can develop for quite a while and you'll never have to think about it. And then you get a couple of users or a bunch of users on the app. And then all of a sudden, it comes up and you'll have to deal with it, sometimes in very sophisticated ways. So it's something to keep in mind.

Obviously, you can hear more about this from the performance session on Friday. So again, this is the object graph, shared data, undo, redo, freshness and synchronicity, and managing rights to the database. These aren't the only things you need to know about EOF to deploy an application. But if you're deploying an application, especially if you're not a developer also, you want to, as I said, ask the developer about these questions and at least make sure that they have intelligent answers for them.

Ask them, so of all the data that we have in the database, how are you making sure that copies of data aren't being shared among too many instances, too many copies being made? How are you sharing the data? How many copies of different things are you keeping in the editing context? If the developer has intelligent answers for these questions, then there shouldn't be many surprises when the application actually deploys. What you want to avoid is you bring up your application, you're running it as a developer.

You're running it as a developer with one or two different sessions going on. And then you put it out and five or ten people use it. And then, you know, maybe it's a public app and it gets slash dotted. You know, you go to the floor right then. I mean, if you haven't thought about these things before, you'll have no idea what to do. These questions make it so that when your demand scales, that you can scale the applications up to meet the demand quickly.

This last one is just, I wanted to say, what does the developer need to know about the deployment? And I would say, why does the developer ask? They don't need to know. The data should be abstracted for them. They look at it through the EOModeler application and they shouldn't have to worry about it. And frankly, if they're doing too many cute things under the covers, it's just going to cause problems later on.

Knowledge is not wisdom. So I just wanted to go through the base case starting with a simple WebObjects application, you know, the parts of it. And again, this is somewhat from the perspective of somebody who's not an expert in WebObjects already. First time you deploy an application, a lot of people see strange things because the class path isn't quite how they think it should be, and they don't realize that that's the problem.

Deployment machines, it can be a little bit differently laid out than what you have on your development machine. Or you've just gotten the app from a developer. You don't know how this person has their machine set up. So you launch the app. The class path is set up in a file inside the WOA, and it is in the console output.

This is perhaps a shallow point, but I just wanted to point it out because we get a lot of questions and we can often answer them by starting, "Well, if you look in the class path, you'll see..." So, you know, this is a job application. You know, look carefully at the class path and make sure that it is what you think it is. and a lot of the initial deployment pain will be reduced if you're cognizant of this.

So keep in mind, when you're deploying an application, it is very often valuable to separate cleanly the server side and client side resources. So when you're first developing WebObjects, it's easy. Most things end up in the server side. The server side is your business logic. It is dynamically generated resources, not so often used perhaps, but custom WoE component logic is on the server side. And these are things, when you install your application, you actually do two builds, one to the desk root for the application server target and one for the web server target.

So you're getting the two different sides of the application separately. In a deployment, you can separate those, and there is quite a bit of benefit to doing so. The server side, obviously your Java class is talking to your database. That all needs to be there. The client side is very often very static. Perhaps it's HTML fragments you include in your application. It's JPEGs. It's pictures. It's things that you reference in your, in your WoE component logic via an href binding.

It's also the custom interface classes in Java client applications. So those are very separate. When your user starts up a Java client application, WebStart identifies the server side, where they want to be, and then it downloads the client side. That download can actually come from anywhere on the internet.

The static client side application resources can actually be served from anywhere on the internet. And so oftentimes you'll see a shop that they have a deployment machine with the server side resources, and then off to the side they have something which just does nothing but scream HTTP and nothing else. And that's for static resources for simple vending through the HTTP adapter. And that's all the stuff that's going on.

And that's all the client side stuff. And as I said, that doesn't even have to be in your subnet that you serve the rest of the data from. That can be anywhere. So it's often useful to separate those out. In Xcode, this is the command you do. Xcode build install with the different configurations, and this will get you the two sides of your application separately placed.

So as a deployer, you've been given this WebObjects application. Now, does it work? You may not know. Hopefully it does. But somebody just handed you some directories, and so you don't really know if it works. Ray Kiddy, Chris Pavicich So as a deployer, you've been given this WebObjects application. Now, does it work? You may not know. Hopefully it does. But somebody just handed you some directories, and so you don't really know if it works.

Wisdom is not truth.

So, Woe Monitor is the application that we have made for configuring and deploying WebObjects applications. It's very flexible. One instance of it runs within a subnet and it can deploy applications on any machine in that subnet and it can deploy multiple instances of different kinds of applications on any machine in that subnet.

So, it is very flexible. It has a web interface, so you can even access it remotely. You may well want to consider the security of that situation if you do it. Maybe you want to put that through a special pipe so that it's secure or access it over a secure connection. So we're going to go through the overview, the adapter information, configuring and managing applications.

A Downside to the Mic. So here's a classic install of a couple different applications on a couple different machines. The browser comes from outside and accesses the WoW adapter. WoW adapter, of course, is a program that you can see the source for on your machines. It's written in C. It translates the HTTP requests and homes them in on specific WebObjects application instances. And so you can see how that works.

It will send it to the HTTP server. The WebObjects adapter, this confuses people who are dealing with it at first. The WoW adapter is another process that sits on the outside of your subnet or on the outside of your installation. The WebObjects adapter is in your application instance doing a similar task within the application. It is getting connections and then homing them to different sessions and different applications on different machines. within the subnet.

You can access the WoWAdapter info page, which will list for you all the running applications and a lot of statistics about the applications that are running. You'll be able to see if things are going wrong with the applications. You'll be able to see if some of the applications are not responding, if they've gone dead.

This page also can be protected by password. So, you know, anything with a web interface, you may want to put an administrative password on it just to make sure not everybody can get into it. We know early on people, you know, put things like Woe Stats pages and they were accessible from the internet.

You know, somebody running, somebody looking at your store catalog, you know, could say, you know, myflowerstore.com slash and then Woe Stats. And they could see a bunch of information about the site. This kind of thing is not a good idea. So make sure your administrative pages are password protected.

This is the interface for managing applications in WoMonitor. Again, one WoMonitor per subnet, one WoMonitor instance. Now, actually, it doesn't enforce this. If I have my way, it will, because only one instance should come up. You start the WoMonitor via the server admin application. So you go to the WebObjects service, you start the WebObjects service, and on the settings page there is a keep WoMonitor running, keep JavaMonitor running checkbox. And you check that and save, and that will keep the monitor running on that machine for you. Server admin actually also allows you to administer any number of machines within a subnet.

Actually, not just in a subnet, you know, any machines you can give the address to and that it has access to. So you can use server admin to talk to all your different machines and do that level of configuration. You can use the WoMonitor application to talk to all those machines and do that level of configuration. So it's very customizable, very flexible.

You can configure things about the application. You can configure for any number of instances. You can say for all the instances do this, maybe just for one. As I said, it's a securable web interface, and anything that you want to do in the application, anything that's accessible, you can administer via this interface. There's no secret hooks that you can only do through the command line. It really is all here. So managing the running applications. And now we're going to go to a demo. Chris Pavicich is going to show you deploying a simple WebObjects application.

and Chris Pavicich. Do you guys hear me? So as Ray said, I'm going to show you how to get WoMonitor up and running on Mac OS X server. Any better? The first thing we're going to need to launch is the server admin tool. Server admin tool is divided into two sections. On the left, there's a list of the local services that are running. If I click the disclosure triangle here next to home local, that's this box sitting in front of me here.

Wait, don't run away. Okay, so what you see on the left is a list of all the services that are up and running on this box.

Okay, so on the left, I'm going to select the WebObjects service. Right now you see that it's stopped and the monitor is stopped. So the settings tab on the bottom.

and I will go back to the overview. Now we see that the monitor is running. The WebObjects service is still stopped, so I'm going to go ahead and hit the green play button on the toolbar at the top. Now the WebObjects service is running. And if you want to get to monitor directly from the server admin tool,

and Hacker stay out. So that was the wrong password. Get the right password.

This has all been set up already. I'm going to walk you through setting it up again. So the first thing you need to do is set up a host to run monitor. And as Ray said, you should really have one instance of monitor running per subnet.

I'm going to add an instance of monitor here on localhost. Type in localhost. There's a note here that says, hey, if you're putting in localhost with the local loopback address 127.0.0.1 as the host, it should be the only host. Localhost, this is OS X, add a host, and there we go.

Our host has been added. It's available. There are no instances running. Processor description is PowerPC and it's 10.4.1. So now I'd like to get an application up and running. So I'm going to add an application called Think Movies. It's one of our developer examples. So Think Movies is the name of the app. Hit Add Application.

And there's this new instance defaults sort of wizard that you need to fill out. So we're running on OS X, so I'm going to click the path wizard next to OS X. It's going to bring up this file browser, and I'm going to navigate to the Developer Examples folder.

Prebuilt WOA and I'm going to select the executable so that path filled in correctly. And the only other thing I'm going to tweak here today is just I want to send all the output that's generated on Mac OS X to temp. And down here in the lower right corner, if you fill in any, if you change more than one of these fields at a time, you'll want to push them all together. If you just select the push icon to the right of any one field when you've changed more than one value, it'll only push the field that you've hit push on. So I'm going to hit push all.

and then back up here on the top, I'm going to press the detail view button. So. Right now the Think Movies app has been configured and Monitor knows about it, but there aren't any instances running, so... We'd really like to see that apps can be started from Monitor. So I'm going to run two instances.

And there's a dropdown here that says, on which host do you want to run your app? If we had a cluster of boxes all set up to do deployment, they would all show up in this dropdown. We only have one box here today. So local host, two instances, click Add. See that it added each of the instances. I'm going to go ahead and click the green button.

and what Monitor did there was complain that there were old versions of these apps running. So I'm just flipped over to the terminal. I'm going to kill them.

I'm going to click on one of the app instances. I'm going to stop all the instances and restart them. and Now you see the Frankenstein switches changing state from off to on. It'll take a few moments here for them to get up and running.

and Chris Pavicich. Let's see how they're running. Click on an app instance. There's our Think Movies application. Let's search for a movie. Let's see what's in the database. There's our data. So that's a brief demonstration of getting your apps up and running in WellMonitor. I'm going to turn things back over to Ray now.

Can you turn it off? No, it's on, okay, it's working. Do you guys know what pod buddies are? I think Chris and I should have just decided to be pod buddies for our microphones. When you see two people walking down the street and they each have one earphone from an iPod going to each other, isn't that cute? Yeah, it's so beautiful to see. If we had shared the mic, this might have worked better. So now we're going on to not the most simple way to deploy an application, but there certainly are reasons to look at deploying applications in J2EE environments. We provide the JBoss container on Mac OS X server.

So why do J2EE? It is a lot more complicated in some ways than just talking about plain Java applications, but it is a standards-based deployment environment. A lot of times an organization won't want to hear that a technology is from Apple or is using this great technology or that great technology. They want to hear standards, buzzwords, acronyms.

And so J2EE is a great acronym for quieting down a certain type of management. It provides JMX tools for administering applications. If you don't know what JMX is, it's Just one of the many acronyms you get to learn if you work with this technology. And as I said, buzzword compliant for selling to management.

So we're going to give you an example of this, but getting started, what you have to think about is you have to build the app slightly differently when you're building for a J2EE container. When you create the project, there's an option for enabling the J2EE frameworks in the application. You have to check those, and you have to decide what kind of application it's going to be, whether it's going to be a single directory deployment or there are a couple different kinds of packaging schemes for the war that will come out of the project.

These can be deployed on any JBoss container. For instance, if you pick the single directory deployment, it puts everything that's needed to run the WebObjects application in one directory so that it can be transported to any machine and run. Now, that turns out to be a big jar. If you want to take just one thing and give it to somebody and say, put this in your J2EE container, trust me, it'll do great stuff and it'll work, this is what you do.

and they can use standards-based JMX tools to deploy and administer the application and they don't need to worry about anything else. So you can also, if you're on Mac OS X server, you can deploy the application via the deployment tool, which is a web-based application we provide that makes it a little bit easier, certainly easier than editing raw XML for deploying in JBoss.

And you can configure it via the JBoss management application, which, again, is easier than finding the correct XML file inside of the WAR or the SAR or the TAR or the JAR. You know, you have to find these things and put them together in the right order again. The JBoss management application does a lot of that heavy lifting for you.

Okay, so I'm going to walk you through a quick demo on deploying within JBoss. Okay, so as Ray said, when you're building your project in Xcode, So there's just a few quick things I want to point out to you when you're building a WOAP for deployment in a J2EE container.

Some things to be aware of you need to look for in your project, make sure they're set up correctly. So I've got my project set up. When I built it with the project assistant, I did click the J2EE deployment option. So I'm going to select the main target for this application.

and I'm going to bring up the inspector. I'm going to double click on it. And I'm going to select, under settings, I'm going to select the expert view. This is all the keys that are getting, keys and values that are getting used to build this particular target. There are four keys that you need to make sure you have set. The first of those is servlet copy jars should be set to no. Servlet single directory deployment should be set to no.

Servlet single directory deployment license should be set to no. And this last one is sort of interesting. It's servlet underscore web apps underscore dir. Whenever we build this project in Xcode, not necessarily a deployment build, any build, it's going to build this app into slash library slash JBoss slash 3.2 slash deploy. So it will essentially be hot deploying this app every time you click the build icon.

You'll see later when we switch to the JBoss configuration tools, since this app has been built already, I'll build it again now. and Chris Pavicich. We have a list of applications available. Once the application is up and configured, it will be hot deployed. As soon as JBoss is up and configured, we'll see this app in the list of Oh, one more thing I need to show you in Xcode. Go ahead and close that.

And I'm going to bring up under the serverlet resources, under resources, the JBoss-web.xml file. This particular application is using MySQL as a JNDI service that it's resolving through JBoss. So this JBoss-web.xml file should get created for you automatically when you click the J2EE deployment tick box in the project wizard. And this JNDI name and this XML here will be big sort of block letters that says, please fill me in.

Before you deploy. If you don't change that value, unless you name your data source, please fill me in in JBoss, it's not going to work. So I just want to point out to you here, we've called it MySQL DS. You'll see that again in the JBoss tools in just a second.

So I'm done with Xcode. I'm going to go ahead and close that up. and Ray mentioned the JBoss Management tool. You need to make sure that's running on your OS X server box. I'm going to switch to the terminal for a minute because we're going to run that from the command line. And the JBoss Management app is in Library, JBoss, Applications, JBoss Management. and Chris Pavicich. I'm going to run that in the background. Whoops.

Then a second to come up and run. I'm pleased with it. Hide the terminal window. Now the next thing we're going to do is switch back to the server admin tool, and I'm going to get JBoss up and running. Again, before, services on the left, details about services on the right.

I'm going to pick the application server. And we see that JBoss has stopped. So click the big green Start button. It's going to start up. And JBoss isn't really that great at reporting back to the admin tool that's up and running. So hit refresh. See that it's running. Looks good. Click on the settings tab at the bottom. And we don't really need to change anything here, but I do want to click the Manage JBoss button here, and that's going to bring up the JBoss administration tool in Safari.

This is going to give a couple of warnings and actually these things, it's good. What it's doing, this is a NetInfo password. Your username and NetInfo password for your machine. So it's accessing it via JNI. Safari wants to make sure you know you're doing that. And then later on you'll see there's a warning about the certificate. These are good things. You want Safari to tell you when it's doing something with the security of the system. So that's what it's doing. Let me just point that out again so you guys can see the dialogue. Continue. Somna.

The first thing we need to change on this page is this isn't a development box, this is a deployment box. So I'm going to change this configuration to say deployment standalone. We've only got one box in our and Chris Pavicich, the deployment fleet here. So deployment standalone. And then I want to modify the configuration of this JBoss installation. So Java applet is going to run here.

Yes, we do want to accept this certificate. And now it's letting me know that host name mismatched. It's using a locally resolved rendezvous name. for this host, and that the certificate is from Apple, but yeah, that's all good. Hit yes. And the JBoss tools are up and running.

So let's look at what's on the local host. Click the disclosure triangle there. Let's look at the services. I mentioned the MySQL service that we were going to be accessing earlier. That should show up in this services list. and Chris Pavicich. We're going to go ahead and start the demo. The first thing we're going to do is MySQL DS and the JNDI name. We got it right.

It matches what we had in our app. MySQL DS. One thing that's missing here is when you do the service resolution through JBoss, it needs some connection dictionary information here. It needs a username and password. So I'm going to fill that in. : Actually, Chris, the username should be MySQL. Is it?

Yeah, yeah, yeah. Okay, thank you. This is the MySQL user. Oh, and it's MySQL, MySQL, Ray? No, no. The password's right. Ray can read the little stars. That's one of his talents. So, set up. I'm going to go back to JBoss. I'm going to hit Change Configuration to save those changes. And hopefully the MySQL service will set up and run correctly.

Now I want to manage this local instance here. So I'm going to click the Manage Local Host button. And I'm going to show you that the app we set up earlier for hot deployment is in fact installed and running and talking to MySQL. So this has changed slightly now. We see under JBoss, this is going to be a list of host names, or in this case, IP addresses. So I'm going to disclose that. That's this local box.

And I'm going to disclose that. And I'm going to show you that we have our new movies.war application. And this is where we have our new movies.war applications. And there's our new movies.war. That's our application that I built earlier and hot deployed. So it's there. JBoss knows about it.

Just a quick reminder. I'll show you one thing. If you click on applications and you've built a WAR file already, but you didn't set it up to hot deploy and you want to add it to JBoss, you can do it from the JBoss console here. Just click choose file. You'll get a standard file chooser dialog. Select your WAR and it'll get added. Now I want to show you that. Our Movies app is in fact up and running. Oh, it's not.

and Chris Pavicich. Thank you. I think we're just going to have to say that we didn't sacrifice a fatted calf to the demo gods. I can actually say though, because management is letting us say this, you know, they did call out specifically that the deployment is something we're going to be looking at in the future.

And so we are going to be improving these tools. We're very interested in what you all want to see in these tools. And so any suggestions? Don't file a bug that says make it work. We know that it was working and we had it working several times. So thank you. Thank you, Ray. All right.

All right, so beauty is not love. We are going to talk about what can go wrong. Things can go wrong. Amazingly enough, I know it's a shock. As smart as we are, things do occasionally go wrong. But I wanted to just list some of the things that you can do about them.

Actually, this list of database problems, host connectivity problems, and browser compatibility issues, those actually aren't something we're going to talk about because those are things you have to set up on your own. You set up your databases. The browser, we're talking standards-based HTML 4.01 now. So there shouldn't be any problems with that. There shouldn't be any problems with different browsers. What I am going to talk about is woe adapter problems and application response issues.

So I just wanted to point out the things to look at when you're looking at your WoW adapter and how it's behaving. You want to look at, you know, is your WoW adapter distributing first requests according to your policy? And actually, you know, I'm always arguing that you should use the appropriate technology for the appropriate task.

You can take a very high-tech approach to this problem, but actually you can also just hit the adapter with curl or something like that and look at what it tells you. Down at the bottom is even just a regular expression in Perl for pulling out the application number. So, you know, access your application through the WoW adapter.

Make sure that you can hit the app once, hit it again, hit it again, and that you see a proper distribution of applications. You know, if you've made three applications available, make sure that they are deploying to all three applications. So you can set the policy in the WoW adapter page to do that. You can also set the policy in the WoW adapter page to do that.

So, and then for timing, you know, just access it via something low level and you can get information about how it's responding. You know, make sure that you isolate the different parts of your system. You know, if people are complaining about an app, you know, try connecting to it directly and see what the application response time is.

You know, come out one layer to the WoW adapter and try accessing it through there. You know, oftentimes, especially if an application is being accessed through proxy servers, the problem can be very far away from your application. So, you know, make sure that before you start changing your deployment that you're gathering data about what might be happening.

So if you're having issues with Woe Tasty or Woe Monitor, So check the server admin application. There is log data that is in that interface. It shows you what it's complaining about. If there are errors in that log, it can tell you what it's doing. I just wanted to share with you sort of a low-level detail, which is that in Tiger, there is a system service available called LaunchD, and we are using that for starting and stopping these services. It's a very reliable mechanism for having an application be configured to be running all the time. If the application shuts down, it will be restarted. If the machine is rebooted, the application will be restarted. It's used for many services throughout Mac OS X and Mac OS X Server. It's very reliable.

So how you configure it is in these files. If you look in system library launch daemons, you'll see a plist files, and each of those is a different service. And the plist configures the application, gives the parameters, gives some information, what user it runs at, what group it runs at, and how it responds to different things.

And then if you're going to look at it in this level, what happens is you can use launch control, which is a command line application. There's man pages for it. If you use launch control to launch the application, you can either tell it to start the app or to stop the app.

And if you start the app, it will be kept running through reboots, through shutdowns, whatever happens, it'll be restarted. So this is a very powerful system tool that we've taken advantage of with Tiger. Ray Kiddy, Chris Pavicich One of the big things that we've done is we've taken advantage of the Tiger. One of the big things that we've done is we've taken advantage of the Tiger.

One of the benefits of our platform choice now is that we can do the more elegant things that are available to us on Mac OS X and Mac OS X server. Oftentimes we've wanted to do things, and frankly, the cross-platform story complicates the issue with other departments within Apple. So we've very much simplified the equations now.

And we're going to provide... ...a very... ...very elegant solutions for managing deployments on Mac OS X. And any input you can give about what you want those to look like, please go to bugreport.apple.com and let us know what things you want to see. And we'll definitely take these suggestions under advisement. As I said, launch control. This lets you launch or stop an application.

And then other tools. An often neglected tool is the WoW Event Center. You can see the Java doc for it. You can declare an atomic WoW event or an interval WoW event. And then you can put them in your application, give them a name. And if you want to see what various parts of your code are doing, you declare the WoW events.

And then you can access a page that will show you how many times a WoW event was hit, how many times a WoW event was hit, and how many times a WoW event was hit. What was the duration of the interval events, so that you can see, you know, in your application logic, especially the component logic, you can see a lot more about what is going on in your application.

Love is not music. So this is about scalability and I just wanted to point out WebObjects is very scalable. Scalability is at the heart of the architecture. It's very flexible. We do scale up to world class deployments. As I said, the music store is a massive application. And I just wanted to point out, you know, make sure you find your bottlenecks by looking, by getting information, and not just by guessing.

Make sure that if you see problems with your deployments, make sure that you're attacking the right part of the problem. So, you know, we make a lot of information available to you through the various tools. So, you know, try to get specific information about where your application may not be scaling. And you use a data driven and information and knowledge driven approach to solve the problem. If you don't see the information that you need to solve the problem, let us know. You know, we can make some of this information more obvious, more available.

So one thing that can be done is that all of these things can be unbundled from each other. You can have multiple databases. You can have WebObjects instances running on many, many different machines. They can be talking to each other in all sorts of complicated ways. You can have the example host5.

That's the static server page. It's only talking static resources. Ray Kiddy, Chris Pavicich So one thing that can be done is that all of these things can be unbundled from each other. You can have multiple databases. You can have multiple databases. You can have multiple applications. You can have multiple subnet applications.

It's transparent to the application how this is being done on the inside of your subnet. So don't be afraid to take these things apart, put them on different machines, have them communicate with each other, and spread them out so that you can see what's happening. If your database server is maxing out, try to fix that problem and then see what's happening.

If the application server is using too much memory, if everything is on the same machine, some of these cloud problems will cloud each other. So if your application is using too much memory, attack that problem and you'll see things will speed up. Things will be much more scalable.

So I just wanted to give a little quick checklist of scalability. Is your database as fast as it can be? Test via native command line tools and test directly through JDBC driver if you can. Is your application's EOF stack properly tuned? Again, are you maxing out on memory? Are objects being garbage collected quickly enough? Ray Kiddy, Chris Pavicich We've tuned EOF quite a bit to not hold heavy locks, heavy references on objects. So EOs are much more responsive to being garbage collected when it's appropriate. But you need to make sure your sessions aren't lasting too long and that those objects are getting garbage collected when they can be.

Are your custom WoE components tuned for performance? Use WoE events to get information about this? And is each tuned to its task? As one sees reusable components, they're very flexible, but one can use a single WoE component to do too many things. And I've seen this happen quite often where somebody sees the power and the flexibility in the WoE component layer, and then they get a bit too enthusiastic about

Static resources can be loaded from a fast web server.

Are the resources as small as they can be? Some of this seems a little obvious, but you know, it is often the obvious things that trip us up because we're down the path of developing an application. We're thinking about our models, we're thinking about our pages, and we're thinking about the abstract parts of our application. And then we get sort of tripped up by the ground under our feet.

So these are just details, but they are important and they are things that people stumble on when they're deploying. Ray Kiddy, Chris Pavicich Some of this seems a little obvious, but you know, it is often the obvious things that trip us up because we're down the path of developing an application.

We're thinking about our models, we're thinking about the abstract parts of our application. And then we get sort of tripped up by the ground under our feet. So these are just details, but they are things that people stumble on when they're deploying. Don't just test your application with the load you think will happen.

Try to test your application with the load that is so high it will break your application and see how that happens. Make sure that happens at a point that you understand. Make sure that it scales as much as it can before it starts to degrade. Don't wait for your application to be slash dotted before you find out whether it can actually scale to handle a lot of responses, a lot of requests.

And here we are at the end. Music is the best. So we just, we like to talk about the music store. It's a beautiful application and of course WebObjects behind it. And well, there are smart people working there too. So we can't take all the credit, but we can take a little bit.

So for more information, go to the web pages and documentation. You saw before the documentation is going to be updated. And we're very interested in hearing from you. I think that one of the effects of the platform choice we made is that we are going to be able to be more responsive to doing things on Mac OS X. We can be more agile now than we could when we were trying to do many, many things on other platforms as well. So there's definitely an upside to this choice that the management has made.

Related sessions are the Development Lab is tomorrow. If you have any questions, if you want us to look at your application. If you want to let us know what your ideas are and see how they can be done, come to the lab. We're going to be there from 9:00 to 12:00. Actually, if you want to see us deploy in a JBoss application and make it work, 9:00 to 12:00, we'll be there.

So the WebObjects performance optimization session is at 2 o'clock on Friday. Those are, we have some people who work at the music store, are going to be talking about the kinds of things they've done to scale up to that size of a deployment. And then the feedback forum.

If for Mac OS X server is on Wednesday. And of course, you know, you want to deploy on Mac OS X server, so, you know, you should get to know those folks. I wanted to point out the Customizing Mac OS X Using Open Source session is on Wednesday and the Java and WebObjects Feedback session on Friday. Thank you.