I know it's early and it's Thursday, and I guess a lot of people might have stayed up late watching Lord of the Rings last night. So I'm Jeff Glasson. I'm the manager of the WebObjects Core Frameworks team, and I'm going to be talking for about 25 minutes about the EJB features that are part of WebObjects, and then I'll bring up Stefan Reich and Arti Wilhout, who will go through some demos.

Okay, so what kind of--this is not an intro course. We're going to make a few assumptions that you have a basic understanding of WebObjects that you should have gotten this week so far if you've attended the other sessions. And also, I'm going to assume that you have a basic knowledge of what EJB and J2EE is. This is not an intro to J2EE or definition of EJB terms. We're just going to talk about the integration of EJB and WebObjects and what we've done.

What we are going to go over, though, is how EJB and EOF are complementary, not competing technologies, and how having an EJB container benefits WebObjects applications and you, the developers. And I'm going to try to get you to understand how to develop and deploy EJBs using our tools. So again, we're not going to cover how to design beans or how to implement beans in general or go over some J2EE design patterns or sun blueprints. That's an exercise for the reader.

So here's the order of things. We're going to go over some of the strengths of EOF and EJB and how they complement each other or compete, as we'll discover. We'll go over the specific EJB container implementation that we put in WebObjects. We'll be going over how we integrated that into the product. We'll have lots of demos, and then we'll go over some tips and tricks for debugging, and then we should have time for Q&A.

You'll have to excuse me. I'm getting over a cold, so I may be coughing a lot during this. So when you talk about EJB, you talk about there's a number of versions of EJB that have been shipped by Sun. What we've done is we've bundled an EJB 1.1 compatible container with the product.

The reason we did that is that right now the current component marketplace out there is based on EJB 1.1 beans. And the primary driver for us, including EJB, as part of the WebObjects product, was for you to be able to take pre-written beans and integrate them into your applications. One important thing to note is the container is not Sun certified, so we are believed to be EJB 1.1 compatible, but we are not J2EE compliant.

So, if you went to the intro to EOF session, I believe it was Tuesday afternoon, you kind of got an overview of what EOF is. There's some more EOF sessions later in the day today, but I wanted to go over some strengths that EOF brings to the table. One of the big things is that your business logic and your EOs are completely data source independent.

If you've used EOF, you know that you don't have to change your code at all if you're writing, if you swap your database out. If you want to talk to JNDI, you don't know that it's JNDI really in your business logic. We hide all the database specifics, such as SQL generation and primary key generation. You can change your schema, meaning edit your model without changing your code. So you can add a new column, generate a table, your business logic necessarily doesn't have to change.

Relationships are handled automatically for you. As you've seen in the real estate demonstrations, you can have listings and agents and customers. And the relationships and the joins are all handled for you automatically by the EOF frameworks. We have a great set of rapid development tools. The direct-to-web, direct-to-Java client, direct-to-web services are good examples of that. And let you prototype and develop applications very quickly. And another big strength of EOF is the model's been optimized for in-process use.

What I mean by that is that We have really good caching, and we assume that everything happens in a single application. So we can batch up requests to the database, and we can be very intelligent about how we query the database and keep a lot of state around.

So what about EJB? So EJB has got a very strong transaction security model. What that means is they have, the architecture's been designed for distributed two-phase commit transactions, and corpus security's built into this, and all kinds of other bigger enterprise scale models. It's been designed for multi-client remote access. Another reason there's two-phase commit there is you can have really distributed things and everybody can talk to it, and the transaction manager and the EJB container handles the concurrency for you.

You get a lot of access to third-party beans. There is an emerging marketplace out there. Shopping cart beans are starting to pop up. SAP's got beans, for example, to talk to them. There's a number of things that you can just plug in and drop into your application without having to write it. And then there's other data sources that you can access through that, such as using the JCA architecture.

I think SAP, again, is another example of what they have there. And also JMS is possible also. It's built on top of RMI IIOP, which allows any programming language client to access it through a corba-like interface. And the biggest strength is it is considered standard as far as J2EE is concerned.

So why do we add this to the product? Well, as you saw, there are different strains. They really are not the same. Yes, they're both ways to access data from an application, persistent data, but it is not, you don't use it the same way. So what we wanted to do is we wanted to leverage the existing EJB component marketplace and allow people to take these beans that are starting to appear and plop them into their WebObjects application. It also complements the servlet support that we added to WebObjects 5.1. So if you are a J2EE customer already, you can deploy your WebObjects application as a servlet, and it makes perfect sense that you would want to access EJB and some other J2EE services also.

