Thank you, Tony. Thank you. Good morning. Welcome to session 609, Developing Desktop Applications with WebObjects. I'm Ron Lue-Saang, and I'm an engineer with the WebObjects group. So everyone that we've told, come to session 609 and you'll find out about desktop applications with EOF. Now you're finally here. This is what you came for. So to start things off, I want to emphasize that WebObjects offers incredibly powerful database connectivity for desktop applications. It's not just about web applications. We also offer incredibly powerful desktop application connectivity to databases.

To that, there are two architectures that WebObjects supports. Two-tier architectures with Cocoa EOF, where your Cocoa client talks directly to your database. We also offer three-tier applications where, using Java Client or direct-to-Java Client, your Swing-based application speaks to a WebObjects application server, which in turn speaks to your database. So what you'll learn today, I'll go over the architecture of Cocoa EOF and some of the functionality that it provides. And then I'll ask Andreas Wendker to come out and talk about Java Client and its architecture.

So first, Cocoa EOF. This is kind of the overview of what layers Cocoa EOF has. Of course, there's Cocoa and EOF, as the name implies. Cocoa, if you haven't heard, is Apple's incredible technology. It's a set of object-oriented advanced APIs for building Mac OS X native applications. And then, of course, there's EOF, our Enterprise Objects Framework. And here I've set out two special parts of EOF, first being the JDBC adapter.

The JDBC adapter is what actually connects to all of our databases. Any database for which we have the appropriate JDBC version 2 driver, we can talk to that database using EOF. The other layer there is EO Interface Cocoa, which actually bridges the two worlds of EOF and Cocoa. So in a little more detail, first Cocoa.

Cocoa and EOF work together. The Cocoa part provides all the application logic. So everything that you get that you're used to with a regular Cocoa application, you get in Cocoa EOF. This includes all of the cool widgets that you're used to, all of the views, the windows, the menus, the matrices, all the widgets that you're used to. And then, of course, the responder chain that you're used to for receiving events, the run loop for getting events from the user interface, and we even support custom views. It's everything that you expect from Cocoa as a Cocoa application.

Now, how does data get from Cocoa and into EOF and back and forth? The general idea of the data flow is, let's say you've got an application that displays some values in a table. So if you edit the value in the table, Cocoa will fire an event off to a class, an object, in EO Interface Cocoa.

This object has already set itself as the delegate for any edits in the user interface. So it gets the event. It realizes, oh, something has changed. I'll tell EOF about it. And the value is then set in the business object in EOF where you can save it or something happens in your business logic. And maybe something changes because of that one change from the UI.

Well, EOF then says, something's changed. And EO Interface Cocoa gets that event from EOF and then pushes the value back into the user interface, setting the display value in Cocoa in your UI. So that's a pretty simple setup, right? You've got Cocoa, you've got EOF, and you've got EO Interface Cocoa that bridges the two worlds.

Speaking of bridges, we do still use the Java bridge. If you're new to Cocoa development or new to WebObjects, the bridge is a cool technology developed by Apple for allowing your Java code to access Objective-C classes. In the Objective-C world of Cocoa, where Cocoa is really implemented in Objective-C, there's a wrapper of Java APIs so that you can actually use NSWindow, NSApplication, all the NSFoundation and AppKit utilities classes in Java.

So while Cocoa is available in Java and implemented in Objective-C, EOF now is all Java. In WebObjects 5, EOF is implemented in all Java, which is different from previous versions where there was also a bridge for EOF. But now that we're pure Java, all of your custom business logic must also be written in Java.

This works out well for you anyway since once you've written your business logic in Java, you can use that business logic in any other WebObjects application. HTML-based applications, Cocoa applications, or Java Client applications, the same business logic can move between the three architectures. And as I said, your custom business logic has to be written in Java, but your application logic, everything that takes care of the Cocoa interaction with the human interface, that can be written in Java or Objective-C. You still have a choice there.

Now, actually, so if you have worked with Cocoa or WebObjects in the past, you may think, oh, no, not the bridge. The bridge has been kind of a source of headaches in the past. We don't believe it's much of an issue anymore. There's two main reasons for this. The first being it's been rewritten for Mac OS X. It takes advantage of Java 2 on Mac OS X. It's much better. And the second, most important thing is we hardly cross the bridge.

