Our next session this afternoon is Direct to Java Client. I wanted to make a quick comment before we actually started the session. For those of you who are at the State of the Union and we showed a two-tier Java Client demo, I wanted to make sure that you guys did catch the part that that was a two-tier demo, not a three-tier demo.

And I've asked Andreas to come back in the session following this one to talk a little bit more about two-tier Java Client. You won't be hearing a lot about that in this session, but you will in the next session. And if he has time, he will also rerun that demo for you. Okay? So I'd like to introduce Ernest Kim, who is your presenter for Direct to Java Client. Thank you.

Thanks, Tony. Thanks, Tony. So welcome to session 706 on Direct to Java Client. My name is Ernest Kim, and I'm a member of the WebObjects rapid development team. So if you attended the State of the Union of Java and Apple, what you found is that my boss's boss's boss's friend is James Gosling.

So obviously he and I are very close. So rapid development is really, really fun team to work in in WebObjects because they work on things like Direct to Java Client and Direct to Web Services, which if you were here for the previous session, you saw an interesting demo of.

And it's my pleasure to talk to you today about Direct to Java Client. But before I do, what is Java Client? Java Client is a great technology. Now, many of you are probably familiar with WebObjects already, knowing that WebObjects is a great technology for developing three-tier HTML-based applications. Well, it turns out that WebObjects also has a great technology for developing desktop applications, Java Client. So Java Client is a technology for creating distributed three-tier applications for the desktop.

When we say three-tier applications, we mean that at the bottom there is a database that stores the data. At the top, there is a client that displays the user interface. And in between, there's the application server, which accesses the database and controls exactly what the client can do. The interesting thing about Java Client is that all three tiers use a common protocol for communication, HTTP. And the clients are implemented in pure Java, so this means swing. The great thing about Java is that it is reliable and platform-independent.

A nice thing about Java Client is that it has been designed with localization in mind. So it is very easy to localize your Java Client applications. One thing to bear in mind, however, is that Java Client is intended for use in an intranet and not for high traffic intranet sites.

The reason is that a client is fairly heavyweight. It is larger than three megabytes, and it may take a long time for a customer with a very slow connection to download the entire client. So now that we know what Java Client is, let's talk about Direct to Java Client.

Direct to Java Client is an infrastructure that helps you to create applications really quickly. Perhaps the defining characteristic of Direct to Java Client is that it generates the user interface dynamically. A key strength of Direct to Java Client is that it provides a great deal of built-in functionality. So this relieves you from the burden of having to create the entire user interface by hand. Because Direct to Java Client creates an application dynamically in such a short amount of time, it is ideal for prototyping purposes.

Now we understand that the default application that Direct to Java Client creates for you may not support exactly the kind of user interface that you want. Fortunately, there exists a number of powerful customization techniques so that you can create precisely the kind of user interface that you want. So that is Direct to Java Client.

So what will you learn today? Well, I hope that by the end of today's session, you'll see exactly what the default applications offer you, which is actually a lot. You'll see why you should use Direct to Java Client. You'll learn how to customize default applications. And finally, because it is such a hot topic and probably the real reason people are attending developer conferences these days, how to leverage the power of web services in your application. So before I go into that, how about a quick demonstration of exactly what Direct to Java Client is all about? And here to help me with that is Brent Shank of Technical Publications. Thanks, Ernest.

All right, I'm going to present a short demo here for the first one. This is similar to what Andreas presented in the tools overview earlier in the week. So simply based on an EO model file, I'm going to generate a three-tier swing application that accesses a data store on the back end. So here we are in EO model, showing you the real estate model that we've been using all week for web objects applications. So in Project Builder, I'm simply going to make a new Direct to Java Client application.

And in the Project Builder Assistant, I am mostly just going to select the defaults that it gives to me. And if you want to really know what these are all about, there's a good book on Java Client that we'll tell you about later describing these in depth. I am going to add the EO model that you just saw in the background there.

Select some other options here. You see this Web Start pane here. This helps us configure the Web Start JNLP file that we will use to deploy this application. Okay, so Project Builder is going to build and run the client and server applications. And what it's doing right now is compiling all our source files and aggregating all the frameworks and things like that. And in a second, it's going to analyze the EO model right here. And based on a sophisticated set of rules in the rule system, it's going to create for us a swing application. So here it is.