And this also gives us a chance to provide a complete solution from Apple so you don't have to go out and buy someone else's container if you don't want to. So you can take Tomcat and Mac OS X Server with WebObjects 5.1 and have pretty close to a J2EE compatible solution. Almost said compliant, which would have been a big mistake.

So what did we choose? We investigated a lot of various solutions, including writing one ourself. But as you guys probably know, it's pretty complicated, and we would need a large engineering staff to do that. So we looked at what was out there in the open source world and the commercial world and tried to weigh into what we wanted.

Some of the requirements that we needed were that the container needed to be self-contained. And what that means is that we wanted a pluggable container. A lot of the open or freely available or even commercial products out there today, their EJB container is very tightly integrated into their application server and not easily separable.

We wanted to make sure that we were able to keep the Web component model that we have as part of WebObjects that you guys have known and loved for the number of years. And so it was very important to us that this was a modular, pluggable, extensible container that we could easily drop into the container. That we could easily drop into the existing product without a lot of rework and compatibility problems. And we really wanted RMI IIOP support for that also, to allow other systems to talk easily to the beans.

So that really only left this one choice, as far as we could tell. It's called OpenEJB. It's an open source project. It lives on SourceForge. And it is a standalone EJB 1.1 compatible container. And all of the services that the EJB container requires are pluggable by us, the integrator. What that means is we were free to choose the transaction manager that we wanted, the orb that we wanted, the persistence manager support, and all of the associated services we were able to pick and choose and integrate that into the product. It has a rapid development mode.

That means that you are able to quickly turn around and iterate on your bean. That's actually something that's not in WebObjects 5.1 but is planned for a forthcoming release. It also has a pretty efficient small footprint as far as EJB is concerned. It's not very heavyweight. And it does come built in with the RMI IIOP support. Excuse me.

So what did we pick for services? These are also open source projects. We picked OpenOrb, which is a Corba compliant orb. Tyrex is a transaction manager. Tyrex is actually used in a number of other commercial products, including JBoss, and I think Sun uses it in some of the Netscape stuff.

And Castor is a persistence manager, which allows us to manage database connections. Tyrex and Castor kind of interplay with each other for connection pooling and transaction management. So what OpenEJB is not is it is not a product that competes with WebLogic or some of the other heavy duty commercial grade J2EE servers. It really is intended for you, the developer, to develop beans and prototype and test beans or use it in small deployments.

So kind of go over a little bit of how we plug this into the product. At the tops of WebObjects application, the big box in the middle is kind of an illustration to try and show what OpenEJB is. So when we talk about an EJB container, we're really talking about multiple containers.

There are different bean types, as you may know, and EJB 1.1 supports four different types of beans. So stateful and stateless session beans, and entity beans of two varieties, container managed persistence and bean managed persistence. And so those all kind of live in separate spaces in the big EJB container.

The EJB container talks to transaction manager services using JTA, and it talks to other resources like the orb. And up on top, you can either talk RMI IOP to your application, or plan for the next release is an intra-VM, lightweight, fast, low-latency thing if you want to just have a single process talking to your container. And I think I'll go into that a little bit later about how we actually launch the container.

So the container, actually, when you start-- instantiate a container in your WebObjects application, we actually start the container in the same VM as your WebObjects application. which means you have low latency to talk to the beans. There's no security issues because you're not really dealing with requests coming in over the network. You're in complete control of everything. And it's real simple to deploy. You deploy it just like you would deploy a WebObjects application. Just launch it or deal with monitor and task D.

Excuse me. So we also, in addition to supplying the container, we provided a number of new tools. EJB components are actually represented as frameworks to match the web component model and the other frameworks that you're familiar with if you're a Cocoa developer or Mac OS X developer. We've added assistance to Project Builder for helping create beans. We've added support to the build system to generate the deployment descriptors and the configuration files, and we'll go into that in excruciating detail during the demos.

We also, as I mentioned earlier, start the container automatically at launch time for you. And again, we'll go into a little bit more detail of that later. And we provide a tool that's run by the assistance called OpenEJBTool that actually generates the XML deployment descriptors and the configuration files, or sorry, generates the configuration files for the container out of your bean deployment descriptors. And new, which we'll preview for you a little bit later, is a new tool called EO Bean Builder.

