Coming all the way from Cupertino this afternoon, to entertain you, please welcome the dream team, Stefan Reich and Han-Ming Ong. Hello and welcome to session 605 WebObjects and J2EE. I think there's two main types of developers in the audience today. Number one, the traditional WebObjects developer who is anxious to see what's going on with J2EE, how does it affect WebObjects. And the second type, hopefully the pure J2EE developer who wants to see what support we have in Macro S10 server for J2EE, what we ship, what it looks like. Thank you.

Good. So I hope you're going to answer all of these questions and switch a few slides to our roadmap. So I'm going to go over all of the new features, be they in the Mac OS and server support for J2EE or the new features in WebObjects. Then I'm going to introduce the J2EE components that are part of our J2EE strategy. I'm going to go over the development tools, especially the WebObjects development tools for J2EE. And finally, I'm going to introduce the specific WebObjects features for our J2EE integration story.

Okay, so this is the feature set that we have been working on so far. We have runtime support for J2EE 1.3, namely the JBoss container that was announced in the Mac OS X server technical overview. We have a graphical J2EE deployment tool that helps configuring enterprise applications, EJB modules, and web modules. We have a monitoring and configuration tool that helps you see and watch the load, watch the resources in your container, and also help optimize your container setup for speed and maintainability. We have written an admin plugin for the server admin.

We have a web application in Mac OS X server that makes it very easy to control the lifecycle of the application server with watchdog integration and so on. In addition to that, we have end templates prepared for pure J2EE development, namely for the EJB module, the web module, and also the enterprise application.

In addition to the pure compilation of J2EE project, we have added X-Docklet support that helps you maintain most of the deployment descriptors, all of the artifact classes in the EJB specification as, for example, local interfaces, remote interfaces, home interfaces, and so on. We have taken these end projects and integrated them with Xcode.

So we have both projects that we can use in Xcode and we have templates for additional files such as JSPs, servlets, message driven beans and so on. And last but not least, we have improved the WebObjects core container to play very well in a J2EE environment and to be completely configurable inside a J2EE container with J2EE development tools.

So that was quick. Let's go on. And I'm going to explain our story, our J2EE story. So first of all, the question, especially for the WebObjects people, would be why? Why WebObjects and why WebObjects with J2EE? So if you have been at the Java 1 conference, basically the message was Java is everywhere. And the second part of the message is J2EE is almost everywhere.

So in fact, we had a lot of customer requests coming in who wanted to have J2EE 1.3 support on the Mac OS X server platform. And this is one of the reasons why we included it. The second reason, again, is more for our WebObjects folks who have been facing challenges getting their WebObjects applications deployed in customer environments, in companies. So we have a lot of companies who basically only have a J2EE-based middleware. And this is where our integration support comes in. And basically, our new support helps you sell your WebObjects application and deploy your WebObjects application even on a J2EE environment.

So I think that's enough of the why. It now comes to how. The J2EE container that we ship is called JBoss. It is really the open source container, the open source J2EE container out there. And it has the largest community, both in terms of developer and in terms of active users.

When you go to the website, jboss.org, you will see that they feature over 2 million downloads for the last year. They have 1.5 million downloads this year alone. And you can also have a look at the major companies that are out there that are deploying their applications, their J2EEs. And you can also have a look at the major companies that are out there that are deploying their J2EE software on JBoss.

So it's a very interesting site. So we have not only taken the CVS, the CVS source space, compiled it and put it on to, on the Mac OS X server.

So here's another few points for our customization. We have identified the three most important use cases for JBoss, namely development, deployment on a standalone machine, and also deployment in a cluster environment.

So for the develop environment, we have a very quick turnaround time. So as you might know, JBoss features something called auto deploy, where the container scans the directory for updates, for removal of packages, and so on. And this is one of the values that we changed. It picks up changes immediately. We have advanced-- we have the logging levels adjusted for you to really have a look at what's going on behind the scenes and to identify possible problems very early in the deployment process.

The deploy-- the two deploy configurations, deploy standalone and deploy cluster, of course, are optimized for performance and scalability. So we have set, for example, the number of concurrent connections very high. We have made that the Tomcat logging levels are low in order to reduce I/O and so on.

The third configuration, the deploy cluster configuration, enables you to take a bunch of machines, maybe an XServe cluster or something, and deploy your website on those many machines that you have. That means you have high availability, you have load balancing, and you also have HTTP session clustering turned on by default.

In general, we have taken care of optimizing the JBoss source base and also optimizing the configuration settings for spec compliance. Many of the parameters that you can set in the JBoss configuration files allow you to trade spec compliance for speed, but we have made sure that spec compliance is the most important setting in all of the three configurations.