Again, since we don't have to use the bridge in every EOF call, and most of the calls that actually go across the bridge are just in EO Interface Cocoa, we don't use the bridge much at all. The two worlds of EOF and Cocoa are pretty well separated, very well separated.

So this works out well for stability as well as performance, since you don't pay the hit of morphing objects from the Java world to Objective-C and back. That doesn't happen nearly as much anymore. But it is still there, so you need to be aware of the different memory models between Java's, of course, garbage collected memory model and the Objective-C memory model where you have to explicitly retain or release objects.

So what that means is you can occasionally be using a pure Java object in your bridge Java method, and the bridge will decide to forget about your object. Well, we offer some utilities, two utility methods to help with that, to make sure that the bridge doesn't automatically clear out your objects. RetainObject and ReleaseObject are two methods in IOCocoa utilities. And Eococoa Utilities lives in Eointerface Cocoa. These two methods help you do the retain and release calls that you would normally do in Objective-C, except you can do them on your Java objects now.

So back to our original graph of Cocoa and EOF. So there you have Cocoa, two special parts of EOF, the JDBC adapter and EO Interface Cocoa. Well, of course, EOF has more layers than just this. We also have EO Control, EO Access, and EO Interface in there. And in a little more detail, I'd like to go through exactly what it does, what EOF is doing here.

So the first layer there, EO Control. EO Control is really the core of EOF. It's what handles all of your business logic. It's where your business logic lives. And as such, there's the editing context, EO editing context, which handles, it holds all of your business objects for EO control. And it maintains an object graph of all of your business objects.

So that means it can track changes to the objects as well as relationships in the objects, insert new objects, delete objects. All of the change tracking can be handled in EO editing context. So that includes undo and redo support and everything. And of course, EO Control is also very performant. So we offer things like faulting, which allows you to not fetch your entire database into your application when you're not actually using all of those rows.

So that's a little brief overview of EO Control. We also have EO Access. EO Access is the part of EOF that actually Connects to Data Sources. And it's built, as you saw, on an adapter architecture where our default adapter, the JDBC adapter, is what talks to databases using JDBC2 drivers. But you can also slip in your special adapter classes here, your special adapter layer, to connect using JNDI to LDAP servers or XML adapters, whatever custom data sources you can come up with.

And the real functionality of EO access, of course, is object relational mapping. So that means mapping all of the relational rows in your data source to real objects in EO control. And that mapping between the two is held in an EO model file, which you build with EO Modeler. Each EO model contains a definition of all of the attributes of your business object, as well as the mapping from your business object attributes to individual columns, let's say, in your database.

Another important layer to EOF is EO Interface. All the classes in this layer are responsible for actually displaying data in the user interface. This is where EO Display Group lives. EO Display Group You'll use most. It's our common gateway to multiple data sources. It wraps an array of business objects that it gets from its data source, which is typically an editing context. And it handles coordinating updates of the user interface, getting the values from the EOs it contains, and setting them in your Cocoa interface. Or actually, any widget interface, Cocoa or Swing, as you'll see later.

So EO Display Groups work with EO Associations for updating the user interface, keeping the user interface in sync with all of your business objects. EO Associations are the parts that actually connect display groups to widgets in your user interface. So that means we've got text associations, for example, to display data in your databases that comes up as text or even dates, numbers, so that things are formatted properly in the user interface.

We also have other associations for displaying, let's say, images in NS Image Views or handling all the data in tables and table columns. So the associations really keep the display group connected to your interface widgets. But there are also other associations that can connect display groups to other display groups. As an example, there are Master Detail Associations. Which can connect a master display group in which you're fetching possibly all of the people in your database.

And it connects that display group to a detailed display group, which could be displaying all of the addresses for those people. This means that once you've selected a person in your persons display group, The association will automatically tell the detail display group to display that person's address information. All of these are available just in EO Interface.

And don't let all of the talk about Cocoa fool you. We also keep EO Interface very separated from the details of any specific widget set. It's abstracted away from all of the details using plugins. So you can actually use EO interface in, In Java Client applications as well as Cocoa applications, it's widget set agnostic.

So why all the layer talk, though? Well, as I said just now, knowing that EO Interface doesn't depend on any specific widget set code, doesn't depend on Cocoa, let's say, you know that when you code, when you write code, write, let's say, new associations, that you can use them any place EO Interface is used. So new associations can be used in Java Client or Cocoa Client.