So now you'll notice that this is a fully functional application. I can search for data. I can open records that I find. Here's a record. I can make changes that I want. Commit things back to the data store. So there we are. Without writing any code, we have a great swing application.

Thanks, Brent. We'll try to make the next demo a little more challenging for you. So now that you have seen a little bit of what Direct to Java Client offers you, let's take a look at the colorful technology that makes this all possible. The most important thing to take away from this diagram is that you have the same control layer on both sides of the client server divide. So what this means is that your business logic lives on both the client and the server. The next important thing to take away is that there's a key difference between the ways that a client and a server accesses the tier that's underneath it.

On the server side, there's the access layer and the various enterprise objects adapters for handling communication between the server and the database. On the client side, however, there's the distribution layer. It handles the communication between the client and the server. The final important thing to take away from this diagram is that a web ob... a j- a JavaClient application is a WebObjects application with the addition of a rules system on the server side. The rules system is what actually generates a description of the user interface. And a JavaClient client becomes a direct-to-JavaClient client with the addition of the generation layer. This is what actually will build a hierarchy of controllers. I will talk about this in more detail soon enough.

But now that you have an eagle-eyes view of the application architecture, let's talk about some of the core concepts in creating a JavaClient application. Well, there are several kinds of display objects. There are display groups that coordinate the flow between the user interface objects and the editing contexts.

There are associations, which will actually synchronize values between the user interface objects and the business objects. And finally, there are aspects, which simply... to simply define various parameters of display objects. And having seen these, I would now like to introduce the heart and soul of Java Client, which are the controllers.

The controllers are what actually implement the client functionality. You can consider controllers to be the glue between user interface objects and the business logic. Now, controllers do much more than associations, which simply listen for events and send values back and forth. Controllers are very responsible objects. They actually carry the knowledge of how to create and layout the various user interface objects, such as display groups. Based on the underlying enterprise object's infrastructure, like the editing contexts. So having seen what the controllers are and what the various display objects are, we now have the basic building blocks for creating Java Client applications. So let's talk about design.

When you design a Java Client, you primarily have two options. You can use the Direct to Java Client approach, which is the so-called code-free approach that we advocate and is the focus of this talk. On the other hand, you could try kind of the more old-fashioned approach, which is to create all of your interface files, or NIBs as we like to call them, by hand using the interface builder application.

The choice between the two really boils down to all the tradeoffs that come between having a user interface that's statically created or one that's dynamically generated. And I think what you'll find is that there are several important reasons that actually favor the dynamic approach. One is productivity. Your productivity will be much higher with a dynamically generated user interface. It will also be easier for you to maintain consistency between the user interface and Your business logic or your data model, if in fact your user interface is generated dynamically from the data model.

And finally, it is easier to localize a user interface that has been dynamically generated than it is to localize one that's statically generated. For similar reasons that make it easier to maintain a dynamically generated user interface, it can soon become a nightmare if you have a statically created interface where you make a few little changes and you end up having to touch many, many files, and that can soon become a maintenance nightmare. So why don't we see the power of the dynamic approach in action. Another demonstration.

Thanks, Ernest. Thanks, Brent. Okay. So we're starting from the application that we created in the last demo, and we're going to show you some of the customization techniques that we provide you for dynamically generated user interfaces. So with every Direct to Java Client application, we include a tool called the Assistant, and it is available from the Tools menu in the Client application, and it's a swing application that runs alongside the client. And it allows us to perform basic, pretty simple customizations to the client application. So for instance, by default, the name of the query window is Query Window, which, you know, may be fine, but you may want something else. So.

We'll give it a different name. And by default, the first one on the application always shows up in the upper left-hand corner of the client screen. And perhaps for some reason, you want a different behavior. So, let's go ahead and start with the first one. In the Windows pane here, we're going to select bottom left as a position, save and restart the client application right from within the Assistant. And you'll notice we've changed the title of the window and where the window shows up. Okay, that's all right. Let's do something that will be actually useful to our clients of this application.

So we're going to open a form window for the customer entity. And you'll notice that there's a lot going on here. Well, it might be nice to hide some of these properties. So in the Properties pane of the Assistant, and you'll notice that the Assistant follows you where you go, we can choose to hide some of these. So I don't want to show the agent and I don't want to see the suggested listings for this customer. So I'm going to save that. I'm going to open a different record.