Lastly, we have made sure that JBoss itself has optimal JDK 1.4 support. There are many features that are optional or that you have to explicitly enable on a JDK 1.4 environment, and we have taken care of that because our standard environment is JDK 1.4, and especially for JDBC 3 for generating primary keys on the fly by the database, this is a very important feature.

And now let's talk about the integration of JBoss with Macro SN Server. So for one thing, for people who already know our Tomcat bundling, we have made sure that the JBoss bundling is done in our /library directory. We pull out all of the log files, and the log files will be written into library logs to send that location on Macro SN Server. We have pulled out temporary directories and so on. So it's very tied in into the traditional system layout, file system layout in Macro S10. And you will find whatever you want, whatever you're looking for in the standard places.

Important also is you might have seen the tool in the technical overview of Mac OS and server that allows you to configure Mail and Apache and so on. And we have written a plugin that also allows you to help configure and manage the lifecycle of the container. You can start the service, you can stop it, you can choose the configuration, you can have a look at the log files and so on.

We'll have a quick screenshot of this tool later on. Also very important is to ensure constant availability of the service is if it should fail for any reason, the watchdog process will immediately be notified and restart the container so that you have basically almost no downtime, only the 20 seconds it takes to restart the container.

In terms of security integration, we have made sure that we have integration with Open Directory, which is our single sign-on server. And what you can do is you can use the Open Directory user and password sets and authenticate, for example, web clients with it. You can make sure that you basically have only one security realm. You don't have any additional setup. You just use the Open Directory to verify Unix password, username, and password combinations.

Similar with Apache, Apache comes with Mac OS and server as well. And we have made sure that you can serve, for example, all of the static content of your site off of Apache, which is really fast. And Apache can just be configured to modify and to forward all of the requests that are, that reference to dynamic content back to our Tomcat engine, which is embedded in our JBoss container.

MySQL. You've probably seen that MySQL 4 is shipping on Mac OS and server. So we have completed the configuration and it's enabled by default. You don't have to look up port number, anything again. It just works and you can just access the database. And finally, we have LDAP support for the LDAP server that's integrated. And it's extremely easy to set it up. It's just a few matters of properties to set it up. And again, you can browse the whole hierarchy of the LDAP server and make use of the information which is stored inside.

Okay, using JBoss. Now that you know where to get it, we have two ways of starting the container. Again, the server admin plug-in is one way. The other way, which is probably more geared towards the developer, is starting it from the command line from the base directory, which is library JBoss 3.2.

And you find the whole, you can see it in the screenshots below, you can see the whole traditional structure of the JBoss installation down there. You can see in the left column, you can see two directories, 3.2 and applications. You'll find our management application and our deployment configuration in the applications directory.

Good. So far for the file system layout. Now let's have a look at the server admin plugin. On the left-hand side, we have all of the traditional services, DNS, FTP, firewall, Apache, and so on. Our application server support is just one more bullet item on the left. Again, you can see the logs. You can restart the service and so on.

I should say that all of the tools that I explained here in a very brief way will be explained in much more detail later in session 612, Deploying Enterprise Applications. So the deployment tool, what's the purpose? I've heard people complain that they don't really like migrating or writing XML files with just the DDD as a guideline. So what we do is we facilitate this approach. We take away all of the pain of launching your XML editors and configuring JBoss using raw XML, using a text editor.

The tool actually-- The J2EE application does most of the setup, most of the relationships between the different files automatically. The main purpose of this tool is, however, to migrate binary components from other application servers. For example, from WebLogic or whatever server you happen to run on. You can just pull out the application.

The deployment tool helps you to figure out what of the JBoss specific elements in the configuration is missing and helps you figure out what resources are present in your container. For example, databases, JCA connectors, and so on. And it will help you match the requested resources that you find in the deployment descriptors with the actual container resources. And we have provided much guideline. Much support to help you figure out what you need to configure for this container.

We have a verification engine that marks all of the entity beans that need to be configured or where configuration is missing as red. I will show you that in a screenshot later on. We have assisted CMP mapping, which means the deployment tool asks the container which databases we have configured, what other table names, what other column names. In the CMP mapping section of the tool, you will just match field names with drop down menus, for example, for the columns and for the tables. It's very easy. You don't have to invest much time into reading the XML files, reading the DDDs, reading the documentation.

We have two types of configuration again. A full configuration which enables you to really leverage the full capabilities of the container. Mainly for performance tuning, for very advanced setup, or you can use the express configuration, which drills down to a very limited set of the configuration files, of the configuration options, and only those that really need to be present in order to ensure a successful deployment. Lastly, of course, you want to deploy at last. Either you write the file into the directory that we recommend, or somewhere else, or you can remote deploy the enterprise archive as well.