So the plugins, though, that do know about the widget set specific details live in EO Interface Cocoa. All the plugins in this layer know how to handle targets and actions and know how to connect up to become data sources or delegates of certain widgets. They all handle certain specific tasks, typically type morphing, so that an image association plugin will know that NSData coming from EO interface can be displayed as an NS image in an NS image view. And it knows how to do set and get, so set object value and object value with Cocoa widgets. And it also, there are many plugins that also handle events from Cocoa. So that they can register as delegates for methods and as data sources.

And of course, this plugin set is extendable to other widgets. We know that you all have widgets that you may like that aren't available with the default Cocoa set. So you can build your own NS views, custom views, your own custom widgets, and create a plugin for it that you can use in your Cocoa EOF applications.

So how does everything, how do all the layers interact when you're actually trying to do something? Let's take another example of trying to fetch objects into the user interface. So a Cocoa widget, I hope you can all read this actually, a Cocoa widget will fire off an event to the plugin that's registered for it in EO Interface Cocoa.

The plugin sees, oh, something's changed and tells its association. The association, in turn, makes sure that the display group qualifies for your fetch, let's say. The display group then goes and tells its editing context, gives it a new fetch specification, and the editing context goes to its data source, which is the database context in EO Access.

EO Access will fetch any new objects that it needs to and change that raw row data into full enterprise objects, into your business objects. And then any subset that's related to the fetch will be sent to the display group. So the display group now contains a certain subset of the EOs in your editing context that it fetched for. The display group then, of course, tells the association. New values have come in and the association gets those values and hands them off to the plugin that it's associated with.

The plugin takes the value that it's related to and knows how to do set and get methods in Cocoa to put the values into your user interface. So it's a pretty simple chain up and down the Cocoa EOF stack, with Cocoa at the top and EOF at the bottom, and that thin layer of EO interface Cocoa in the middle. So I'm going to ask Andreas Wendker to come out and give a demo, show you exactly what Cocoa EOF applications look like.

So here we've got a pretty simple model. Maybe kind of hard to read back there, but it's based around a person and some information about that person. So that's the model we're going to use in our application. So we just go to Project Builder and create a new project.

One of the types that you can choose here is Cocoa EOF Application. You go ahead and you do everything you would with a normal project. You name it, you choose a place for it to live. And then you add any frameworks that you need. We're going to skip frameworks and directly add a model.

So the one we're going to choose, the layout that we're going to choose is a master detail layout. All you do is you choose your main entity and any attributes that you'd want to show in your tables. The master detail layout, by the way, by default shows you a table for your master display group and another table for your detail display group. You choose your master entity and your detail entity and all the attributes you want to show in those tables.

So we go ahead and we build the project for you. And as you can see, this is really just a Cocoa application with a few extra things in it. We've got our main.m, we've got our main menu.nib, and actually we've added a few other frameworks. We've added Java EO Cocoa, as well as some of the standard EOF jars that you'll get with WebObjects 5.

Oops. We've added our education model. And to show you the nib, this is the nib that we build for you, that our assistant builds for you by default using master detail template. We fill in all of the details of putting in table names, table column names, and labels for your forms.

And of course give you the ability to do some of the simplest things you would do. Add and remove objects, fetch new objects, and save back to the database. You can tweak the nib and add anything you want, edit it any way you want. It's really just a Cocoa nib.

So you can see Andreas is here just beautifying some of the names.

So remember, we've written no code, and then all of a sudden, we have a Cocoa application that can talk to EOF and talk to our database, browsing live data in our database. Editing values, saving values, the whole nine yards without any code so far.

But of course, you're probably not gonna just sit there and use our Assistant-built application. You can add stuff. You can add even other display groups that we may have missed from building it in our Assistant. So you can simply drag a new display group from EOModeler. and wire it up in Interface Builder. This is another one of the beautiful things that we can do with WebObjects that we've added. The functionality that we've added to Interface Builder, being able to connect these display groups to the widgets.

So we can choose a pop-up and connect it to person type. So we can now choose from a pop-up list what type of person we're editing. So we can edit the person. And as you can see, you can actually traverse relationships, so person to person type. And notice that Andreas hasn't recompiled.

You may be aware of the test interface functionality of Interface Builder. Well, you can still use that with Cocoa EOF. No more recompiling, simply run it, right? Back to the slides. So I'll hand it off to Andreas now, and he'll talk a little bit about Java Client. Thanks, Andreas. ANDREAS WENKER: Thank you, Ron.