for a customer. And you'll notice in comparison, this is the new window here that we customized with the Assistant, and this is the window before it was customized. So without writing any code, we have a tool that helps you write rules to simply customize your application. Thanks, Ernest. Thank you, Brent. Okay. I promise to make the next demo a lot more challenging for him. So let's talk about the all-important controllers in more detail. You're going to need the help of many controllers to create your client. And there are primarily four kinds of controllers.

All of these controllers are subclasses of the EO controller class in the EO application framework. First, there's the application object, which, like every other application object, handles the startup process and also application-wide parameters such as menus. Then, there are the user interface controllers, which handle the higher level layout management tasks. Examples include the tab view controller.

The rule system is a simple question and answer mechanism. It generates an XML description of the user interface. Now, the rule system resides on the server primarily for two reasons.

For sharing, because the rule system is a computationally intensive expert system, and it is advantageous to cache and share the results of those computations. For security, because the rule system analyzes information in the data model to generate the description of the user interface, you can consider that data model to be sensitive business information. And in general, you do not want to send the data model across the wire unless it is absolutely necessary.

Now, the rule system in Java Client, Direct to Java Client, is really great because it provides a lot of built-in functionality. In other words, there are approximately 100 default rules that help you to create a sophisticated user interface. It is also easy to define custom rules because the rule system has been designed with extensibility in mind.

So now that we've talked about how controllers are organized and defined in the rule system, why don't we step back for a moment and take a look at the complete data flow of a Direct to Java Client application, or what I like to call a day in the life of Direct to Java Client.

We start with The application object on the client side, which in Java Client is an instance of U application, and in Direct to Java Client is an instance of EO dynamic application. Its most important task is to warm up and initialize the controller factory. Controller factory is an object that actually builds the hierarchy of controllers. But to do so, the controller factory sends out a request to the rule system, which as we discussed, resides on the server.

The rule system will analyze information in the data model as well as rule models to generate an XML description of the user interface, which the controller factory will take and actually build the hierarchy of controllers. The hierarchy of controllers will actually generate the user interface and also listen for user events, which may trigger additional actions on the controller factory.

Which in turn may result in the creation of additional windows, which of course may require additional requests to the rule system. I feel like I'm on the Discovery Channel, you know. It's like the salmon have swam upstream to whence they came from so that they may spawn the next generation, and thus the cycle of life continues. But this is pretty much a day in the life of a Direct to Java Client application.

So now that we have spent a day in the life of a Direct to Java Client application together, I feel like I've gotten to know you all really well. So I guess it's time to get personal. So I think we're ready for the next step. So we can discuss customization techniques. There are primarily three broad categories of customization techniques. Writing rules, which means you're keeping dynamic.

We're freezing parts of the user interface, which means we're becoming static. And finally, writing code so that we can add more functionality. To help you with writing rules, you need a system, which Brent kindly demonstrated for us earlier. And that suffices for most simple tasks. But for more complex tasks, you may need a little more flexibility. And that's why there's the rule editor tool, which allows you to write any arbitrary rule by hand.

Freezing the user interface is the next level of customization, and it is a slightly heavier-weight customization technique. So freezing means that we're starting to bypass the dynamic rule system and instead using hard-coded XML that has been saved in the file or an interface file that you created by hand using the interface builder tool. And this requires more work. On the other hand, it gives you more flexibility over the layout.

Finally, when you want to write code, you commonly do two things. One is to create your own controllers. So typically that means writing a subclass of an existing default controller And you may want to do this to add more widgets or associations. It's up to you. But you can even go so far as to override the behavior of the controller factory. And that way, you can actually customize the flow of the user interface completely.

We'll delve into each of these more customization techniques in further detail. Let's first talk about freezing XML. Freezing XML, as I mentioned, allows you to bypass the rule system and to use static XML that's been saved in the file. That file happens to be a WebObjects component. A woke component.

The reason we used a WebObjects component is that it allows you to mix in the dynamic elements, such as woe conditionals and woe repetitions. You can even go so far as to create your own templates, which is a very powerful technique. Yes, you can use frozen XML to describe the complete window or just part of a window. It's up to you. The thing to remember is to write a rule to register that frozen XML component with the rule system so that it actually gets used when the user interface is built.