And what that will do... It'll allow you to generate entity beans from your EO models without you having to write any code at all. It'll actually do all the deployment descriptor generation, all the class file generation for you, and give you a fully functional entity bean without you having to write any SQL or wonderful JSP code. Or, sorry, EJB instantiation code.

So why put the EJBs in a framework? In addition to it being consistent with the way the rest of WebObjects applications are developed, we wanted to make it very easy for you to just drag and drop it in Project Builder. So... A component in EJB should be thought of as a framework in the Mac OS X project builder model.

and it works just like any other framework. You just drop it and add it to your project and Project Builder's build system will do the right thing. There is a new project type we added in Project Builder that allows you to create frameworks. We'll go through that in the demo. One important thing is there's no container-specific information contained in the EJB framework.

And so what that means is if you build an EJB framework using our build system and our tools, you're able to take the generated jars and deployment descriptors from that framework and put them and move them over to a different EJB container. We generate separate jars for interfaces and implementation, meaning the server side and the client side. And as I just mentioned, the jars are exportable to any container.

So we actually can do beans two ways. We can import existing compiled beans with an assistant that lets you specify jar files. And then the project builder will then--the assistant will then create the necessary framework and associated deployment descriptors and all the other infrastructure that project builder needs to recognize it as a framework in a bean. Or you can develop beans from source. You can start as an empty framework and create whatever you want from source, any of the four bean types.

So how do you import a bean? You can actually have more than one bean in a framework. You just specify them in the assistant. We'll go through all this in the demo later. You specify beans in the assistant. It'll merge the jars and the deployment descriptors and all the fun stuff, and you can deal with it if you want manually afterwards. But we actually do a pretty good job of merging the deployment descriptors and letting you just drop things in without having to modify them. It'll generate the RMI stubs if necessary. It's actually an option.

We make it an option because actually the RMI generator, the stub generator, actually is a fairly time-consuming process, as you'll see during the demo. And if you're doing the intra-VM deployment for rapid turnaround, you probably don't want to wait the time for those stubs to compile. One of the new things we're thinking about adding for the next release is a hook to let you add a bean verification tool.

We don't actually ship the verification tool, but it's available from the Sun Reference implementation. But you can... What that verification tool does is it makes sure all the right things that a bean requires in the interface are properly in your bean, things that can't be checked at compile time. And it generates a framework ready for you to leave, ready to use and drop into your application.

So if you want to develop from source, again, we have assistants that create the template classes for all four of the bean types. PB maintains the deployment descriptor for you. And again, you have an option of generating RMI stubs if you want. And again, there's a hook. We're planning to generate verification tools. It's actually probably more important to verify beans that you're writing from scratch than beans that you've bought or have precompiled.

So how do you create an app now that you have these beans in the framework? There's an option, as you've probably seen if you've been in some of the other sessions where we've been going through creating apps, where we've been kind of glossed over. There's a little check box that says "Deploy as an EJB container." So what that does, if you check that box on your Web Application Assistant, is it will add all the required EJB frameworks for runtime, and it will create all the container configuration files in XML that the container needs to run, and then it just adds them to the project for you.

One important thing to remember is in order to best make use of this, you should make sure that your bean frameworks are all compiled first, because the assistant needs to have the deployment descriptors from the bean frameworks in order to really generate as best it can the other XML configuration files.

So, as I mentioned earlier, we start the container automatically when you launch your WebObjects application. And the way we do that is that's actually another framework called Java EJB Activation Framework that its initializer will actually launch and configure the container for you. It's used whether or not you're using intra-VM mode or RMI mode. There's a lot of options to control the container and logging, which I think we will show at the end of one of the demos.

OpenEJBTool is a tool that we wrote that runs at build time, excuse me, at assistant time, that creates a deployment descriptor for the EJB container, or sorry, creates the configuration files that the container needs. The deployment descriptors are actually already created in the frameworks. There's a slide in a little bit that actually shows all these wonderful XML files that get generated for you.

It also has templates for the other XML files that are needed, such as things that can't be filled in automatically, like your database connection dictionary information, or specifics for container managed persistence that you actually need to fill in by hand, like which column in the table maps to which field in your CMPB.