So my name is Andreas Wendker, and I'm the manager of the WebObjects rapid development team. And I'm going to use the rest of the session to introduce you to our Java client technology. So Java Client is another technology inside WebObjects you can use to develop desktop applications. It has a lot of things in common with Cocoa and EUF, but there are also a couple of differences. One of these differences is that Java Client is implemented in pure Java. For the user interface, we use the Java Foundation Classes, or Swing, and that basically makes Java Client platform independent in the sense that it runs on all platforms that support JDK 1.3.

The other important difference between Java Client and Cocoa EUF is that Java Client uses a three-tier architecture, not a two-tier architecture. So we have a client that displays the user interface and interacts with the user. We have a server that accesses the database, and we have a database that stores the data. Now, it's important to know that the client never directly accesses the database. All the database access goes through the server, so the server has full control over what the client can do with the database and what it can't do.

The other thing interesting about Java Client is that it uses HTTP as the communication protocol between client and server. So you basically get the connectivity of an HTML application running in a browser. You can access the server from anywhere in the world, but you get a much richer user interface.

Let's take a look at what we have to do with the architecture to make this work with Java Client. You already know that instead of Cocoa, we use Java Client. Out with Cocoa, and in, sorry, I said we use Swing. In with Swing. Using Swing also means that we need to use a new plugin layer.

We have this plugin layer that connects the Interface layer and Cocoa, and we have a new plugin layer that connects the Interface layer and JFC Swing. This new layer is called EU Interface Swing. I also mentioned that we don't access the database directly anymore. So we don't use EU access into the JDBC adapter. Instead, we use a layer that we call EU distribution that takes care of connecting to the server. Also, for your convenience, we added another layer.

It's called EU Application. I'll talk more about it in a minute. Something you should notice is that the EU Control and the EU Interface layer stay the same in both architectures. Code that you write against the EU Interface or the EU Control layer, that mostly means your business logic, can be used in both architectures.

Now let's take a look at these new layers in a little more detail. The EU application layer exists because Swing doesn't offer us all the functionality that Cocoa gives us. Swing is a relatively plain widget set. It has a lot of user interface elements like text fields, buttons, windows, but it doesn't help you a lot with higher level tasks like simply starting your application. Or tasks like implementing a document management, maybe managing user defaults, or handling menus. We created the application layer to help you out with these tasks. It's a layer that provides you a lot of utilities that you can use to manage your user interface.

And another very important feature of the application layer is that we added the ability to load interface files that you created in Interface Builder. That's actually pretty cool because you can use the same tool to create user interfaces for both Cocoa applications as well as Java Client applications.

There's just a little problem with that because out of the box, Interface Builder doesn't allow you to edit Swing lib files, right? You can only edit Cocoa or Carbon lib files. So how do we deal with that? Well, we ordered an extension that translates a Cocoa interface file into a Swing interface file, right? You don't really see this translation. It just happens for you whenever you save your lib file. But what it means is that you can create the interface in Interface Builder and then use it in the Java Client application. And we will show you how that looks.

Now let's talk about the distribution layer. The distribution layer replaces the EU access layer as the data access layer. So clients fetch business objects, not from the database, but they fetch the objects from the server. And if they have changes that they want to save, they also save the changes through the server.

And on top of exchanging business objects, the distribution layer gives you a convenient API to do remote method invocations. So if you have something that you need for your client application to deal with some kind of resources or so that is independent of business logic, the distribution layer has an API that you can use to contact the server.

So the complete picture then looks like that. So there are a lot of boxes, but the important piece is that we basically pushed the EU Access layer and the JDBC adapter to the server side. And the server is actually a pretty normal WebObjects application. We use eVaccess and JDBC adapter to access the database. We have eO-Control to manage business logic. We have WebObjects to deal with things like sessions. And we also have a server-side component for the distribution layer, which plugs into WebObjects and makes sure the Java client works fine with WebObjects.

Something that is very interesting about our distribution layer is that it uses a copy distribution mechanism for business objects. That's very different from what most other technologies for three-tier use. Most other technologies use some kind of a client stub. What that means is that the client business object is just some kind of an extension to the object that really lives on the server, and the client has to ask the server for every little detail. So there's a lot of communication going on. In our distribution layer, business objects are actually copied when they are fetched from the server to the client, and they live as fully functional objects on the client side.

