Hi there, thanks for coming. Boy, this headphone is interesting. I kind of feel like I should take it off and just use the force, but I'm gonna keep it on. We'll see. Yeah. Right, we're here to talk about web objects and J2E deployment. Hope everybody's in the right room. So how you all doing? Appreciate you hanging around all day. How many people have been to either of the other two WebObject 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. Thank you. I got the clicker right. All right, my name is Ray Kitty. 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 J2E container. Then we're going to talk about monitoring the application to try to find out what's going on. trying to get a sort of knowledge-based approach to dealing with your application. We want to try to make it so that when you deploy your application and if something goes wrong, 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. 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. ProMonitor, and Tomcat, also known as Apache, Jakarta Tomcat, they keep complicating the names. Axis, aka Web Services Project at Apache, and then JBoss, aka Mark Fleury PhD, so if you know him, you know it's a, that's, JBoss 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, you know, 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, 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 raised, Zappa. Okay, truth, beauty is not love.

Love is not music. Music is the best, see? 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.

Back to the talk talk. The object graph, when you're deploying applications, you have to think a little bit differently about the objects, about EOF in your application. You can get into a habit of setting things up and doing things in a certain way as you're developing, and then that will rapidly not work when you deploy. And so you want to think about these things. If you're a deployer, what you want to do is ask the developer about these questions.

And if they look at you very blankly and are confused by your questions, that's a sign. Not a good sign. So the things you want to ask about are the shared data, undo, redo, freshness, and synchronicity, and managing rights to the database. So shared data, we have classes. We have a shared editing context class. Many applications mostly read a little bit of write. Maybe 90% read, 10% write. some more or less. And a lot of apps have a bunch of static data, which is mostly static. And very often you can share those among different... You don't have to pull in a copy of that data in every session of your application. It can be shared across the sessions of an instance.

And so you do that via the EO shared editing context. So there are details about how this is done. You should make sure that when you do need to update in the shared editing context you know how to do that, or that your developer knows how to do that. You know, you can be told that the catalog that you're vending will only change on the weekends, you know, Saturday night, but then Monday morning, oftentimes they'll come to you and say, "Can we update it in five minutes?" You know, and so you want to make sure that you cover these scenarios. But if your data is mostly read, then get that into a shared editing context, and it'll cost less for the application to vend that data.

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. Thank you. Freshness and synchronicity is actually a little bit of a complicated topic.

The problem is that if you ask a developer how fresh do they need their data and how current does the data need to be, they'll say, I need it to be completely fresh all the time. Well, WebObjects allows you, the frameworks cache data and make it so that you can get data around very quickly.

But that caching introduces latency. And if you want an application that is very synchronous all the time, you can do that, and your application will behave very badly. It will be slow. It's hard to run that. You know, the natural pattern for using WebOtrix applications is to have caching and latency going on. You need to get some sense of, you know, how often the data for a particular class of users needs to be updated and how fresh it needs to be. You know, if a person comes in and is buying something off a catalog, they don't need to see a lot of other data about other users fresh. They shouldn't need to see any other data. You should be able to segment the data and you should be able to show them what they need only and leave everything else out of it.

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.

Ultimately, if you want a very high-performing app, the main theme is to tightly manage rights to the database. You know, use the session as much as you can. A lot of people use a lot of direct actions in their applications, and there are definitely reasons for doing that. But there's also a cost to doing that. So, you know, there is a benefit to sessions. And if you can use sessions right, then you can have your user interacting with their session for quite a while going through the trip through your application. And then at the appropriate time, you can get the data from their session down into the database as quickly as possible. So I've seen some of the graphs of the music store. They go to absurd lengths to make sure that everything that happens, that the data coming from the database is as accessible as possible and is redundantly stored and very much available. And they make sure that every change that actually has to go to the database goes like a bullet through. It's very tightly architected to manage the rights through the system so that there's not too many of them. There's not too many rights to the database because they're more expensive than reads. So manage the rights to your database, and it'll make your job much easier. It'll make your app much more scalable. example. 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 with one or two different sessions going on, and then you put it out and five or ten people use it, and then maybe it's a public app and it gets slash dotted. You go to the floor right then. 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. you 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 EO Modeler 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. Um, 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. You know, deployment machines, you know, it can be a little bit differently laid out than what you have on your development machine. Or, you know, you've just gotten the app from a developer. You don't know how this person has their machine set up. So, you know, you launch the app. The class path is, you know, set up in a file inside the WOA and it is in the console output. So, 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 Woe Component logic via an href binding, and then you can 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 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 had just handed you some directories, and so you don't really know if it works. Before you involve too many pieces of the puzzle, it's often wise to bring up the application and then connect to it directly. And I wanted to bring this up because it's useful, but I also wanted to say this is not what you usually do in a deployment machine. You know, deploying an app, using Direct Connect is very often not wise. But when you are trying to get the very first instance of the application up and connecting, it is often very useful to not have to go through the WoW adapter to see what minor configuration error might have been made in the application. If you bring up your application for the first time and see it return a page, then you know you have a certain level of confidence and you can go on getting it started through WoW Monitor, through the WoW Adapter, but it is very often useful to start the application and connect to it directly to make sure that the application per se, by itself, launches and returns a page and works. So this is how you do it with these flags. Again, these are not the default flags for a deployment machine, so when you deploy your app to the public, don't use these. Again, the parts of a WebObjects application.

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 WebObjectsAdapter, this confuses people who are dealing with it at first. The WoWAdapter is another process that sits on the outside of your subnet or on the outside of your installation. The WebObjectsAdapter 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 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. but 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 Java monitor 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. Okay, that's pretty simple.

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 gonna go to a demo. Chris Pavicich is gonna show you deploying a simple WebObjects application.