So here's a list of the files that are generated for you. There's actually five files that manage the container. Five, not four. There are two that are required in all cases. The names are rather long, but you shouldn't have to worry about them. The top two, the Transaction Manager Configuration, is really kind of an overriding thing that manages TIREX and its connection pooling. OpenEJB Configuration is the overall container management, which specifies which beans will be deployed, other things. And we'll go through the XML files.

Not in too much detail, but we'll show you the files during the demos. If you do container manage persistence, there's a number of other required files to specify data sources and specify tables mapping to fields in the beans. And those are the ones that you're most likely going to have to tweak by hand when you deploy the beans. We fill in placeholders for you, so they're fairly obvious for you where it needs to be edited.

So what are some limitations with what we have today? I guess the biggest limitation right now is that EOF and EJB are really two separate things in this release of the product. They don't understand each other's transactions. And what I mean by that is that EOF has a very strong caching model in the editing context, and it doesn't talk to the transaction manager at all.

And so if a bean comes in and modifies a database table out from underneath the EOF side of your application or a different application, you potentially have stale data. It's pretty much the same problem you have today if you have multiple instances talking to the same database in EOF. And I think Steve's going to be talking about something with that in the advanced EOF session later this afternoon on how to deal with optimistic locking failures and concurrency issues. So you might want to come back for that.

I think it's 5 o'clock this afternoon, right? So because of this, we don't support writing EOF code inside your EJBs. If you're going to write a bean, you're going to write a bean using the J2EE APIs today. You probably can get away with a little bit of EOF code if you're really careful and know what you're doing, but it's real easy to get into trouble right now. And so we really do not recommend you doing that.

And again, the last bullet point to drive it home is that there's no notifications at all between EOF and EJB, and that's the reason we don't recommend mixing these two things together right now. So that's kind of the overview. I wanted to bring up Stefan Reich and RD Wilhoyt. And Stefan's going to talk through some demos while RD drives them.

Thank you, Jeff. Good morning and welcome to the second part of our session, the technical overview. We will go through three demos in the next 30 minutes, and we will show you the everyday use of the product. So let's start with the first demo now. We will bring up Project Builder and create a new EJB framework.

So as Jeff mentioned already, we have a new framework type called EJB framework. And we create a new one, fill in the blanks here. And also we have two choices to create an EJB framework. One choice is to create a development type framework from source. The other one is to basically deploy an EJB component that you bought off the shelf from somewhere. So for this first demo, we will create a new one. We will create a new source file here.

And this screen shows you the project builder support for development. We have four different bean types, of course. The stateless and stateful session bean, the CMP, and the BMP entity bean. And for this demo, we just use a simple stateless session bean. So of course we can fill in the name and the package name. And let's have a look at what project builder renovated for us. So we have three files that were created automatically. We have the bean implementation, the remote interface, and the home interface. So let's have a look at the bean implementation first.

As you can see, we have the necessary EJB create method. We have all of the methods that are required by the session bean interface. And there is nothing really interesting here. It's just a simple state of session bean. And we will just uncomment the code that's automatically basically serves as a template for you to remember how to pull in business logic. So we uncomment this, and we move on to the remote interface.

The remote interface is, as you know, the place to place business methods, business logic. And this is, of course, empty because Project Builder doesn't know by default how What business logic you want to implement, unless it can read your mind, and project builder is definitely not there yet. So, let's uncomment this one method. and move on to the home interface. And of course, that's not very exciting either. It has the create method, the standard stateful session bean create method that takes no arguments. Now let's have a quick look at the deployment descriptor.

As you can see, Project Builder already filled in all the necessary information. Since we have the templates ready for every single bean, Project Builder knows enough to fill in everything that's required. And now let's simply hit compile. We move on and create a new WebObjects application that will link against the framework and call into the bean that we generated. So again, we fill in the project name.

And Jeff already showed a slide that covers this option, deploy as an EJB container. What this does is it will fit in a couple of predefined frameworks already and make your life easier. Let's check that. And we skip all the web services support. This is not the session for web services.

And for the EOF adapters, if you use EOF and EJB side by side, you need to select JDBC adapter. We are using only EJB here, so you don't need it. Now, as you can see, Project Builder already added the necessary frameworks for EJB support. We have the OpenEJB framework, we have the activation framework, and we have all of the other pieces that are required for the EJB to work. The only thing we are going to add now is the business logic, the framework that we just created. This will enable Project Builder to create all of the necessary container files so that the container can be configured and launched.