Here comes a screenshot. You can see it's a WebObjects based application using direct to web. And on the left hand side, on the left hand side, you see the pet store, the pet store ear application, which has an embedded set of EJB modules. And you also see that some of the beans, for example, the sign on session bean there comes up in a different color than the rest. This means that the sign on session bean is fully configured. You don't have to click on it again. And you have to focus on the other ones that are marked as red.

And as soon as you update, for example, when you click on one bean, you see a pop up on the right hand side. This is the configuration that you need to fill out. Once everything is complete, it will show up as blue or as fully configured on the left hand side as well.

Again, more details in session 612. So the next tool is the container management tool. This is very important because for one thing you need to know what's going on when you're deploying a full site. You have to know which application is causing the most traffic, which is the most important one to optimize.

This is where the JSR77 monitoring support comes in. JSR77 monitoring support or JSR77 as a specification is geared towards introspection of a running EJB container. You can find out, for example, which kinds of applications are deployed on the server. You find out which resources are deployed and which services.

On top of that, JSR77 also requires that the container keeps statistics about resource usages, for example, the transaction manager or the connection pools, for example, to find out the waiting time, the average waiting time on a connection, which is very important data to do fine tuning later on. And our container support container management tool does support just that.

The second feature of the container tool is container configuration. Again, all of the configuration is thought as XML files and they are very hard to read and very hard to understand. So, we have created a graphical interface that helps you select the most vital options and concentrate on those. In your configuration settings, you can also apply all of the knowledge you have gained during the monitoring and then find you in the container based on the knowledge you gained for the traffic for your particular site.

Yeah, again, more on In Session 612 on this tool. But let me just quickly explain how it looks like. On the left-hand side, you see three different tabs, Applications, Resources, and Services. For the Resources, currently I have selected the Transaction Manager. And on the right-hand side, you can see the statistics that the Transaction Manager keeps for us. In this case, we have three different counts. We have committed transaction, we have the number of rollback transaction, and we have the number of currently active transactions. All of this is important data to figure out how much resource usage your container actually has.

Okay, this concludes the introduction of the J2EE components. This is mostly the stuff that we have in Mac OS and server and that we will leverage with WebObjects. I will switch on to the next topic, J2EE development with WebObjects tools and Mac OS and server tools. And for that, I would like to welcome Han-Ming Ong on stage.

Thank you, Stefan. Hi there. My name is Han-Ming Ong. I'm an engineer in the J2EE WebObjects team. I know you have been listening for more than 25 minutes. Bear with me for 15 more and we'll show you a demo. Okay, development tools. Here is a summary of four development tools that we have in order to help you with your J2EE development. I'll just go through quickly each one of them and then jump into more details about each. Xcode.

That's the new Apple's IDE that we have and now it's integrated with the J2EE project types, project templates and follow visits. Two, Xcode and N integration. N is the Java based build tool and Xtoglet is the metadata processor that generates files and codes for you. I'll talk about this tool in details in subsequent slides.

EO Modeler, that's the, for the WebObjects crowd, that's the EO modeling tool that we have. And EO Bean Assistant, we ship EO Bean Assistant, which is the entity bean generator in WebObjects 5.2, but now it's been upgraded to support EJB 2.0 specification. Stefan will delve into the details for these two tools.

Okay, and integration with Xcode. Now, Xcode is the IDE that Apple encourages you to use to develop projects on Mac OS X. And Ant is the de facto tool that, you know, Java developers use to develop Java projects on every other platforms. Let's have a show of hands, actually. How many of you have used Ant before? It's a pretty overwhelming response. So both Apple and you have emphasized that these two tools should work together so that you have a relevant Development Platform and Mac OS X for J2EE Tools.

So, let me say a caveat first. The developer CD that you have, you need to go into the sneak peeks folder and install the N integration tools in order to play with it. And we would love that you play with it so that you can give us feedback and we can improve further.

Okay, let's dive in now and talk about the details. We are using AND 153 to build J2EE projects. We hope to pick up the latest version whenever they have it. Current version is 153. And two, if you have done J2EE development before, especially EJB, you know that you have to deal with three, four, five Java files that are essentially boilerplate files. And all the deployment descriptors as well that Stefan alluded to. We are leveraging another great open source project known as XStocklet to help you manage this complexity.

And I'll talk more about that as well. Three, in order to jumpstart the J2EE project, we have to build J2EE. To help start your J2EE development on Mac OS X, Xcode now comes with three project templates to help you build your Web module, your EJB module, and your enterprise application. It also comes with two file wizards to help you build your EJBs and your servlets.