Maybe we should make things a little more concrete with a demo. All right. Sounds good, Ernest. Okay, so as Ernest was saying, when the controller factory generates XML, it ends up creating a controller hierarchy for each window in the application. And conveniently, in the Direct to Java Client Assistant, there is an XML pane.

And so if you switch to that, you see all these wonderful XML descriptions, each corresponding to a single specification in the application. So let's take a look a little more closely at one of them. So if we look at the Customer Form window, let's find the specification for that. So the entity is Customer, the task is Form, and the question is Window. And we'll just look at a few of them here. So the top level of the window is described by a frame controller element.

The button bar here is described by an action controller button. And if we look at the first two text field controllers, those correspond to the first name and the first name of the text field. Last name widgets in the window there. So that's kind of a concrete example of how the XML generated is transposed into swing widgets in the end.

So this XML is great, but we want to know how to freeze it. So conveniently, since we have the XML in the Assistant, we can simply copy it out of there and into a new Web Audit component, in this case, an instance of D2W component. So we want to freeze the listing window.

Or the form window for the listing entity. And it might be nice to add, like, a badge for your real estate agent or something there. So we're going to freeze XML to accomplish that. So we need to find the XML description for that particular task and window. In this case, it's the entity listing and the task form.

So I'm simply going to select all that XML, Copy it out of the Assistant and back in my project. I want to add a new component to the project. This is going to hold the frozen XML that we customized. We're going to add a file that is a WebObjects component.

And since this is for the listing entity for the form task, we're going to give it that name. So the assistant that we just invoked actually gives us a WOL component, but we need a D2W component. So we're just going to change the superclass and simply add the import statement for the Direct to Web package. So I guess this is writing code, but it's not really writing code. OK. And finally, in the WOL component that was generated for us by the project builder assistant, we're going to paste in the XML.

Whoops. Yeah, yeah. Okay, so we'll go back to the assistant and paste in the XML. And fortunately, so I don't make any typos, I have typed in the definition for the controller we want to add that will put that badge in that window. We're in text edit and I'm just going to slap it in at the bottom here.

Okay, so you notice the last point on Ernest's slide was that when you freeze XML, you actually need to register that frozen XML component with the rule system. Well, all that means is you need to write a rule to tell the rule system, hey, I want to use frozen XML for this particular part of my application. So again, I have written that rule over here before, so I'll make sure that it's typed right. I'm going to add it to my project like that.

and we're gonna build and run. Okay. A few things you may have noticed there that I glossed over is that I added the new rule to a file called d2w.d2wmodelfile. Now, that's just simply a file that I added to my project. Notice also this user.d2wmodelfile. The reason you don't want to add your own rules there is because that's where the direct-to-Java client assistant puts rules.

So it has control, it owns that file, you don't want to mess with it. So by simply adding a file called d2w.d2wmodel to your project, you have control over that rule file. So, if this works, which it will, when we ask for a form window for the listing entity, we should see the powered by web objects badge on the bottom.

There That was a little harder, Ernest, but next time. Okay. Thanks, Brent. That wasn't too bad. So Brent just added an import statement, as you saw, and he just changed the class so that WebOpticsComponent extends, simply because we create a WebOpticsComponent and then make that a D2W component to be used with our rule system.

But some of us don't really consider import statements to be actual lines of code. So I would still argue that he still hasn't written a single line of code. But thanks, Brent, for demonstrating that technique. So we've seen how to freeze XML. Let's delve a little more into freezing interface files.

So freezing interface files, just like freezing XML, allows you to bypass the dynamic rule system to build part of the user interface. But it also allows you to bypass XML generation altogether. If you choose to freeze XML, this means that you will have created an interface file using the interface builder tool. This actually affords you the maximum control over the layout of the widgets, resizing behavior, and even the kinds of widgets that you'd like to use. Just as with freezing XML, you can define a complete window or just part of one.

Similar to Freezing XML, Freezing Interface files requires you to write a rule to register the interface file with the rule system so that it actually gets used to build part of the user interface. Another thing to remember, though, is that when you're mixing frozen interfaces with dynamic ones, you also need to write another rule to suppress some of the standard subcontrollers from being generated.