That's it, finished. Now the first thing that we have to do now is to change the database setup. We have only the stateful session bean. We don't need a database, so we will just remove the database template that Project Builder created for us. There we go. And now we will add some demo code that will actually look up the bean and call the hello method that we created on the StatefulSession bean.

So after we compile and run the application, we will make use of the rapid development, the rapid turnaround support that's present in WebObjects applications. And we will just type in a little HTML text and connect. Connect the HTML with our EJB. We just use a whole string for it that will actually call into the main component and extracts the data and displays them in our browser. So the application is running already. The first screen was blank. The second screen is blank.

You're trying to get me in trouble. Okay, so look, it's almost working. And we will just consider this demo to be finished. So that shows you-- Rebuilding. So the essence of the first demo is you can create an EJB framework from the source template. And then you use it in your WebObjects application. Set up the project right from the start. Yay! You set up your WebObjects application right from the start to link in the right frameworks, and that's all you need to do. So we move on to the slides again. Thank you, Arlene.

Jeff already talked briefly about a new tool that we provide with hopefully the next available release. It's very awkward to hand program entity beans from your database layout. And that's exactly what EO Bean Builder does. It basically takes a database layout that is represented in an EO model, and it generates all of the files that are necessary to deploy your database schema to convert it into an enterprise Java bean.

So we have a wide range of options to translate the model into an EJB. and we will go into details in the next demo. Currently, there's only one major limitation of the tool, and it cannot handle relationship-- that is, it cannot handle relationships automatically. The two will try and make the best effort to get you as far as you can, but after that you have to model the relationships by yourself. And we will just demo it right now. So we will take the EO model that you see here.

So we move on and launch the tool and load this specific model.

Here we go. We select the only data type that we configured, the only entity, and now we come to the fine-grained setup for the EJB. So as you can see, you can change all of the class names that are generated. You can control some-- For project-based options like the package name, you can add a legal disclaimer or an RCS ID or whatever you want that is prepended in every file.

Also, it's very important for you to choose the primary key class. So if you have an integer representation of your primary key class, you will probably want it to map to the Java integer. If you have a component primary key, you need to map it to the primary key class that will be automatically generated with all the primary key attributes.

Then we have a larger section on how you can configure your BMP support. And in the first box, yes, we want to generate a BMP file to show off What ugly code you are spared to program. We are not going to change the class name. You can configure the JNDI data source name to something that is more

The next checkbox would enable you to reuse business logic that you implemented in a CMP version of the entity. And just by inheritance, you wouldn't need to write all your business logic once again in the BMP version. So we don't care about this now.

The third major option is controlling support for data access object classes, or DAO classes in short. As you all know, this is a Sun Blueprint pattern that allows you to apply database-specific optimizations for your BMP entity beans. And we want to show this, so we check it. And of course, if you need a findAll method that finds all of the entities in your database table, of course, your bean builder can help you there. And let's check it. The CMP support is very short. There is not much to configure here because it's really quite easy. And we are finished with this week.

So the next step is to actually choose a directory, and your bean builder will dump the files in there. So the idea is that we have tight integration with Project Builder, and that we use an empty framework that we already pre-created. to hold all the files so that we can easily rebuild the project and basically are ready to deploy the bean. Okay. So the tool is a little bit verbose on-- it shows you what it does, and it's happy. Very good. So we are happy also. And we move on and have a look at all the files that have been created by the tool.

So we first start with the remote interface. The remote interface contains, of course, all of the getter and setter methods for each attribute. Except, of course, for primary key attributes and read-only attributes. So, of course, all of the methods follow the Java Bean convention with Prepend of Get and Set. So that's not very exciting. So let's move on to the BMP bean.

So we selected the generate DAO class option. That means now that in our BMP implementation, Every database access will be delegated to our DAO class. So therefore, this implementation is relatively empty. and contains only the fields that have been generated that are mapped to the attributes. So we have two EJB create methods, one that takes only the required arguments, and one that takes all of the arguments of our entity.

Then let's go, we have our findAll method here. And let's move down to the setEntityContext method. This is how you declare the specific database optimization or database-specific DAO class in your project. In this section, you see that the bean is looking for an environment entry called param DAO class name. It will generate, it will instantiate whatever class name you configure here and use it as the DAO class.