And during your development process, it's really essential for you to have a quick test deploy of your module into JBoss so that you can test drive it. So what happens, we optimize it so that the build product of your wall or your jar or your year goes into the auto deploy directory that Stefan mentioned earlier on. And say your computer is RAM challenged and your JBoss is installed on another machine, you can always use the FTP task. Although this is encouraged only during development because of the security risks associated with plain FTP.

A couple more quick details to complete the picture. In the developer preview CD, when you install it, the files that support your N and XTocklet integration work will be installed in developer Java J2EE. Now you want to know this because you might need to surgically upgrade N or XTocklet for speed or feature reason. We try to ship with examples to demonstrate the power of XTocklet and N. Actually, we with one now, but we will provide more as we go along.

Okay, you guys know about ANN, so we have more things to talk about, so I'll skip this slide and talk about the more interesting things. So I'm going to talk about the end scripts that comes with the project templates that we have. First off, you'll see build.xml and build.properties. These are pretty much the two files that you see in every other Java project on other platform.

WebBuild.xml is a build script that's provided by us to build your web module. And EJBBuild.xml helps to build your EJB module. And an enterprise application, which is the third kind of project template, would contain copies of one of each because they usually contain a web module and an EJB module. It has to be emphasized that these four build scripts are customizable, just like any good end build scripts. Customizable to your heart's content. If you don't like a certain style, you're encouraged to change it.

Last show of hands, who have used xDoclet before? It's pretty cool. So essentially it is a, to simplify it, it is a code generation tool and it helps you generate extra Java files, those pesky deployment descriptors based on extra information that you put into your original Java file. In the correct Java J2EE lingo, this extra information are known as metadata. And to specify those metadata, you use Java.txt. They are defined by XTocklet.

To generate the files and the deployment descriptors, you have to run it through two end tasks, WebDocklet and EJBDocklet. Now, as the names imply, the WebDocklet builds your web module, the EJBDocklet builds your EJB module. The web doclet that we have in your developer preview CD is a special build compiled from the CVS source, open source, because when the developer CD went to print, they have not released the beta build.

So it's 1.2 beta 3. I'm mentioning this because in case you need to upgrade, you know where to download and where to put them. I mentioned it before. And if you like X-Tocklet, be sure to thank them for their effort as well when you visit the website and stuff.

Here's a little diagram that summarizes the process. On your left is the original Java file. Here we choose EJB because it's pretty illustrative. And we would put Javadoc tags as defined by X-Doclet. I wouldn't go into the details of each tag because Stefan and, you know, we'll go into them and you can find them on the X-Doclet website as well.

So, suffice to say, if you put in proper and correct X-Doclet tags and run that through the EJB Doclet task, in this case the EJB Doclet task, it will spit out for you, in this case, five files. All right? These five files are boilerplate files that you probably shouldn't worry about in your normal development.

And if you want to, we will generate deployment descriptors as well, those XML files. The good thing about XTocklet is if you don't like using them, you don't have to use them. Say you are a code masochist and you decided that juggling five Java files that are essentially boilerplates is a healthy obsession, ignore the XTocklet test and go straight to the Ant test. We bid you good luck, though.

I'm going to switch gears a little bit and talk about the project templates. We assume that you have experience with Xcode, while it's a reincarnation of Project Builder, so you know, and using Ant. And we assume that you would like to learn about XDoclet. So I'm going to enumerate the major steps so that you have a clear overall idea.

First off, what you do is you go to Xcode and instantiate the WebModule project. It will give you three build scripts, build.xml, build.properties, and webbuild.xml. You can always customize them then or you can always come back later to customize them. And then you create your sublets using the file wizard. It will ask you a few questions and then generate the the file for you based on your answers.

As opposed to EJBs, actually sometimes you create your serverlets from scratch, no big deal. If you do that, make sure you observe the naming convention. Because the task that we have in the build scripts recognizes these files that end with this four kind of ending. servlet.java, tag.java, action.java, filter.java. It takes me a long time to remember these four.

So, and then you add your static resources. For WebModule, usually you have quite a lot because you have your JSPs, you have your images, you have your tech libraries, you have your third-party jars. So if you need that, make sure you put it into the static resources. The demo we're going to show will illustrate this. And then you hit the compile button on Xcode.

What happens is it will choose the default target in end, which we chose to be installed because it's the shortest path to test deploy your WAR file. It will not only run through that web doclet task, generate a deployment descriptor, compile your classes, create a WAR, and drop it into the deploy, auto deploy directory that Stefan mentioned.

If JBoss were running, it gets picked up almost immediately, and you can test drive it by firing your web browser because it is a web module. Let's move on to EJB module. Again, you create it from Xcode, instantiate it, and then for your build scripts, instead of having WebBuild, you have your EJB build.