And if it's not too much trouble, I think I'd like to make things a little more concrete by asking Brent to give us one more demo. Okay, I suppose. One more. All right, so let's start with the application from the last demo. And let's take a look at the form window for the agent entity. We'll pick Andreas. He's a nice guy.

And so this window is okay, but you know what? The interface I'm getting from the dynamically generated XML and all that, I don't really like it. You know what I'd really like to do, Ernest? What would you like to do, Brent? I would love to use Interface Builder to build this window. Be my guest. All right.

So we're gonna do that. It's actually pretty easy. So we're gonna go to Interface Builder, which is a tool that should be familiar to anyone who has done Mac OS X development. Guess what? We can also do Java Client development with it. So I'm gonna start by selecting an empty Cocoa project type. And the first thing I'm gonna do is I'm gonna save it into my project.

That is the name of my project, right? Yes. Okay. We are going to call it Agent Form Window since we're customizing the form window for the agent entity. Since Project Builder and Interface Builder are so smart, it's going to ask me if I want to insert it into the project.

Of course, it would do this, but this is a demo, and since everything is going so well, this is where Ernest has obviously sabotaged my machine so that I cannot actually add this new file to the target in Interface Builder. But that's okay because there's always a workaround.

So this is actually rather easy. We saved the Nib file as agent form window. I'm simply going to drag it into the interfaces group in project builder and add it to the web server target since it is associated with the client application. So there it is. And I'm going to open it from within the project.

OK. Now we're all good. That wasn't very nice of you, Ernest. But we worked around it. OK, so there are a few things we have to do to successfully use a Nib file within a dynamically generated user interface. First thing we have to do is associate files owner, which is the object with which the Nib file is associated, to a particular class. And in this case, we need to associate it with the EO form controller class, which is in the EO generation package.

For those of you who are familiar with some of this, you may notice that some of the package names are a little bit different than you expect. We are showing you the future version here and we've renamed some of the packages, so don't be confused by that. So, anyways, we're going to select EO form controller, associate files owner with it.

And then I'm going to just drag out a window, just like you would do building an application. And I'm going to bring up UL Modeler. And I still have that model file open that we've been using throughout the whole presentation here. And Interface Builder and UL Modeler can speak to each other. We hope they can speak to each other.

And it's as easy as dragging an entity or a relationship from UL Modeler into the window over there. And they're not playing nice now, so that's why we saw that little dialogue. So what we got here, if we choose Test Interface from the Interface Builder menu, you'll see that we're actually talking to the data store and getting the data back.

And we have, let's A successful master-detail relationship just by doing that drag here. So we select a master object up here and we see its detail data in the table down here. Okay. So, now the reason we're using Interface Builder is because we actually want to customize this part of the UI. So there are a few things I don't care about here. I don't care about the user type, password, login.

The agent name, first name and last name, are probably OK. And then down here in the detail field, you can collapse some of these and you can even add formatters just like you would in a Cocoa application, things like that. And we translate all these out to Swing4You so you don't have to worry about it.

And I can even do things, if I want to make editing a little bit easier, I can add some text fields. You get the nice Aqua UI guidelines for you even in a swing app, which is kind of nice. And I'll drag out a label here. First name.

One thing to recognize in this is that we support most of the widgets you get in Cocoa and Interface Builder, but not all of them, so we have to consult the documentation to figure that out. You noticed when we dragged in the relationship from Elmodeler, it added a bunch of objects to our nib file window. It added a display group for the agent entity.

It added a display group for the listings relationship in the agent entity, and it added this editing context object. We need to do a few things to get this all to work, and one of those things is connect files owner. Files owner has some outlets, and if you're familiar with that paradigm in Cocoa, this will make sense to you. Otherwise, don't worry about it.

We're going to connect files owner to the window here, connect that on the component outlet, and also the editing context there. And for the text fields that I added here, when I select an agent name over in this table here, I also want that name to display in these two text fields here so I can edit them rather than have to type in the table, which would be cumbersome. So we can simply control drag and make an association to that property in the agent entity. There's first name. And then, last name. OK. So now we save that, and if you test the interface, just make sure we connected everything correctly.

