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 a really fun team to work 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, turns out that WebObjects also has a great technology for developing desktop applications, Java Client. So Java Client is a technology for creating distributed And 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-JavaClient 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-JavaClient.

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-Job Clients is all about. And here to help me with that is Brent Schenk of Technical Publications. Thanks, Ernest. Thank you.

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 directed Java client application. in the project builder.

Assistant, I am mostly-- I'm just gonna 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. And you see this Web Start pane here, and this helps us configure the Web Start JNLP file that we will use to deploy this application. Whoops, I meant to do that. 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 is a record i can make changes 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 obj, a j, a Java client application is a web objects application with the addition of a rule system on the server side. The rule system is what actually generates a description of the user interface. And a Java client, client becomes a direct-to-Java client, 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 eye's view of the application architecture, let's talk about some of the core concepts in creating a Java client 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 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 lay out 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 the user interface.

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. there. 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 directed 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.

we'll give it a different name. And by default, the first window in 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 say we're going to do a different behavior. So, 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 these pane of the assistant, and you 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.

Third, there are entity-level controllers, which are responsible for managing business objects. Examples of these include the query window and the form window. And finally, there are property-level controllers, which work at a finer grain of detail than entity-level controllers. A good example is a text area controller. So given that we have all of these kinds of controllers and that you need many controllers to create an application, how are we supposed to organize all these controllers? And the answer is that the controllers are organized in a hierarchy. This turns out to be very fortuitous, because if you look closely at the visual components of a user interface, what you'll find is that they naturally fall into a hierarchy.

So there is actually a one-to-one mapping between the hierarchy of controllers and the user interface. So the user interface that gets rendered depends on the hierarchy of controllers. So we have a way to organize the controllers. But then the question is, well, we still need a way to define those controllers in the hierarchy. So how do we do that? Well, in Java Client, controller hierarchies are defined in XML. This also turns out to be a very good choice. The reason XML is a suitable format is that XML happens to be hierarchical in nature, too. An XML document is a hierarchy of XML elements.

So for each controller, there is actually an XML node in that document, and for each of the kinds of controllers, there is a unique XML tag. So given that the controllers are organized in a hierarchy and defined in XML, let's talk about the layer in the application architecture that's responsible for generating the user interface in XML, and that is the rule system.

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's an instance of UApplication, and in Direct to Java Client is an instance of EODynamicApplication. 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 directed 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 class. 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 Wo 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 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 Director Java Client Assistant, there is an XML pane. And so if you switch to that, you'll 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 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 Auditors component, in this case, an instance of D2W component. so we want to freeze listing window for the form uh... form window for the listing entity it might be nice to add like a a badge for your real estate agent or something there so we're gonna freeze xml to accomplish that we need to find xml description for that particular task and window in this case it's the entity listing and the task form so i'm simply gonna 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. And this is going to hold the frozen XML that we customized. So 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 directive web package. So I guess this is writing code, but it's not really writing code. Okay. 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. OK, 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. Over 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 and we're going to 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 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 we go. Thank you. That was a little harder, Ernest, but next time. Okay. Thanks, Brent. That wasn't too bad. Thank you.

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. And 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 would 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 my project right yes we're going to call it agent form windows since we're customizing the form window for the agent entity And since Project Builder and Interface Builder are so smart, it's going to ask me if I want to insert it into the project. Now, 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 NIV file within a dynamically generated user interface.

First thing we have to do is associate files owner, which is the object with which the NIV 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 UoFormController, associate files owner with it. - Okay. 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 ULModeler. And I still have that model file open that we've been using throughout the whole presentation here.

And Interface Builder and ULModeler 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 ULModeler into the window over there. And they're not playing nice now, so that's why we saw that little dialog. 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 see, we 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 'cause 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 column-- user type, password, login.

the agent name, first name and last name are probably okay. 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 Swing for you 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. And 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 you have to consult the documentation to figure that out. Okay, so you noticed when we dragged in the relationship from EOModeler, 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. So we need to do a few things to get this all to work, and one of that, 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 can 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. Okay. 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 gonna 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 real system gives us, we should get that static interface that we built in Interface Builder.

okay so search for agents There we go. So that's pretty cool. And just to show you that, yeah. Thank you. So I guess that's it. You didn't stump me, Ernest. Try harder next time. I think you've earned your lunch print. 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. AND I THINK IT IS A GREAT 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 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 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 web services which may have also noticed in that session is that there is an extremely powerful configuration tool for direct web services namely the direct web services assistant as it so happens the direct 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 just be able to just type in the zip code and to just get the city and state from that. Thank you.

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 returns the 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. Let's take a closer look at that controller. If you look at the zip code controller, turns out that the code for that is really short. It's 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. execute, which looks at the selected objects in the controller and for each of those objects invokes a method called executeWithObject. And as a convenience, we'll 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 the 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 were 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? But... 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 the 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. - Okay.

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-- 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-to-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 TreeView controller, you won't have to wait much longer.

All things willing. And along the way... Which is, 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, we're going 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. Thank you.

If you haven't already, there is a WebObjects lab in room L, and you can still attend today, 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 the 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.