Now you go and create your EJBs, but we really encourage you to try to use the wizards because it's slightly more complicated to create from scratch. So the wizards that we have will help you create stateless, stateful session beans. entity beans, the simple BMP and CMP, and eventually your message-driven bean. The version that you get on a developer CD might not be that powerful, but give us feedback. And eventually we'll have message-driven VIN as well.

If you do create the EJBs from scratch, make sure you observe the naming convention as well. We have to end with EJB.java, bin.java, or mdb.java in order for the EJB doclet task to work. And then you add your static resources. For EJB module, usually you don't have a lot, but you might want to add your customized deployment descriptor, your EJB jar or your JBoss.xml.

Similar story, you hit the Compile button, you will auto deploy it to JBoss. As opposed to WebModule, you wouldn't have a web interface to test it. So usually what you do is you create a test web interface beforehand to test drive it. Or you can look at the JBoss log.

This is the last slide for me. So for enterprise application, this is usually the most complicated to explain, but because we have built our foundation knowledge on the previous two slides, so we can apply that knowledge to here. And that J2EE enterprise application will usually contain a copy of one or more copies of WebModule, one or more copies of EJB modules, with steady resources, your third-party jobs, etc. And eventually the end product is something conventionally known as a year.

Our enterprise application template will start with one EJB module and one web module. So we will contain a webbuild.xml and an ejbbuild.xml. Next, you go through the similar steps of creating servlets and EJBs like what I mentioned earlier on. And then you add your static resources to the organized subfolders that you'll see later. Static resources for WebModule go to the subfolder for WebModule.

and similarly for the EJB module. EJB enterprise application does have its own special requirement for static resources, the third party jars that your modules are dependent on, for example, log4j, JUnit, blah, blah, blah. You have to make sure as per the J2EE specification, you have to make sure that the manifest files of those modules that you're going to make use of, the English came out bad, but the modules that is going to be dependent on a third party jars, make sure you amend the manifest files for those to reflect the dependency or else it won't work.

And then eventually you compile and you auto deploy and because it usually has a web module, fire up your favorite browser, which is Safari now, and test drive it. Let's go on to a demo. Demo 2 machine. So, Stefan is going to do the screen manipulation. I'm just going to do the narration.

So before this project here, I went through the steps of jump-starting it by following a how-to file. I added a how-to file to this project, which is known as XPetStore, which is a rehash of Sun's iconic PetStore project. So JBoss now should be started in the background, in terminal. And this is the project that you find actually in your developer CD. Stefan has selected the four build scripts that I've mentioned all the time. And now I'm just gonna take a look at the sources, the organization in the source folder.

So you can see EJV module and your Web module. Let's drill down to EJV module because it's slightly more interesting. You'll see an xDoclet merge there. There's a concept in xDoclet for merging points. What you have here essentially is a list of deployment descriptor XML elements that can be merged into the eventual XML file. More details on the xDoclet website. The ExpatStore source directory here is organized in the same hierarchy as your Java package hierarchy. Let's drill down all the way to domain, catalog, EJP. I just want you to take a look at this file called category Java.

Thanks to Mr. Wei Shipanu. This is the expat store that he built. So you can see a lot of xDoclet text there. The name, the type, CMP. Stefan will talk about more as well in his demo. And I just want you to remember this file and see what are the files that are generated later on. Okay? Let's close this. Let's look at the organization of the static resources as well.

So again, it's organized in a way that reflects where you should put stuff. Let's look at WebModule because it's usually more interesting. Here you see a lot of JSPs. and the majors and what have you. There's usually in your webint, you will find your tech libraries that you're dependent on as well. All right, let's close this. And I want you to take a look at the X-Doclet generated deployment descriptors.

Let's look at the one for EJB module. Now they are in red because we have not built the tool yet. That's why they are in red. When we build it, they will become black and you can look at them. So let's build it now. He will build up the browser window. Now the font is kind of small, I apologize for that because Xcode being in beta or developer preview doesn't allow us to change it. But I'll try to narrate off. So let's build it.

and Stefan brought up the terminal because he wanted to illustrate the, J2EE is the first machine to deploy the J2EE application to the WebObjects application server. It is in this order because usually your WebModule is dependent on your EJB module. Oops, I have to speak faster. So, J2EE picks it up and now it's deploying it. Let's ignore this view now. Has it been deployed? Okay. And I want to take a look at the generated files. So, let's hide everything and bring up Xcode.

Go to window. Okay. So, let's talk, look at the files that are generated for EJB module. Right now you have a C extra directory called xDocklet generated. Drill down to it. And remember the category EJB file? Now it has generated two interfaces for you. Category Local, Category Local Home. If you don't use xDocklet, you have to create, maintain, and resync this file.