There you go. So you can see now how the names are displayed over there. It's a nice feature being able to test the interface like that. Isn't that great? Okay, so now it's nice that we can use this in Interface Builder, but your customers probably won't. So we actually want to use this, integrate it into our application.

So back in Project Builder, you see we've added the NIV file to the project. And just like we did with Frozen XML, we need to register this NIV file with the rule system. So again, I've written these rules, so I typed them correctly. I'm going to paste them into my D2W model file. And I'll explain them in a minute here.

So I'm adding two rules. The first rule says that for the form window, for the agent entity, I want to use a Nib file. And we specify that with the archive key, and then we point it to the name of the Nib file we just created. The second one speaks to the last point on Ernest's last slide, is that when you use a Nib file, you also have, you want to tell the rule system to not generate the XML for that part of the window for which you're using the Nib file, otherwise you'll have redundant display there and it will be a little bit weird for your users.

So if we've done everything correctly, which I'm pretty sure we have, we build and run the project, it's going to find the Nib file and include that, and then when we ask for a form window for the agent entity, rather than get the dynamically generated XML that the rule system gives us, we should get that static interface that we built in Interface Builder. Okay, so I'll search for agents. There we go. So, that's pretty cool. And just to show you that, yeah.

So I guess that's it. You didn't stump me, Ernest. Try harder next time. I think you've earned your lunch, Brent. Thanks. But notice one thing. He still didn't write a single line of code, but he did a lot of clicking and dragging, so that's okay. So we've seen how to freeze XML, and we've seen how to freeze interface files. So let's delve into the third and most heavyweight customization technique, writing code.

If you decide to take the leap and write code, the possibilities are endless. Sadly, my time with you today is not, so I will just brush upon some of the things that you can do when you choose to write code. Probably the most common thing you'll do is to create your own controllers. And you'll probably do this for a number of reasons. But when you do, what you'll do is you'll write subclasses of the existing EO controller classes that have been provided.

One thing that you can do is to try your own custom widget or association, if you like. Another thing is to try a completely different layout mechanism that will dramatically change the way that your user interface appears. Another thing to do is to plug in a special qualifier or fetch specification to change the way that the application retrieves data objects.

And one other thing that you can do is to add additional actions. So if you see the menu of your Direct to Java Client application, perhaps there will be another item in there that says, generate a report about the business object that the user is currently viewing. So again, the possibilities are endless. Now, as I mentioned before, you can even go so far as to programmatically change the behavior of the factory. Let's say that you are completely unsatisfied with the overall structure of a direct-to-Java client application. You just can't stand the way that the default application does its things.

Well, if you programmatically change the factory behavior, you can completely customize the flow of the user interface. So what this means is that you can write a subclass of the controller factory and plug it in, or you can even implement some of the delegate methods that the controller factory provides in order to change its behavior.

Now, I could burn up the remaining time that I have together with you talking about these customization techniques in more detail, especially programmatically changing the factory behavior. I think that could take the rest of the session. But because I think it won't really be necessary for the most part, and because it will be so much work, especially for Brent if I force him to do it, let's not and say we did.

Instead, let's use some of our not-so-endless time together to talk about a topic that is of great interest to many people these days, web services. Hopefully, you attended the previous session, session 705, on web objects and web services. There was a pretty good explanation of what web services do. They are, roughly speaking, public APIs available over the Internet. So these are programs that you can execute and use in your own applications. Well, it turns out that there are some really interesting symptoms.

There are similarities and differences between web services and EO distribution. These are both technologies that are distributed and platform independent. Key difference, however, is that EO distribution is highly performant. It is tuned for interoperability with enterprise objects. So there's the simple reason. If you attended the previous session, you found that the crux of the support for building web services and web objects is, well, direct-to-web services.

So it may interest you to know that direct-to-web services and direct-to-Java client use the same kind of rule system. So this is, I think, the most interesting part about working in rapid development, the ability to go beyond the traditional programming techniques and to use advanced techniques to create powerful applications in such a short amount of time.

Same thing that we have for Direct to Java Client applies for Direct to Web Services. What you may have also noticed in that session is that there is an extremely powerful configuration tool for Direct to Web Services, namely the Direct to Web Services Assistant. As it so happens, the Direct to Web Services Assistant uses many of the same customization techniques that we've been talking about today, such as writing rules or freezing XML. So now that we've talked about web services, I could ask Brent to come back up here and give another demo. But actually, I'd like to give him a break. And I will actually show a project that we've prepared for you.