I think a good way to think about Java Client is that editing contexts on the client side behave like a nested editing context to an editing context living in the session on your server side. What does that mean? Well, those of you familiar with EOF probably know that an EO editing context, which I, by the way, abbreviated with EC in this diagram, is just a special form of an object store.

An object stores have parents. The parent object store is the object that is really responsible for providing data. In the normal case, if you're just on the server, if you write an HTML-based application, the parent object stuff in editing context is a database context, abbreviated DC in this diagram.

With Java Client, we introduced a new type of object store, which is called the Distributed Object Store, DOS. The Distributed Object Store lives on the client side, and its task is to connect the editing contexts on your client side to the editing contexts on your server side. So as you can see from this diagram, the only way for your business objects or your business data to get from the client into the database is through the editing context on the server side. And that's where you have all the control. So you can control exactly what goes to the database. Let's take another look at this diagram just quickly. I want to point out again that the control layer that's really important is used on both sides of the architecture.

Now with Java Client, you have the choice to either use the same identical business logic on both client and server, or you can use what we call petition business logic. Petition business logic means that the implementation of your business logic, of your business objects on client and server is different. And it can be different in two ways.

You can limit the visibility of properties to the server so that you don't even send to the client what you don't want to see. And also you can use different implementations for the two business objects. So you can actually force the client to make roundtrips to the server and use an implementation it provides there.

That adds a lot of value to your application, and it adds value in two areas, in the area of security and in the area of performance. I think the area of security is pretty obvious because you don't send any data to the client that you don't want it to see, and you don't even send compiled code to the client that you don't want it to know about.

Because since we use Java, you will know that the code can actually be pretty easily decompiled. So if you have code that you consider secure or secret, and you don't want to send it to the client, But then you can keep it on the server and force the client to invoke the head code.

The other area is performance. Business Project Petitioning helps you with performance because if you have the great server with 500 processors and lots of gigahertz, then you can make your clients use the high computing power of your server. Today, that probably doesn't matter that much anymore because most clients are fast enough. But more importantly, you can use business logic to avoid that too much data is transferred between client and server.

You can minimize the amount of communication between client So if you have an algorithm, some kind of computation that requires you to look at a lot of data, but you don't really want to display that data on the client, you just want to display the entries out, then the right thing to do is to execute that computation on the server, fetch the objects that you need for the computation only on the server, and then just send the entries out, which is much smaller.

With Java Client, you have two different options to deploy. You can deploy the client as an application, as a full desktop application with an icon that you can double-click on the desktop, or you can deploy as an applet embedded in some HTML running inside a browser. I would like to take a moment and compare these two options for you.

The most compelling advantage of the applet is the simplicity of the installation process because there is basically no installation process. When applets start, they download all the classes that they need to execute the program from the server side and then execute the program inside the browser. With applications, you have to install a start program on the client machine and all the classes that you need to execute the client. So you have to give your end users some kind of an installer that just puts the application on the desktop.

Now, if you want to upgrade your application, you get into a lot of trouble. So if you have some bug fixes, you get in a lot of trouble with desktop applications because now you have to make sure that all your clients install the new version. With Applets, that's so much easier because you just upgrade it on the server. The next time the client launches, the new classes are downloaded and the client has automatically updated.

Nevertheless, applications score much higher in the area of user experience. It's just so much nicer for users to start an application from the desktop, to not have to wait 30 seconds until all the classes are downloaded, and to have an application that is actually fully embedded in your desktop environment. Applications you can hide, you can minimize windows, you have access to service menus, et cetera. You don't have that with Appless.

You will also find that applications perform a little better than applets, and the reason is that they are very isolated. Applications run as standalone processes, while applets, all the applets running in one browser, share the VM, the other code. That can have all kinds of negative side effects on both performance as well as stability.

From your perspective as the developer, applications also have the advantage that you don't have to deal with security restrictions. In Applets, there's a security manager installed which prevents the application, the program, from accessing your file system, from accessing certain system parameters. You don't have to deal with that in an application. So if you have the need to store something in the file system, it's much easier for you to do that as an application.