Let's close this. I won't go into details of that. And now I want to take a look at the deployment descriptor that's generated by Xtalklib. So this is a perfectly normal, well-formed, validable XML file, as opposed to you firing a baby edit and leaving out the slash, for example. Let's search for category.

So all this information that you see here, they are derived from the original Java file that I showed you earlier on. The name, the EJB class. In fact, EJB class, you don't even have to put it in because it's a Java class. It draws introspection and gets it from there.

Okay, I'm gonna close this. And I'm going to show you the first page of the expat store because these are all fresh JSPs. I like WebObjects, you know, when you first hit it, it takes time to compile, so I'm not gonna run through all the demo. This works! Okay, it's working. And, um, For some of you who have done J2EE development, this is the quintessential demo that they have to demonstrate. Okay, that just about ends my part of the presentation. Thank you for your kind attention. Stefan will continue the rest. Thank you.

So we continue explaining the WebObjects tools that can help you getting your J2EE applications written and tested and deployed. So the next tool that we have is not really geared for the WebObjects developer, not really perceived as a J2EE tool. It's EOModeler. Well, EOModeler, for the people who don't know WebObjects, is a database modeling tool.

It helps you build a representation which is semantically richer than the database contents. What you can do is you can reverse engineer existing databases. You can forward engineer a database and then finally have the tool create the schema in the database. But its main purpose is to map between the world of database contents, which means tables and columns. To the world of Java, meaning classes and fields.

Finally, when you're in development mode, you can also browse the database, connect to the database, and look what's going on. So this tool builds the foundation for our entity bean generation that we have, which we implement in another tool called EO Bean Assistant. EO Bean Assistant is not really a new tool. If you have WebObjects 5.2, you have it installed already, but in 5.2, it only was geared towards CMP 1.1 or EJB 1.1 development.

Now that we ship with a J2EE 1.3 compatible container, which means EJB 2.0 as a technology is included, we can do far more than we used to do. And also, thanks to our end templates, we can make it very easy for you to have maintainability. code generated by this tool automatically.

So as I said, we have very good integration with AND. Basically the tool will just write out based on an EL model and some more information that you can enter in a graphical environment. It will create the source files on the fly, write them into the AND template directory that you selected.

It has X-Docklet integration, which means we don't create EJB XML files anymore. All of them are X-Docklet generated so that it is very easy for you to maintain your code. And if you do changes, if you just keep up synchronizing changes in the X code section, it is really easy.

We create support for deployment descriptors, which are the regular deployment descriptors mandated by Sun, but also for the J-Boss deployment descriptors. The output is an EJB jar or an enterprise module that is portable to any container. Specifically, it can be deployed out of the box onto J-Boss. We have also a command line tool, a command line back end system for this tool that you can use in an automated build. And we're going to show you this tool in an upcoming demo.

What we suggest for J2EE development on our platform is that you use EO-Modeler to model the database, to model your persistence layer. EO-Modeler, as I said, is a very good tool that also has a lot of performance or can give both the EOF stack as our entity generation tool a lot of hints on performance. For example, read-only caching attributes and so on.

. Once you have the model generated, you should go ahead and use the EO Bean Assistant to create the entity beans. Drop them right there into our project support, build them with Xcode. You can enrich the generated entity beans with session bean facades, for example, with message driven beans and so on. Our template support will help you.

Finally, what's missing in most cases is a web tier and you can either use WebObjects to access the entity bean layer or you can use JSPs and so of that. And then finally, of course, JBoss is the container to deploy on later. But as I said, everything is generated totally compatible with every other J2E container.

So you can just port your applications to almost any container. Okay, now we come to the demo. What we're going to show is basically the recipe that I showed in the previous slide applied to a project. In our case, I have already created a Neo model, and you can see that we have three entities.

We have the entity complex types, which is our main demo element, which has a very complicated mapping of the database section into the Java world. So we map. You can see we have many parameters here, many attributes. And we map to basically all of the primitive Java types that you can see in the uppermost section. In the lower section, you can see the relationships that our entity has with the two other entities.

So we have a to-one relationship with the one entity, and we have a to-many relationship with the many entity. This will show you how not only the CMP attributes are mapped very easily, but also the CMR attributes, even for a more complex case, are mapped and generated automatically with CMP2O. Let's move on and launch the BeanBuilder UI.

And we load the model and go on. We can select mapping only partial subset of the attributes or of the entities in your model. And we go on and I'm just going to show you one screen. We have prepared a mapping already. The mappings are stored in XML files and can be easily manipulated. We can also use the CMP to map the relationship mapping. So what you can see here is you can edit the package name, you can edit the class names of all of the files that will be generated.

You can either generate CMP beans or BMP beans. And you have a variety of options to generate the two different types of beans. Again, we recommend using CMP2O now because with the relationship mapping, it is so easy. Good. Let's quit here. And we're just going to show you the command line version.