So we actually implement or we generate two different default classes. One is the default Non-optimized version and currently we create also an Oracle optimized version. Now let's move on to The JDBC DAO implementation. So as you've seen, EJB create method, EJB load, EJB store, all these methods are delegated to the DAO option--to the DAO object. And here we have the full beauty of SQL and JDBC.

This is what the tool does for you. It generates all of the nasty code that you don't like to program yourself. And of course, since this is generated code, you don't need to debug it. You can just use it out of the box. And you've seen it took you like five minutes to configure it from your model to the bean implementation.

Okay, I think that's enough nasty stuff. And now we move on to the Oracle version. So, This class adds automatic primary key support to our generic JDBC implementation. So your business code doesn't have to deal with this at all. What it does, it uses an Oracle sequence to select automatically the unique primary key, primary key code. and calls in its superclass, the generic JDBC class, and finally does the create method, does the creation of the bean. Good. Let's have a look at the deployment descriptor.

Of course, the tool knows everything that's needed to generate the two entries that are present in this deployment descriptor, one for the BMP version of the bean and one for the CMP version. And here you can also see again how you set up the JDBC, the environment entry to configure The actual class that's used for the database delegation.

So in our case, of course, we use the data type DAO JDBC, the generic JDBC class. Then let's quickly browse the CMP version. All of the CMP fields are declared here, everything that is needed for deploying the bean. We can have a look at the transactional attributes. Also, we provided a default.

So here are some development tips that we would like to share. We have seen that EOModeler is very suitable to model your database schema and that it provides access, for example, helpful functions, for example, for primary key generation. We've seen that in the Oracle case. And we would encourage you to use EOModeler even in the--even for EJB development. After you created your EO model, we encourage you to use EO Bean Builder. for entity bean generation. EO Bean Builder will really save you a great deal of time and even more time on debugging that you don't have to do.

We also recommend to basically make it easier for you to resynchronize possible schema changes to implement all of the business-related constraints, for example, on on data values in session beans. That way you can easily resynchronize and you don't have to change, you don't have to start and maintain the code that's generated.

Finally, and I think that's a very important point, we encourage you to use a deployment verification tool. Although our container doesn't come with one, there is one freely available in the Sun reference implementation. And that's actually the best choice because it's the official interpretation of the rules from Sun. We have provided hooks in our build system that will actually make it possible to choose your specific deployment tool, deployment verification tool that you want to use. And the second point is how you can change it, how you can configure it in Project Builder.

So wherever there's development, unfortunately there's debugging. And we have, also we have a couple of options how you can How you can just have a look at, on what's going on behind the scenes without actually having to start a debugger. We have a verbose mode that the container, that the container has that you can enable by using both EJB container debug. And this will tell you exactly which method is invoked on which bean. And we will show that later in the next demo.

Also, if you cannot pin down a possible problem using the first option, you can start using the second option. And this will give you a very detailed overview of what's going on in the Java layer. So, for example, in the most verbose mode, which is debug level 5, You are able to see every single JEOP request message that goes back and forth. So there you can see For example, which strings or which data is really going over the wire. And also, it will generate, it will enable verbose exception logging.

Very important is that if you see problems, use project-builder debug support. I have had great success in narrowing down problems. You can set breakpoints in the EJB frameworks and basically have it run down until your problem occurs. forthcoming is log4j logging for all of the involved components that will enable you to basically pass the locks to any-- basically to the-- for example, to the console or have it locked to an SNMP system and such.

So we switch to the next demo, which will be PetStore. And it will demonstrate how you can, how you can hook in Tomcat and the EJB container together to, to have a very advanced deployment. This is not, this is not a very common use case, but it shows you that you can do it, basically.

So the first thing, of course, like in the first demo that we have to do is we wrap all of the EJB components involved in this example in an EJB framework. And PetSol comes with seven EJB components. So in order not to make the demo a little shorter, we have already created Five of them, or six.

And we will only show you how to add the last component. So now we will use the useJarFile option to tell Project Builder to include a binary EJB component into our build system. As you can see, we have separate representation for the bean. We have the client side, which only contains the required interface to access the bean, and the second, the second jar contains the implementation and everything the bean needs to be deployed.