So we've already created a project that has client stubs for accessing a web service. So we created those client stubs using the Apache Access, WSDL to Java generation tool. It's a really neat tool. And we found the web service just on xmethods.com, or you can go to other things like South City and search for web service.

Why did we want to use a web service? Well, if you remember the-- If you remember the way that the windows look inside of our Direct to Java Client application, notice that there were many fields for certain windows, especially for the listing form window. So there, if you wanted to specify the address, you'd have to fill in the street, the city, the state, the zip code. And what we were thinking is that it might be really helpful to save the user of such an application time if they were to be able to just type in the zip code and to just get the city and state from that.

Now, when you create an application, really you want to be focusing on the business logic required to create an interesting application. But there are certain kinds of business logic that you may not be interested in. So you may not necessarily want to get into the business of writing or publishing a service that returns a city and state based on the zip code. So why not let someone else do that? So you can focus on the business logic that you find interesting. So to do that, it was really simple.

We took the frozen XML for the listing form window, which is similar to the result of the third demo that Brent gave when he froze the XML. And let's make this a little bigger. And what we did actually was to plug in our own controller into that form.

So actually, right here, inside of the frozen XML, we simply inserted one more node, which is to use a controller that we created called the zip code controller. And there's a label that says, fill in the city and the state. And if you look at the user interface of that application, you'll find that it's there.

But... Let's take a closer look at that controller. If you look at the zip code controller, it turns out that the code for that is really short and is really very simple, because what we're doing is we're extending a class called the EO Web Service Controller. So the important thing about this class is that it implements a method called execute with object. I'll return to this later. Let's take a look at the web service controller itself.

This is just a very simple example of what you can do when you create a controller. So it has the default constructor and one that takes an XML on archiver. That's not really so interesting. And in addition, it has logic for the enabling and disabling of the button. The most important thing to note is that there's this method called execute. Which looks at the selected objects in the controller and for each of those objects invokes a method called execute with object. And as a convenience, will pass along the selected object itself.

So given that this web service controller, which by the way is an action trigger and will be available in the next release, does all that for you. All that the zip code controller has to do is implement the execute with object method. The code for this is actually very simple and very standard.

And what it's really doing is it's making a connection with the service, and it is sending out a request. So given the zip code, the value of the zip code that is currently in the controller, it will actually send a request to that web service to get back the city and state, and the service returns it as one string. So we just take care of a little logic to extract out the city and extract out the state. And we set that on the selected object. And that's all this controller has to do.

So if we go back to the application, And we're to type in the zip code. Unfortunately, that's all that this controller will do, because for the moment, the web service is actually down. And that's just one of the perils of working with web services. You want to use a reliable web service in your application. But note that the controller gives a very nice message, an error dialog that says, please try again later.

But if that service were to be up and running, the answer would have been that 92612 corresponds to Irvine, California. And I would have asked, to a round of rousing applause, is there Irvine in the house? Unfortunately, that will have to happen next year. So if we could go back to the slides.

I think you'll have noticed something very interesting with the series of demos that Brent kindly did for us and for one that I did just up there, which is that With Direct to Java Client, your development process actually begins to evolve, the process itself, to the point where you can actually develop in iterations and focus on the business logic. So you can develop in iterative cycles, and at the beginning and end of each iteration, you will have a fully functional application. So this is very much compatible with the spirit of iterative development methodologies like extreme programming.

So the important thing is that at all times in the development cycle, you have a fully functional application that you can always choose, if you want, to deliver immediately to your customers or to your investors. It's really up to you. So what we recommend is that you start by creating a database and a data model sufficient enough to run the default application. And in Direct to Java Client, customization is really quick and easy. So what you find is that prototyping becomes very efficient.

And since customers, as customers do, have a tendency to change their minds about the user interface even after the product has been delivered, what we recommend is that you delay polishing the user interface. Make the changes to the user interface layout and application logic later, until the business logic has been finalized. And that way you will be able to deliver maximum value to your customers or your investors at all times throughout the development cycle. So the benefits of developing this approach are many. As I mentioned, fast and efficient development.