But the users might see that a little different. That's why I've got a little dot here in this diagram. From the user's perspective, applets are usually executed as untrusted code. And the Java VM ensures that the program can't mess with the computer. So users might see that a little different than you. But we think that in the environments where you install Java Client, where you use Java Client applications, which is mostly intranet, it probably doesn't matter so much because your user should trust the system administrator. that the software is a good software.

Another advantage that might come in handy with applications is that you have full control over all the VM parameters. Let's say you need a very large heap size. You can adjust the heap size with an application because you have control over the start program. You can't in applets. So now I would like to ask Ron to come out and give you a demo of our Java client.

We are basically going to create the same application that we created with Cocoa, the Java Client. So we go into Project Builder, we create a new project, choose a different kind of project type, give it a different name. Then we add some frameworks. This time we actually do add a framework. It's called Java Client Class Loader. It's just for the demo purposes. It's not part of WebObjects 5. It just makes our demos here really easy. So we choose the same model.

Thank you for your time. I hope you did for Cocoa. And then there's something interesting. This is different than in Cocoa. It asks us for a so-called interface controller class. The interface controller class is a class that we generate in the Assistant and it's a very convenient class for you that helps you to manage user interfaces and to especially load interface files. So the Assistant creates, for every interface file that you create, you also create an interface controller class. Now we will do the same thing. The rest of the system is basically the same. We choose the master detail layout.

Choose person as the main entity. Last name, first name, person type, table. Last name and first name for the form attributes. We choose addresses as the relationship we want to display. And we pick a few attributes that we want to display in the table for the addresses and in the form.

And that's it. So this project now looks a little more complicated than the one for Cocoa. The reason is that now we have a full WebObjects application. So we have all the components that, you know, we are familiar with from the server side. And actually, projects with WebObjects have two different targets. One is the application server target, the other one is the web server target. The application server target contains all the objects and resources that you need on the server side, the web server target, the ones for the client side.

And these little donuts here on the left side, they basically show you to which target a file belongs. So as you can see, we have a normal application, we have an application class, a session class, a direct action class. And if you look inside the main.vod for a second, you can see that We can see that we use a VoJava Client Applet and we specify the interface controller class name here, which is the interface we want to load.

So this is our connection from Java Client, from the client side, into the server, that we use a special class VoJava Client Applet. Now let's take a look at the client side. - So there are two files. There's the code, the Java Client Interface controller class, and there's the interface file, why don't we open that in ID. So it's basically the same interface file that we had for Cocoa, and Ron is going to beautify it again.

So we give the vendor a better title. We modify a few of the labels. That's all I have to do. Be safe. Now we go back to Project Builder and actually compile it. This will take a little longer than with Cocoa because now we have a client and a server side that needs to be compiled.

Okay, and Ron is now starting the server side of the application. The nice thing about this little framework that we added is that it hard codes some of the port numbers we want to use, and it allows us to use a little start program that we wrote, which is our Java Client Launcher, and then we can just enter the URL, and it happens to be the right one, and now our client connects to the server.

And this is the client application. So as you can see, it looks pretty similar to what we had with Cocoa. We have a table, we can enter values, we can change values. It just behaves the same way. and all that without writing code. Okay, we want to show you, If you want to just show you something else. In earlier releases of WebObjects, the slip-fetch installation had a bunch of problems.

It's still a little problematic because there are these two different worlds, Cocoa and Swing, and they don't always match exactly. But we think that Interface Builder is really the greatest tool on the planet to create user interfaces. And it's especially the only tool that allows us to set up connections. And in UAF, we really need connections. We need to set up all these associations. So Interface Builder is really the best choice for us to generate interfaces.

And with WebObjects 5, you try to fix all the bugs and... We would like to show that to you by just overlaying the interface file and the running application, and then minimizing the window in the interface files. As you can see-- As you can see, it maps pretty well. There are a few differences, just maybe Swing draws the text one pixel higher in a button than Cocoa does or so. But basically, if you overlay the two Nib files, it looks pretty much the same.

OK. Can we go back to the slides, please? With Java Client, we also have a technology we call Direct-to-Java Client. Direct-to-Java Client is an infrastructure that helps you developing Java Client applications very easily and very rapidly. It does so by providing you with a lot of predefined application functionality that you can make use of.

And it relieves you from the burden to create user interfaces by hand. Instead, it actually generates the user interfaces dynamically for you. And it does that by analyzing the EU model and coming up with a good scheme to display and edit your data. And we would actually like to give you a short demo about that as well. We will have a full session about it later this afternoon, but we'd like to show it to you here as well. So if you could go back to the demo machine.