It will run through the EO model and create the three files that we are looking for. But first of all, obviously we have to create a new project. We create an EJB module to show you how the two technologies are integrated. Now that we have a new module, unfortunately we have to get Xcode up and running with the new font.

And then we can switch to the terminal and show you the command line version of our tool. So the only thing that we're going to do is we launch the tool, give it our EJB specification as an XML file. You see the file EOB.xml. and we're just going to discard a bunch of not really useful messages.

As you can see, the tool is implemented as a WebObjects application. So we leverage the component layer to make sure that

, and we have a mapping of one entity in the database to one file on disk to one entity. Okay, let's have a look how this looks like in the n-template with Xcode.

We have put all of the beans into the demo package and our main important bean is the complex types bean. So again, xStocklit makes it very easy for you to write maintainable code and to avoid having to specify duplicate information in two places. In this case, we would have to get information of the class names of the local and remote interfaces and so on in the actual Java files, but also in the deployment descriptors. And also in the JBoss-specific container descriptors, which is very annoying.

So you can see the EGB tags for xStocklit. Those are the tags that will, or this is the information that will end up in the EGB jar XML. And when we scroll down a little, You can see that we also have JBoss specific attributes that will end up in the JBoss specific files.

, and I'm going to show you how to deploy the application server. Even if you don't want to deploy on the application server, you can still leverage all of the attributes. You can just insert the attributes that you need for WebLogic or whatever Ong, and the X-Docked engine is not ready yet for the advanced set up but it will get there before we ship.

Let's go down a little and have a look at the attribute to -- or database As you can see here, we automatically include every single attribute you found in the entity as a getter and setter method in the bean. This is a spec requirement you can get around except for the case that you have a read-only attribute.

So we generate all of the necessary information to generate the deployment descriptors and also the performance synth for the JBoss container. Then let's go down a little since CMP attributes are really boring. We go down and have a look at the CMR fields. The CMR fields are the way how relationships are mapped in CMP2L.

Instead of having an integer, for example, or a long foreign key that points to the real entity, they are mapped again as local interfaces. And you can see that the relationship setup is a little bit more advanced and has quite some more code necessary for CMR fields, both in terms of reading and writing. So this code that we generate automatically is really a big help.

Okay, so what we do now, I think we are through with it. Let's just compile it. Let's bring the terminal window up and see what JBoss does. J2EE, and then we compile it and you see it is ready for deployment. You don't have to change anything anymore. Especially you don't have to use the deployment tool to manually go over and figure everything out.

And this is because the EO model, which is the back end store, has enough information for us to generate all of the required information. And again, it picks it up automatically. It generates the tables as necessary. You can also tune it to have it generate indices and so on. Okay, let's move on. The demo is ended.

We go to the next slide. And we go on to the section that most of the WebObjects folks are probably most anxious to Our integration story is this. Our server adapter, which is not really new, we have been shipping it since WebObjects 5.1, is the central point of the J2EE integration strategy.

the solid adapter is basically a framework that you pull in into any web objects application and It enables service support it has custom build scripts that create all of the hierarchy which is necessary for a almost dot war deployment and It pulls everything it basically put everything together for a j2e container to deploy it Now the one thing that was missing in the previous releases was the ability to have a pure jar representation of the web objects application and That we have added in the form of job on those a job on it is more or less a framework inside a jar many many people have been asking that for a long time and Now we have it and this enables us to vend web objects application as the traditional dot war file or as a enterprise application We have enhanced the NSLog interface with an NSLogger implementation that is capable of using an existing NSLogger or NSLog4j logger as the backend. This is especially important for the JBoss container which uses Log4j as its native logging mechanism.

Log4j is integrated with the container and you can use the administration tool to look it up. The other important gap that we bridge now with the upcoming 5.2.2 release is our configuration story for properties and for EO models. The problem is that we have a lot of data that is not yet available. We have a lot of data that is not yet available. We have a lot of data that is not yet available.

In the past, we used to have the properties based on the system properties, which is especially bad if you have multiple applications launching at the same time with conflicting settings. This has been remedied with our JNDI property configuration. Similarly, we used to have a problem where if you have an EO model and you have a database configuration set up, especially for the .var deployment, this is extremely annoying. This has been remedied with our JNDI property configuration.

Similarly, we used to have a problem where if you have an EO model and you have a database configuration set up, especially for the .var deployment, this is extremely annoying. Because you would have to unpack the jar and then launch an editor and type in the real database for the deployment scenario. And that's extremely annoying. So this is a thing of the past as well.