Can you guys hear me? I don't think my mic is on. 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. Good work, Ray. I'm projecting well enough. All right, so there's a list of services running on that box.

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, that. The default ports here are already filled in. WoTaski should run on 1085. Monitor runs on 56789. So I'm going to tick the box next to turn monitor on. Hit save.

back to the overview. Now we see that the monitor is running. The WebObject service is still stopped, so I'm gonna go ahead and hit the green play button on the toolbar at the top. Now the WebObject service is running. And if you want to get to monitor directly from the server admin tool, on running, that's a link there. And as Ray mentioned earlier, the monitor can be password protected. That's already been set up here. So I'm going to go ahead and... "Hacker, stay out." So that was the wrong password, give the right password. So the first thing you have to do once you bring Monitor up is configure it. Is configure it.

This has all been set up already. I'm gonna 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.

Then 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.

Java Web Objects, Think Movies, pre-built WOA and I'm going to select the executable so that path filled in correctly. And the only other thing I'm gonna tweak here today is just I wanna 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 gonna 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. You see that it added each of the instances. I'm gonna 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. hide the terminal, back to monitor. Start them back up again. Cool. The little Frankenstein switch has switched to on. I'm gonna click on one of the app instances. Uh-oh. I'm gonna stop all the instances and restart them. 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.

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 Well Monitor. I'm going to turn things back over to Ray now.

Can you turn it off? No, it's on. Okay, it's working. So do you guys know what pod buddies are? I think Chris and I should have just decided to be pod buddies for our microphones. You know, 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 just, 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 J2E environments. We provide the JBoss container on Mac OS X server. Okay. So why do J2E? 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 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.

We're going to try this again. Oh, hello, everyone. Okay, so I'm gonna 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.

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 blank. And this last one is sort of interesting. It's servlet underscore webapps 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. Um, 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-- It will be hot deployed. As soon as JBoss is up and configured, we'll see this app in the list of available applications. So... 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 servlet 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. Okay. 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.

I'm going to run that in the background. 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. Amen. 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. You know, 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. Thank you. Thank you.

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 gonna change this configuration to say deployment standalone. We've only got one box in our... Deployment Fleet here. So deployment standalone. And then I want to modify the configuration of this JBoss installation. So Java Applet's gonna 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 rendez... Er, bonjour 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 gonna be accessing earlier. That should show up in this services list. is mysqlds and the JNDI name, we got it right, it matches what we had in our app, mysqlds. 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. update it. 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, right? 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. I'm going to disclose applications and there's our newmovies.war. That's our application that I built earlier and hot deployed. So it's there. JBoss knows about it.

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 wanna 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 wanna show you that... Our Movies app is, in fact, up and running. Oh, it's not?

Try it again. Hmm. No, it's 8080, new movies. Let's go back and reset the password. On the MySQL service? Yeah. I didn't keep my changes. Is that it? Yeah, go ahead. Put it in again. I think we're just gonna 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, Rick. All right.

we switch back to the other screen. Thank you. All right, so beauty is not love. We are gonna 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, 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 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 WOA adapter and how it's behaving. You want to look at, you know, is your WOA 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 different things. So you want to make sure that it's actually doing what you think it's doing, that you've actually said it how you want it to behave.

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

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'll 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 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. One of the benefits of our 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 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. Thank you. As I said, launch control. This lets you launch or stop an application.

And then other tools, an often neglected tool is the WoEvent Center. You can see the Java doc for it. You can declare an atomic WoEvent or an interval WoEvent, 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 WoEvents, and then you can access a page that will show you how many times a WoEvent was hit, how many, 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.

And you can use, you know, open source tools for administering the applications. And I just wanted to show really quick, you know, has anybody here heard of Nagios? Yeah. So, you know, I was looking at it. And oftentimes, you know, one hears about some neat open source tool. And these can be insanely hard to set up. You know, it looks easy. You try it and then you're in the weeds. This is actually very easy to set up. And it was interesting that I just went in and in a very short period of time, I managed to go in and create a WoTASC-D specific check service in Nagios. So just as an example, there are third-party tools that can help you in a deployment. And Nagios scales up to hundreds and hundreds of servers, so it's a nice piece of the puzzle. So we're very standards-based, and we talk with open source tools. So when you're deploying, when you're managing your deployment, try to use the right tool for the right problem. And we try to make that as easy as we can. Let us know if things are not as easy as they could be. And as I said, the management has identified that we will try to improve this area. So we're very open to suggestions.

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, 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 we make a lot of information available to you through the various tools. So try to get specific information about where your application may not be scaling. And use a data-driven and information and knowledge-driven approach to solve the problem. If you don't see the information that you If you need to solve the problem, let us 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, host five, that's the static server page. It's only talking static resources. And then your WoW adapter is sort of your gatekeeper on the outside lets you provide a single point of control for the entire subnet.

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? 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 reusing a single component. So, you know, make sure that you know that your components are tuned for what they are doing. And you can check that with the WoE events and with the information made available.

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 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. And is the WoW adapter performing as intended? These are all things to check. And then, I can't say it enough, test for performance. If you're testing for performance, think about how much performance you might have, but then start multiplying that by 10, by 100, by 1,000, by 10,000.

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. So 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, WebObject's 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. 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-- 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.