So we go back to Project Builder again. We create a new project. Choose a different project type. This time it's direct to Java Client. And we give it a better name. We will add our little Java Client class loader framework, just so that our demos are easy. And we choose the same model again.

And the last option is to build and launch the application automatically for us. So Ron, if you expand all the groups again. So you see there's still a WebObjects application. The one thing that is different about it is that if you go to the main.bot again, It now uses another application class. It's the EU Dynamic Application.

That's just a special class that makes sure that your client does something sensible even if you didn't give it any interface file. As you can see here, there is not a single interface file defined. There's actually not a single file related to the client that you have to create. So the program automatically compiled and launched for us. And now we will use our Java Client Launch again to connect. And the reason why this works so simple is that we have this little framework.

This is the application we get. As you can see, this application here has a little more complex UI. We have query interface for persons and departments. We see much more entities in our model. We can search for persons and then we can open them. If you open them, you get detailed windows.

Why don't you make that? And maybe you can switch around to addresses, phone numbers. So as you can see, with just a very few steps, we were able to create a fairly complex UI that allows us to browse the whole database and display and edit all the values in your database. Okay, thank you, Ron.

And I think -- oops, can we go back to the slides, please? Before we go into question and answers, I would like to take a moment and compare the two technologies that we introduced to you. Ron introduced the two-tier Cocoa EOF applications, and I talked about the three-tier Java Client applications.

What are the differences? Well, Cocoa is a Mac OS X only technology. So Cocoa EOF applications you can only deploy on Mac OS X. With Java Client, you're basically platform independent. You just need a platform that supports the JDK 1.3. But if you want to give your users the optimal user experience on Mac OS X, you would have to use Cocoa.

Platform independent, but that also means it's not specially designed for the Mac. So if you want the best user experience for your users on Mac OS X, then you have to use Cocoa. Java Client and Swing still gives you very good user experience, and especially with all these optimizations that Steve Nero's team is working on, the applications get faster and faster, and it's really hard to, it starts to get really hard to distinguish Cocoa and Swing.

When it comes to deployment, you have to have an installation on the client machine with Cocoa applications. With Java Client, you have two different options. You can deploy as an application or as an applet. We usually recommend to deploy as an application because the user experience is so much better, the performance is a little better, and you can tune all the parameters, but you have both options.

From the administration perspective, Cocoa applications, you know, it's like every other desktop application. The Java client is a little more complicated because now you suddenly have two things. You have a server that you need to administer, you need to make sure that it performs well, and you have to have, and you have a client. So it's a little more complicated, a little more work for you.

Performance of Cocoa applications is just fine. The performance of Java Client applications is still fine, but you have to make sure that you partition your business logic correctly so that the communication between client and server doesn't become a bottleneck. Also, with Swing, the user interface is a little more sluggish than Cocoa. I personally don't think it matters. It's really close enough.

When it comes to security, Cocoa applications you can only use in the intranet because the application directly accesses your database. You don't want to give that to anybody outside your company. Java Client gives you all the tools you need to make your clients or your database secure, but there are still these complications with either installing the application or you face this 30-second at least download time of classes if you deploy a snaplet. So that's why we think it's not really a technology that is suitable for high-traffic internet sites. And Java Client is also mostly an intranet technology.

The reason why I wrote Intranet++ is that since you have all the tools to make it secure enough, you can actually use it in what I call controlled environments. So let's say you're a software company, you have a bug tracking system where you lock all your bugs, and you have a few customers, a few preferred customers, that you want to give a direct login into your database. It makes perfect sense to give them a Java Client application. But as I said, it has to be a controlled environment because of the installation complications.

Okay, so we still have some time, but... We care a lot about desktop applications. We care so much about it that we give you two technologies to implement them. We introduce to you the Cocoa UF applications, which are two-tier, and we introduce Java Client applications, which are three-tier. With both architectures, you get incredibly powerful database connectivity for your desktop apps.

Something to keep in mind is that the business logic code you write can be used in all architectures. It can be used in Java Client, it can be used in Cocoa, and it can be used in a WebObjects HTML application. Who has not seen that? Good. The sessions I recommend to you related to this topic are session number 606, later this afternoon, about direct-to-Java client, and number 614 tomorrow, advanced Java client.