I also want to highlight the additional features that you get by deploying a traditional WebObjects application on a J2EE container. And for one thing, the background is you can use all of the capabilities, all of the features of the traditional server specification, which means you can use filters. Filters are traditionally used for authentication or compression or whatever else.

You can use EJBs that you maybe get from third-party vendors that you develop in-house. You can use JDBC. You can use JSTA for enterprise information system. You can use JMS, for example, for asynchronous messaging or to access message queues and so on. And also, the transaction manager is always available in a servlet, which means you can have multiple resources in the same transaction.

And either roll back all of the changes automatically or commit them all at once. The other set of options that are very appealing, I think, is integration of security, which means you just write your application without a login scheme required, and you can make use of the container security.

And again, we have included modules so that you can access and verify user password combinations with our Open Directory server. . It is very easy to have one, if you have only one middleware, one infrastructure, you have one place where logging occurs. You have only one place or one container, one process to watch. So it is basically a -- it makes maintenance and running a J2EE store way easier. So those are the additional , and the latest developments in WebObjects application on J2EE.

These are some of the advantages you get out of the box when you deploy your WebObjects application on a traditional J2EE So this is an example of using a J2EE resource in WebObjects application. I'm not going to talk about this in much more detail because this is traditional J2EE programming. It's nothing special for WebObjects. You can use it out of the box. There is no call overhead, so there is no extra network access because everything is in process.

So the way to get access to an EGB or you can get access to the transaction manager or getting access to JCA or whatever is you create a new initial context. You look up a certain string where you know the resource is located. You narrow it down to the right type and then you're done. You can use it.

Let's have a look at the JNDI property configuration that I talked about previously. So the servlet adapter creates a template for a Web.XML descriptor for the servlet. And there, We use the environment entry XML sections to specify our property definitions. So all of the documented properties that exist in the WebObjects application container are documented there and have their standard value there, which means that it's very easy, for example, using our deployment tool or using the deployment tool of, let's say, WebLogic to change the configuration right there. And again, since JNDI is capable of having a thread-local definition of the whole environment, there is no problem if you have multiple applications, multiple WebObjects applications starting up and using different properties.

The deployment is easy because you can see in the description elements, you have a description of what this property does, you have the name, you have the value, and with the type information, deployers can easily figure out what the correct values are and what the possible values are. Very similarly for mapping data sources and for making sure that your EO model or that EOF can find data sources that you configured in your EO model, we have a similar setup.

So in addition to the environment entry that we have to define to do the actual mapping, we have a mapping of a resource reference. This is an indication to the container that we are referencing a database in our server environment. And we are declaring this reference and we are saying, okay, we will be using this under the name JDBC default data source.

In the second layer, we have an environment entry which the EUF stack will use to actually do the mapping. You can see we have an element called movieDB. And this movieDB will be, we assume, in the connection URL section of the EU model. And this key makes sure that we can map the moviesDB to the environment entry. You can see JDBC default data source, the lowest entry.

And we can map the movieDB to the environment entry down there and map it to the definition in the uppermost entry. So we have basically a two-step mapping mechanism for accessing data sources. And this is the final step basically in making sure that WebObjects application can be fully configured using a J2EE deployment tool.

Okay, and that was it. So what was important? For one thing, I think one of the very important part is that J2EE can very much benefit existing WebObjects application. And that J2EE really is not your enemy anymore. It's your friend. Because it cannot deploy on, for example, .NET systems. But you can deploy on J2EE systems.

And also, I think WebObjects can benefit J2EE. You have seen that our tool set can greatly help you develop your J2EE applications on WebObjects on Mac OS X server. And then finally, I think with all the integration work of the many pieces that I introduced today, we have a very good story and that I think Mac OS X server is the best place to develop and deploy JBoss applications. Thank you very much. That was the presentation.

I'm just going to go over the roadmaps and the end titles. Very important is session 612, enterprise application deployment, where we go over all of the tools in much more detail and explain many more things that we just haven't had the time for today. WebObjects reusable components for the Web tier, very important.

WebObjects UF advanced topics. WebObjects creating web services, very important if you need to interoperate with .NET systems, for example. And then who to contact, Andreas Wencke of course, Bob Fraser and Catherine Wenck are our main address, our main contact persons for the WebObjects product. And we finally have Apple Care Enterprise Services if you need more help getting applications out.

And these are for the DVD library. Don't type them up. They are all in the URL section that we will publish on the website and the DVD. Important, I think, is the JBoss website. There's actually two addresses for the JBoss website. One is JBoss.org, which is the commercial arm, basically, of the JBoss project. And the other one is more geared towards developers. It's on the SourceForge site. Tomcat and X-Docklet have their own websites. X-Docklet website is really very important because there are so many X-Docklet tags and you just can't remember all of them.