So now we have to create a new WebObjects application that wraps the EJB framework and provides the automatic container start. We will use a pre-compiled version of this framework to make the demo a little shorter. And... As in the first demo, we will use deploy as an EJB container. No web services. No framework. And now, again, we need to add the EJB framework here. So that Project Builder can go ahead and create the necessary container-specific files for us.

So since this example actually requires a database, we need to change the database setup and we will do that in the Transaction Manager configuration file. This file holds all of the databases that are involved in your EJB application and it also allows you to configure connection limit and stuff like that. So as you can see, we have a JDBC database configured and the Java mail support.

Now we need to add some launch options that will allow us to control the behavior of the EJB container better. And we add, for example, the-- the VOR EJB name service port parameter, which allows us to start The Cobber name service that is launched automatically as part of the container start on a specific port number. This is required so that the server container can actually find the namespace. We also included the verbose debugging level option so that you can see what the servit--what the servit here actually invokes.

So I think we are ready here. In the background, there is a Cloudscape database running that has all of the necessary tables created. And we have also Tomcat 403 running, which didn't need to have changed at all. We just took it from the web and... created the necessary configuration setup for Tomcat and that was it. You can use the off-the-shelf binary distributions from Tomcat now to access our container.

What we've done to set up the web tier is we unjarred the petstore.wav file in the web apps directory, and then we had to add, or we had to patch two files that, two XML files that didn't conform to their own DTD to make it work. Also we had to add the JDBC drivers because the server tier actually accesses the database at the beginning to create all of the tables. And that was all that was required to make the example work.

So here we have PetStore. In the first one that we're going to show, you will see that All of the pages are very, very slow. And we went through it a second time, and you will see that this is mostly because all of the JSP pages have to be compiled, and there is a lot going on behind the scenes that you don't see here.

In the window above, you can see that whenever a D clicks something, that there are methods involved on the EJB container. So this is the output that you see. When you turn on the debugging mode and when you have to nail down possible problems. Of course, if you have to nail down problems, you will see verbose, you will see verbose exception traces that will point you to the error.

So apparently, the server container wants to have a lot of details here. and we just go ahead and buy stuff. What are you buying? 10,000 finches or something? Good? I like birds. Good. I'm going to have to take a look at that budget. Oh, well. Hmm. I thought it was free.

This is the standard demo that every application server vendor shows off. to show that the container runs the PEDSOR example. Of course, we're running PEDSOR 1.1.2, which is the latest PEDSOR version that runs on EJB 1.1. Now we go through it a second time, and you will see that everything is pretty fast now that the container, basically both of the container, have actually warmed up.

I think that's enough. So this concludes our demo. Thank you, Ali. And we now return to the executive summary. So what have we learned? So the key message today is that our EJB integration is ready for both development and deployment. As you have seen, Petzl runs a large variety of applications run without any problems. And this is the key message. You have a lot of development and deployment support from WebObjects and from the EJB container.

The second message you should take home is that we have strong tool support, the EO Bean Builder, the EO Modeler that makes your life easier. And thirdly, we have learned that EJB and EOF are actually supplementing each other, that by adding EJB to our WebObjects application, we have a real value add.

That's a new slide. So if you want to if you want to have a new look or a look at the current

Now we have the end titles. The WebObjects app is open until 6 p.m. today and tomorrow, the whole day. You can play around. You don't have access to the EOModeler tool that I showed, but you have access to the currently shipping version.

Very important for us, please give us feedback on all aspects of WebObjects, including, of course, the EJB support. and I'm waiting for you all to show up at 3:30 tomorrow. Who to contact? Tony or Bob at [email protected] or if you need professional advice on support or on development, please go ahead and contact Apple Professional Services. For more information, we have, of course, our website. We have-- We have all the developer documentation online, and we have a couple of other places where you can find various documentation, various information about our product.

If you're interested in OpenEJB itself, please have a look at openejb.sourceforge.net. There you can see what's going on the latest. The latest news, basically. Kessler and Tyrex have their own website. They are hosted at exolab.org if you're interested. And of course, if you need generic EJB advice, there are many books out there and there are even more web links. Our documentation staff has created a special EJB book that describes our EJB integration. The project will support everything that we showed today. Please go ahead and read it. It's available online and on the CD.

And of course, the documentation is the freshest documentation is always online. Both PDF and HTML are there. You can print it on demand if you want to. We have all of the required documentation on the CD and in the box. And the latest and breaking news are in the ADC newsletter.