which is one of the key advantages of using Direct to Java Client, the fact that it generates user interface dynamically in such a short amount of time, and that there's an immediate reaction to changes in business requirements and data model. How many times have you seen a project not quite meet requirements or to have to accommodate late incoming requirements because, sadly, as the reality of developing is, the requirements change? Well, with Direct to Java Client, you can actually see immediately what those changes in the business logic or data model would do for the application.

Key advantage, again, is that it reduces testing time. Direct to Java Client provides all of these built-in application functionality components for you, and it's reliable, so you'll spend less time testing. And finally, and perhaps what is the most important thing, is that you can start to return to your core competency, which should be the business logic. Because that's really where you're adding most value, the most value as a client application developer. Not all of the client, you know, application interface logic, but actually the business logic.

So it is actually my privilege to be able to give you a glimpse of where we're focusing our efforts into the future of Direct to Java Client. So it turns out that we've heard some feedback from many of you. And what we've heard is that three-tier applications are nice, and they provide hooks for security. But sometimes they're a little bit hard to maintain, or even to understand.

So as a result, we're In the next release, what we plan to do is to provide support for two-tier applications. So what we've done is we've actually allowed you to eliminate the middle tier, to cut out the middle man, so to speak, so that there's no application server. And the client will just directly access the data from the database.

So that will be coming in the next release, or what we plan to put in the next release. Hey, Bob. There will also be a number of new controllers which help you to add more polish to your user interface. There's a really fun-to-use split view controller, and there's actually an extremely powerful tree view controller, which we saw in the direct web services assistant demo in the previous session, and which is a controller that I like to use quite a lot. And so for those of you who have been waiting a long time for a tree view controller, you won't have to wait much longer.

All things willing. And along the way... Which is great for you, by the way. A number of enhancements have been made to the dynamic layout. Issues such as having to do with the resizing of widgets or the placement of widgets have, for the most part, been resolved. So this is, again, work that you didn't want to do, that you shouldn't have to do, and that you will no longer have to do. Thank you.

I wasn't the only one who did it, but I don't mind taking the credit. And as always, we are looking for new ways to better support web services. Because again, web services are not just a really hot topic, but going to be very important sooner than later. And so the EO Web Services Controller in my demo that I showed you was just one example of some of the things that we're thinking of doing. There are probably a lot more that we can do. But again, we're going to try our hardest to make WebObjects the best platform for developing web services and the applications that use those web services.

So in summary, I would just like to say that Direct to Java Client is truly a developer's best friend, because it makes your life a whole lot easier. The key thing about Direct to Java Client is that it dynamically generates user interface based on information in the data model.

Direct to Java Client comes with a great deal of controller classes that provide pre-built, pre-tested functionality for you. Again, that's probably a key advantage of using Direct to Java Client, that you get so much for free. Finally, Direct to Java Client has been designed for extensibility. There are a number of powerful customization techniques so that you can create precisely the kind of user interface that you desire. Thank you.

If you haven't already, there is a WebObjects lab in room L, and you can still attend today, and also Thursday and Friday, so you can start to experiment with Direct to Java Client right here at WWDC. In terms of a roadmap, some of the sessions that you can still attend include the session that's coming up in this room, the WebObjects Java Client session.

And I strongly recommend, for those of you who have a little bit of background in EOF and want to learn more, to attend the Advanced Enterprise Objects Frameworks session. Because Direct to Java Client, it turns out, is actually a very good tool for testing your business logic and some of the advanced techniques that you want to use with EOF. can contact Tony and Bob if you have any comments or questions about Direct to Java Client. And for training, support, and certification, you can contact iServices.

For more information, there's a great deal of documentation online. By now, you should be familiar with all the links. Interestingly, there are also a number of user groups or other support groups online that have a great deal of information as well. And I strongly recommend that you read Java Client Desktop Applications. This is a terrific resource. It has a lot more information, a lot more detail about things like programmatic customization techniques, some of which I couldn't cover in as much detail as I would have liked.

Had my time with you been endless. It's all right here in this great reference. To access the documentation, most of it can be accessed online. Some of it comes on the CD, in the box, or can be printed on demand. It's a wealth of great documentation now, and we're adding more all the time.