So this is the WebObjects Technical Overview. And if you attended the State of the Union, a lot of the content is going to seem similar, but we're going to go in a lot more depth than you saw in the State of the Union. And we're going to cover a lot more parts of the technology.

So what is this session all about? Well, it's really about power, because WebObjects is about power. And this session is about teaching you how to harness the power of WebObjects in the applications you write. But it's also about elegance. You ask a lot of veteran WebObjects developers why they like using WebObjects, and they say that it's very elegant. And another reason they like it is because it's sophisticated. And the point is not that WebObjects is sophisticated, although it is, but it helps you build sophisticated applications and allows you to do really difficult things that other application development environments make it very hard to do.

But fundamentally, WebObjects is about productivity. You have to write a web application, so you have to get something done. And WebObjects helps you get to market faster and write a better application the first time. And WebObjects, once you get it, it's a lot of fun. So we're going to hopefully have some fun today.

So what are you going to learn? You're going to learn what WebObjects is. Most of you probably know what it is. But most importantly, we're going to show you what you can do with WebObjects. And when you think of WebObjects, you probably think of HTML applications. But it's really much more than that, because it's designed to be very flexible, very modular, and so you can target types of network applications that you might not know that you can. So we're going to show you some unique examples. And then we're going to show you how to learn.

And to learn WebObjects, you need to know about the building blocks and the tools that you use to build these applications. So we're going to look at each of the tools, and we're going to look at each of the frameworks, of the most important frameworks in any WebObjects application. And then we're actually going to go behind the scenes.

So we're going to go behind the scenes in running a WebObjects application, so you can get a sense of the objects that are involved in that application, and what your role as a WebObjects developer is in building those objects and adding value to the objects that we provide you. And throughout the session, the whole idea is to help you know and get a sense of how to start learning this technology.

So, first of all, what is WebObjects? Well, if we can come up with a one-sentence definition that encompasses everything WebObjects is about, this is probably it. It's software made up of frameworks and tools that help you build network applications with data from multiple data sources. Well, this is a long way of saying that really, WebObjects is an application server.

So this isn't a marketing talk, but if you're going to build WebObjects applications, you need to know why WebObjects is a good tool for the job. And there are three main reasons, and these are really three themes of the presentation today. The first is that WebObjects lets you focus on business logic.

Now, lots of other app environments force you to focus on things that you can't add a lot of value to, like writing the code to actually access a database, like JDBC code, or writing SQL to actually get data from a database. But with WebObjects, we take care of all the minutiae of app development that you usually have to do in other environments, and this lets you focus on writing your business logic. And that's why you're writing an application in the first place.

And like I said, one of the reasons lots of people like using WebObjects is it's very productive. It helps you get to market faster. We provide a set of rapid prototyping tools that allows you to have a working application in literally minutes. And from there, you iterate and build this application that, as Wiley said in the State of the Union, your 1.0 application is usually better than a 2.0 application that you would get in another app development environment.

Brent Shank And the WebObjects development provides a unique development cycle that offers more opportunities for feedback throughout the whole development cycle. So rather than just gathering customary requirements at the end and showing them the final product, we know that that's not the reality of software development. Requirements change, and WebObjects helps you adapt to those changing requirements throughout the development cycle.

So let's back up. Now most of you probably know what an application server is, but let's provide a broad definition of it. Well, an application server provides a service on the web. This could be a banking service, or a student tracking service, or some kind of travel service.

And the reason you're providing it on the web is that the value of that application is only as good as many users use it. So you have tens, hundreds, maybe thousands of users, and it doesn't make sense to deploy this application on the desktop. Now with WebObjects, of course, you can deploy distributed network applications that run as desktop applications, but the point is you want to distribute this to many people.

And the people who use your application, they might just read the data in that application, but most likely they're actually contributing to the data in your repositories. And with WebObjects, we help you use data from multiple data repositories and present that in a meaningful form in your end application.

And these days, it's very common for applications to exchange and share data. And so we're going to talk about how to do that. Brent Shank So let's get started. So we're going to start with a web application. data with other applications. So rather than an application just living in its own world, we use web services and other technologies to communicate with other applications, which adds value to all of them.

So if we can come up with a picture of what an application server is, this is a very simplified form. So on the one hand, we have data repositories. And on the other hand, we have WebObjects. And the important thing to know about WebObjects is that it doesn't matter what kind of WebObjects these are. They can be HTML clients.

They can be swing desktop applications. They can be Web service clients. Or almost anything you can get to through Java objects. And the role of the application server is to mediate between the data sources and between the web clients, and to help you get data out of those data sources and present it to a meaningful form to web clients.

And of course, an application server relies on a web server to actually communicate with the outside world. So we're going to go back to that picture throughout the presentation, so keep it in mind. So like I said, when you think of WebObjects, well, the word "web" probably connotes HTML and browsers. But that's not all WebObjects is about.

With WebObjects, out of the box, you can target almost any type of network client. Most commonly, people target HTML clients, web browsers. But also, it's very common to target swing clients. These are desktop applications that run on the user's machine, much like Word or iPhoto or something like that. And the reason you would do this is you want to provide a more rich user interface than HTML allows.

But also, with WebObjects, out of the box, we also allow you to target SOAP clients, generic XML clients, and even something called SMILE, which is the synchronized multimedia integration language that's supported by QuickTime, RealPlayer, other multimedia clients. And we provide a specialized framework so you can build very rich multimedia applications, standard-based applications that have all the rich access to databases that WebObjects provides. And because WebObjects is written in Java, you can target almost any type of network client that you can get to. through Java, such as PDF and SVG.

So just like WebObjects helps you target almost any type of network client, you can use data from almost any type of data source. And out of the box, we provide connectivity to JDBC and JNDI data sources. And other third parties provide connectivity to other solutions, such as SAP.

So one of the best parts about WebObjects is that it allows you to access these data sources through Java objects. So rather than have to worry about writing your own JDBC or JNDI code to actually connect to these data sources, we provide abstractions to these data sources. And you interact with these objects, and usually you don't actually need to interact at all to make these connections, these objects which are Java objects. So you think in Java, you think at a very high level, you think in object-oriented terms, and WebObjects does the work of connecting to data sources for you.

And just like it takes care of accessing those data sources, it also allows you to express your business logic in Java. So a common way of expressing business logic is to do it in the database, so doing it with stored procedures and triggers and things like that. And that locks you into that database.

You have to write in very low-level code. But with WebObjects, we allow you to express that business logic in Java, which is really a much more pleasant way to write your business logic. And how do we do this? We do this through software that we call the Enterprise Objects.

And this is kind of the crown jewel of WebObjects application development. This is the technology that helps you access databases, helps you write your business logic, and is really the core element to any WebObjects application. You're going to become familiar with these two icons. The one on the left is the icon for EOModeler. And EOModeler is an application that helps you build EOModels, which is the icon represented on the right.

And these EOModels are descriptions of your data. They help WebObjects. They provide WebObjects a mapping between your relational data and Java objects. We're going to talk much more about that in this session. So let's go into a little more depth about the three types of most common types of client applications you target with WebObjects. And the first is HTML applications. And the goal here is you want to provide dynamic content, and you want to provide it to web browsers. You might have an online catalog, and you want to provide customers with a customized look and experience when they enter your catalog.

With WebObjects, you build the pages that your HTML applications express with templates. And these templates are built on the ideas in a proven component model. And what we mean by that is we spent a long time coming up with the best way to design these pages. So you build these templates, which are based on this model.

And this component model has a lot of interesting features. One, the templates you write are usually reusable, so you can reuse the same templates within one application or even between applications. So this is part of the way that we help achieve reusability, but also help you get to market faster through reusability.

And since WebObjects 5.1, we've heard your request, and we've also-- now we allow you to integrate your favorite parts of the Java server pages technology right with your Web Components. So if there are parts of the JSP model that you like, we allow you to integrate that with our component model, so you get the best of both worlds. And some well-known examples of HTML WebObjects applications are Apple's .Mac suite of services, providing the home page application and mail, and also the Apple Store.

So another very newer type, a very popular type of client application you can target with WebObjects is a web service application. And in web services, there are two types of applications. There are web service servers, so that we say they vend database content through web services, which is a set of standard protocols.

But the other part of that is a web service client that actually consumes the data that this web service server vends to you. And with WebObjects, we allow you to build both types of applications. We allow you to build the server and the client. And we do this by putting a layer of abstraction on top of Apache Access.

Apache Access is open source software for helping you build web services. And it's a great set of software, and we love it, but we've made it even easier to use by providing a layer of abstraction on top of that. And we've even done a lot of work to provide you with plug-ins so that you can serialize WebObjects objects that you build and enterprise objects that you build.

So my favorite kind of WebObjects application actually is a Java client application. This is what we call client applications that are written in swing. And the goal here is you want to provide dynamic content to an application that runs on the user's machine not in a web browser but just like an application.

So an application that the user can double click. And as of WebObjects 5.2, we actually allow you to do this with two architectures. We officially support the three-tier architecture which includes the WebObjects application server in the middle. And in this architecture, the app server mediates all access to the database. So it's very secure and you have total control over what the client sees.

But we also allow you to build two-tier desktop applications that allow -- in which the client application accesses the database directly. So if you don't want to worry, if you don't have the need for the WebObjects app server in the middle, you can also build that type of application, which is great.

My favorite part about WebObjects Java Client is the dynamic user interface generation provided by something we call Direct-to-Java Client. What does this do? Well, it allows you to build these swing desktop applications without actually writing any of the swing. We have something that we call the rule system, and the rule system helps Java Client produce these very rich swing user interfaces. So we actually have apps internal at Apple, Java Client apps, that don't have any swing code in them, but they're these very full-featured, rich desktop applications. It's a great part of the technology. And WebObjects Java Client also has a business logic distribution architecture.

What does this mean? Well, you have business objects in any WebObjects application. And usually, these business objects just live on the WebObjects application server. But when you have a Java client application, you have a client that's smart. Especially these days, clients are very robust. They have lots of memory. They have very fast processors. So you can actually put some of these business objects on the client side.

And when you do this, you increase performance. There are drawbacks, of course, because any time you put a Java object on the client, it can be easily decompiled and things like that. But this business logic distribution architecture is flexible enough to allow... So it gives you total control over how you want to distribute your business objects.

And in WebObjects 5.2, we even took care of one of the most difficult parts, most tedious parts, of deploying desktop swing applications over the net, and that's deploying the client application. So we've integrated WebStart for you, so without having to configure JNLP files or do anything, we just provide a hyperlink when your application starts up, the client clicks it, they automatically get all the WebStart functionality, and you don't have to worry about it. So that's part of the heavy lifting philosophy that WebObjects takes care of all the hard work for you.

Brent Shank And so this is an example of a Java client application. You can see it looks like a Mac OS X application. It assumes the Aqua look and feel. Now, of course, you can run this on other Java 2 platforms, so you run it on Windows, and you get the Windows look and feel. And we can edit properties and edit relationships, and again, all of this is done dynamically on the fly as the user moves around the application.

So those are the three most common types of client applications you can target with WebObjects: HTML, Swing, and Web Services. But I said before that WebObjects was designed to be very flexible, and allows you to be creative and to build new kinds of applications. And one of those that you're very familiar with, I'm sure, is the iTunes Music Store.

It's actually a WebObjects 5.2 application on the back end, and iTunes sends requests to the WebObjects application, and this application hands back XML that iTunes then interprets and presents to the Music Store. And it's actually built with a lot of our direct web technologies in the back. It's very cool stuff. That's just an idea of the flexibility of the WebObjects framework. It allows you to do almost anything you want, build any kind of network application.

So if you attended the WebObjects State of the Union, you're familiar with our new documentation site, which just went live yesterday. And it's actually, the pages are all static pages, but these pages come from a WebObjects application. So at Apple, we have this running application, and a couple times a day, we ask the application to generate a static version of all of its pages. So we create this virtual site map, and we traverse each of the directories and each of the nodes on this site, and generate static versions of the HTML pages.

Brent Shank So if you attended the WebObjects State of the Union, you're familiar with our new documentation site, which just went live yesterday. And it's actually, the pages come from a WebObjects application. So at Apple, we have this running application, and a couple times a day, we ask the application to generate static versions of all of its pages.

So at Apple, we have this running application, and a couple times a day, we generate static versions of the HTML pages. what this means is we get all the features or most of the features of an application server, but with static HTML. So you notice if I look at the Cocoa documentation, I can sort this list by simply clicking a column header.

Now, what I'm doing, I'm not talking to an application server, I'm just asking for a static HTML page that's been pre-generated. So this gives us the advantage of we can deploy these pages, we can serve these pages with Apache without having to worry about the overhead of actually deploying an application server.

So that's just another example of the flexibility of WebObjects and some different kinds of applications you can build with it. So now I'd like to bring Bill Baumgartner on stage to actually show you an example of how quickly it is to get up and running with building a WebObjects application.

So I'd like to show you two applications. One of the interesting sort of chicken-the-egg problems that every developer faces when you're starting up a project is you may have your database sort of kind of initialized in there, but you don't have any data in it. And because you don't have any data in it, then it's hard to build the app. And you kind of want to solve both these problems.

So one of the focuses of the tools, and you'll see this throughout all of the Xcode discussions as well, is that we want to keep you productive. We want to keep you moving forward in your projects. We want to make you happy developers. And I apologize, I'm a little new to Apple, so I'm learning the appropriate marketing term. So I guess, our tools kick ass? Okay, so I got that in. Good. : I'm going to show you how they kick ass. I guess I'm only supposed to use it like three times, so there's one more.

Oh, I'm sorry. Wrong menu item. Yeah, so I'm going to create a new project now. Thank you. And I'm going to create a new direct web application. And I'm going to not use that name. I will call it VideoStore. And my goal here is I have a video database.

Now, if I was into typing in demos, I would have gone into eoModeler and actually reverse engineered the database. But I've already done that. So I'm going to take already existing models of my database and just build an application on top of that. So we'll call it VideoWeb, because we're being arrested.

And we will choose the default actions, once again, emphasizing productivity. Our default behavior just moves you to your goal. And we will add a couple of eoModels here, which this is interesting. Notice I'm actually adding multiple models. What this means is that, again, these tools, what I'm showing you is very simple. However, the implications are complex.

You can have multiple databases. You can have data across those databases. You can have relationships between data on a Sybase database, an Oracle database, a front base, and LDAP. And I'm going to choose the neutral look. So let me go ahead and just create the project, let it build and run, and we'll see what we get.

Excuse me. Now, what's interesting about this demo is actually the tools I'm using here are the same stuff that's used to build things like the Music Store and other wonderful technologies out there. So here's my application. It's already up and running. Let me go ahead and log in. We don't take care of security on that page, by the way.

So that's something you should put that on your to-do list. So as you can see, though, now that I'm in my application, I've got all of my stuff from my database is just showing up, all my entities, which correspond to tables. I can search for things. I can actually even create, say, a new movie, or I could drill down and inspect a movie. Now I'm happy as a developer because I can go in and I can start really working with my data, and I'm five minutes into my project.

Now, of course, HTML as a user interface is somewhat lacking. And as Brent mentioned, we also do Java. So let me actually create a new project. And this time I'm going to choose direct to Java client. And we'll call this Video Web J, continuing with our tradition of originality. And again, I'm running through the default answers here. grabbing all the frameworks, adding the same two EO models. I'm going to steal them from the other project.

In this case, I'm continuing down my default. And that last screen, let me actually go back. This is kind of neat. Web start. So this will automatically create the little thing that you can just kind of shove on a web page or send an email to start the application. It makes distribution very easy.

So we'll go ahead and, again, we're following the default

So what's actually happening here is, of course, the application's building, et cetera. This is a direct-to-Java client. So now as the application launches, what you'll see is a user interface that was dynamically generated purely from a data model.

So there's a bunch of rules in the rule system that say, okay, if there's an entity that has certain kinds of attributes that are strings, then you can go ahead and create a search form automatically that actually allows for very rich interaction with the data. Now, I look at this immediately, and I go, you know, I'm doing a video store. The first thing I want to do when I'm administrating this data is I really want to focus on movies. I'm less interested about my customers because I don't have any yet.

So there's an assistant, and through the assistant, you can actually go in and modify the rules that are used to drive this application. So the first thing I'm going to do is I'm going to go to my main entities, and I'm going to bump movies up to the top of the list. And since I'm not a very good video store owner, I'm going to just remove talent because I don't like actors. So we'll go ahead and apply this and restart my application.

And as you can see already, my movies are at the beginning of the list, and I have no talent in my list. Hopefully I have talent. And for searching movies, you know, I really want to be able to do it by rating. I have a lot of customers that want to come in and they want to get Finding Nemo. I had to work that in, too. More marketing. I'm learning. And so they want to be able to search by, say, the rating of the movie.

So I can easily come in and I can say, okay, whenever I'm querying for a movie, and this is the whole rule system, I want to search by rating. And I really don't want to search by plot summary. That just doesn't make any sense. So again, I'll apply and I'll restart the app.

And I can come in and I can search for movies that are rated G. And it'll go off, and there's all my movies that are rated G. Notice Finding Nemo's not in the list. We need to update this database. But anyway, as you can see, I've, in five minutes or so, have created two applications that allow you to work fully and intimately with the data in your data stores.

And what this means for you as a developer is that you can get up to speed really quickly and get into the client or the customer or your user or your mom, if you're building an app for her, face and say, is this what you meant? Is this what you wanted? Let's go interactive on this.

Let's push our product ahead very rapidly. And as was indicated earlier, what that means is the 1.0 with our stuff usually is like a 3.0 with everyone else's, because you're learning all the time through the development process. Now, these tools, a lot of people look at things like this, and they're scared by it.

They're worried that they're going to get locked into our way of presenting the information. That's not true. With the rules system, you could actually build your own super spiffy, say, revenue display widget, and then in the rules system, say, anywhere a revenue is displayed, use this widget. So we encourage reuse throughout all of these tools as well. And then, of course, once you have this administrator, you can build your own.

And then once you have this administrative app, you start building the app facing the user, then you can reuse all that code and the business logic again. So we kick ass because you're productive, and we like to support that. There's my third one. So I'll turn it over to Brent again.

Thanks, Bill. And one thing Bill was emphasizing there at the end is that we just showed you an example of the rapid development tools and frameworks that WebObjects provides. And those tools do everything for you, but we also let you do everything on your own if you want to. And there are good reasons for starting with both approaches to WebObjects development. So now we're going to take a minute and talk about all of the tools that we provide, the great set of tools we provide to build these applications.

So Bill showed you two tools, three tools. He showed you two. Project Builder, and he showed you the Direct-to-Java Client Assistant. And those are just two tools in the suite. So Project Builder. Well, this is very important because this allows you to organize your project files. It provides new project assistants to help you get up and running with any of the WebObjects application types. It's the application that you use to actually compile your project. And we provide a front end to JDB, the Java debugger, so that you can graphically... debug your WebObjects application, which is a Java application.

We also provide CVS integration, so you don't have to resort to the command line to get full source control management. And we provide documentation lookup, so you can double click on a WebObjects method or class name, and right there in Project Builder, see the description for that class method, which is pretty cool.

And Project Builder also is part of the equation that we label Rapid Turnaround. And Rapid Turnaround is a feature in WebObjects that allows you to make changes to your applications, usually to the user interface, to save those changes and to see them reflected in the running application without having to recompile. And there are other tools that work with Project Builder to make this possible, which we'll talk about in a minute.

So I talked about EOModeler. And EOModeler is really the most important tool in WebObjects development, because it allows you to build data models. And as you saw, by simply providing WebObjects a description of your data, you can actually get full-featured running applications for free. But even if you're not using the Rapid Development tools and frameworks to build WebObjects applications, you really still need a data model, because this data model is how you provide the data to the templates, the visual pages that you construct.

So how do you build these data models? Well, EOModeler is very smart, and it will actually reverse engineer a model for you from an existing database. So a lot of projects start from existing data. So you simply point EOModeler to your database. And like I said, out of the box, this is, we support JDBC and JNDI. And it looks at all the tables and all the columns and all the joins, and it creates entities, attributes, and relationships from all that information. So you don't actually have to worry about creating the model in many cases. You may want to make tweaks to it.

But if you don't have a database, you need to create a schema. And EOModeler can actually help you think about that schema in entity relationship terms, and then it will write that schema back to the database for you. So it's a great data modeling tool also. And we also think of EOModeler as a front end to the Enterprise Object Frameworks, because it actually allows you to configure a lot of the more sophisticated characteristics of things in EOF, which we'll talk about more in a second.

So what does EOModeler do? Well, it helps you map relational data structures to Java objects. We said that with WebObjects, WebObjects allows you to build your business logic in Java objects. But in order to do that, we have to have a way to get the changes that you make to your Java objects back into the data source. So we need a description. We need a mapping of that. And that's what EOModeler does. It helps you map entities to tables, attributes to columns, and relationships to joins.

Another great feature of EOF and EOModeler is that you can model inheritance. So as a Java developer, it's common to build inheritance hierarchies into your application. So you might have a person superclass, and you might have concrete subclasses of it, such as student, teacher, administrator, if you're at an educational institution.

Well, this is a very natural way to think in Java, in object-oriented terms. But wouldn't it also be nice if you could translate that hierarchy into something that persists in a relational database? Well, we fully support that with EOF, and EOModeler allows you to map your Java inheritance hierarchies to your relational tables.

And EOModeler also helps you build fetch specifications, which are descriptions of the data you want to fetch, which also usually include things like sort orderings. And you can do all of these things in code. In fact, you can even build models in code, but EOModeler is, we provide it because it's a lot easier to do it with a graphical tool.

So if you're building HTML applications, you need to build these page templates I was talking about. So we provide a tool that helps you do that. It's called WebObjects Builder, and fundamentally it's an HTML editor, but its specialty is that it helps you write these page templates. And these page templates in WebObjects are made up of something we call dynamic elements. And a dynamic element is just what it sounds like.

It's an HTML element whose values and characteristics are resolved at runtime. And WebObjects Builder has collections of these dynamic elements on palettes. So you drag out these elements, you put them on your templates, and you connect them up to your enterprise objects. And so that's how we say that WebObjects Builder is integrated with enterprise objects.

It knows about the entities in your data model. It knows about their attributes. It knows about their relationships. These are things that your EO model provides. And WebObjects Builder also plays a part in this thing we call rapid turnaround. So in many cases, you can make changes to the HTML templates you build in WebObjects, save them, refresh the page in the client browser, and see those changes reflected without having to recompile, rebuild your application. So this is one way that WebObjects helps you get to market faster by removing some of these steps in the development process. Thank you.

So we touched on rapid development, and rapid development is one of the coolest features of WebObjects, and it includes a number of tools. So there are three types of client applications that you can target with the rapid development frameworks. One is an HTML client, other is a Java client, a third is a web services client. And each of these types of client applications has its own assistant. And these assistants are front ends to the rule system. So the rule system is, we consider it kind of like a black box.

It's very smart, it knows how to do all these things, but to interact with it, you need to write these rules. These rules can kind of be hard to learn to write. So what these assistants do is, they provide valid configurations and valid combinations of these rules that you can just choose in a graphical user interface, which has the result of writing these rules for you. And this enables code-free, rule-driven applications.

So how do these tools all work together? Well, we divide the WebObjects development workflow into three general phases. The first is a data access phase. Second is the business logic phase. And third is presentation logic. And each of the tools has a specialized role in each one of these phases. So in the data access phase, of course, the goal is to get data or get a description of the data in a JDBC database, a JNDI directory, into an EO model file. And you use EO Modeler to do this.

So that's really the first step. And once you have this description of your data, then you're ready to write your business logic. And in WebObjects, you write your business logic in Java. So you edit your Java files in Project Builder. So this is the business logic phase of the workflow. And after you've done that, you work on your presentation logic. So you use WebObjects Builder to build HTML templates.

You use Direct to Java Client to build swing applications, but you can also use Interface Builder. This is the same Interface Builder that you use to build Carbon and Cocoa and other applications. So you can use Direct to Java Client to build Carbon and Cocoa applications for Mac OS X. But we've actually extended it.

So when you build a Java Client interface in Interface Builder, we actually write out the swing for you. So in this case, we're not dynamically generating the user interface on the fly as the user moves around the application, but we're actually using a chunk of static swing that Interface Builder generates. And of course, you can integrate both the static interface and the dynamic interface in the application.

So if you need very precise control over one particular window in your application, you can use Direct to Java Client to build a dynamic interface. particular window in your application, you can do that in Interface Builder. And finally, if you're building a Web Services application, whether you're building the server side or the client side, if you're building the server side, you use something we call the Web Services Assistant.

If you're building a client, you can build browser-based Web Service clients with the WebObjects frameworks, but you might also be interested in building a Web Service client to target something like Sherlock. And so we showed this workflow and we showed the arrows going from one side to the other, but that doesn't mean that you have to finish the data access phase before you move on to the business logic phase and then finish the business logic before the presentation logic.

You can go back and make changes in any one of these realms, but this illustration is just here so you get an idea of how the tools work together. Okay, so we've talked about, we've shown you a demo of HTML applications and Java client applications, but what about web services? I'm going to bring the world's foremost Jamaican-Chinese WebObjects developer on stage, Ron Lusang, to show us a demo of Web Services with WebObjects.

Cool. Thanks, Brent. So first off, you guys know about web services and how Brent explained that with Access, we're able to bring web services to WebObjects, or vend web services through WebObjects. On top of that, we've added a technology that we call direct-to-web services, which makes it even easier to start building a web services server. So I'm going to start a new project, and I'll choose direct-to-web services as my application type. And I'll choose a silly name, as I prefer to. Again, go through all of the default settings. Choose the movies model.

And I'll just build and launch the application. So what it's going to do is put together a list of the entities in my model.

And poof. You can see here, we see we have a service. And we take the approach of being paranoid for our web services. So none of the services are turned on by default. So nobody can go in and start sending random soap to these services.

Anything that's not specifically enabled is disallowed. So we'll go ahead and enable our special default web service, called appropriately enough default web service. So we'll add an entity to our default web service as far as public entities go. Once I've added this entity, you can look over here in the service list.

And we'll add a couple of operations. So what we've done here is go through the entity that we've added and looked at what fetch specifications are defined, as well as just what arguments should be exposed as web service arguments. So we haven't written any code yet, and all we've done is focus on our business logic, and already we can already publish a web service. Let's start by just moving a couple of entities out. I just want to search on rating for my movies, let's say.

We'll remove these. We can change what arguments are sent to the web service, and what return values are sent back to the web service client. Let's just say we're interested in the title, the rating again, and we can also, from this list here, choose to see the studio name. We can go through relationships. Brent Shank And we can also, from this list here, choose to see the studio name. when we're returning values from the web service.

So all of this again is going through the rule system and changing values only in the rule system. You don't have to write any code to change the settings for your web service. Let's go ahead and return or try and test this. One of the things about web services, by the way, you really have to put together a WSDL file, a web services description language file, saying what arguments you expect and what results the client can expect to get back from invoking a web service.

Rather than have to write all that for you, or write all of that yourself, Direct Web Services generates all of this lovely XML for you. So you can go ahead and be productive immediately, like testing the application. So we'll search for all rated G movies, and we'll get back a list of all the rated G movies. You could look for PG and test it.

So one of the things that you'll also notice is we haven't had to go through and write any access code. We haven't had to do anything actually parsing the WSDL ourselves. We figured out the direct web services assistant can actually parse the WSDL and put up a dynamic UI so that we already have something that we can use to invoke the web service and test it.

If we go back, you can see if we add, say, title as an input argument, We get rating and title as the UI to test with. So we can look for all PG movies. Actually, one other thing, we can change the operator that is used. So we can look for case insensitive like.

And there aren't any G movies to start with us. So that's a simple example of how quickly you can get up and running with a web service application using the direct web services technology. It's very simple, very easy to use, and you should use it. Back to Brent.

Thank you, Ron. So there's something we need to emphasize about the demos you've seen today. Now, they demonstrate that you can go very far in a WebObjects application without writing any code. And that's true. Everything you saw here today is what you can get in the trial version of WebObjects and in the box when you buy it. But WebObjects is not a toy. It's a programmer's tool. You really need to be a programmer to use it.

Now, we take care of a lot of the difficult things for you. So you don't have to be a DBA to write a WebObjects application that uses multiple databases. But you do need to be a programmer, a Java programmer, to really build a usable application. So you can go far, but we don't want to give you the sense that you can go all the way in application development with WebObjects without knowing how to write a little bit of code. So after saying that, we need to talk about how all of this is how we make objects. So let's talk about the building blocks behind every WebObjects application. And the building blocks are something we call frameworks.

Well, what's a framework? A framework is software, and it provides a lot of pre-built functionality that you plug into. Another way of thinking about this is a framework knows how to do a lot of things. The WebObjects frameworks know how to access databases. They know how to generate HTML.

They know how to do web services stuff. But they don't know what to do. They don't know what you want them to do. So you have to provide information. You have to tell them, tell the frameworks what kind of data you want to fetch or what your page templates look like.

So a key idea about frameworks is that they do all the driving and all the heavy lifting. Well, what does this mean? Well, they know how to do a lot of things. And one of the most common obstacles that new WebObjects developers face is that they start writing all this fancy code to do all of these things that they think they need to do, when actually the frameworks do all of this for you.

So you need to learn to trust that these frameworks actually know what they're doing, and that your goal, your role as a WebObjects developer is to understand the frameworks well enough to know how to harness the functionality they provide so you write less code. And when you write less code, you write less bugs, and you write a better application. So the WebObjects frameworks have been around for a long time. WebObjects was actually the first application server a long time ago.

And because it's been around for a long time, these frameworks have had a lot of years to get really good, to the point that we say they incorporate a lot of the best practices of object-oriented programming. And they actually share a lot of these best practices with the Koko, Apple's other object-oriented framework for building desktop applications. And I want to talk about three of these because they're really important. One is key value coding.

When you start reading the WebObjects documentation, you're going to see this all over the place. And you look at the API reference and talk to people, and they're going to talk about key value coding. Well, what is this? Well, it simply encompasses the classic object-oriented design paradigm to encapsulate the thing that varies.

Well, what varies in an application? What varies is how your objects provide access to their data. They might provide access to their data through an accessor method, preferably, or through an instance variable. And the name of that accessor method or instance variable could be different. Well, what key value coding does, it abstracts away all of that diversity in how objects present their data and allows you to access data by key or by name.

And as you'll see later on, this is very powerful because if we have business objects that have very complex relationships in them, we can actually get to the data in those different objects simply by traversing what we call a key path. And this is all enabled through key value coding, name-based lookup.

Another important idea is delegation. It's kind of a complex thing, and you don't need to know about it to get started. But we said that the WebObjects frameworks are very flexible. And one way they're flexible is that the class designers, the people who design the classes in these frameworks, provide opportunities for you to customize these classes.

And they do it through something we call delegation. And this is a way for the class designer to say, at this point in this object's execution, I want to provide other developers a way to intercept things and provide custom functionality. Brent Shank So rather than requiring you to actually subclass one of our classes and override a bunch of things, we provide things called delegates, which provides you a great deal of flexibility. : And Model-View-Controller is another key idea in the WebObjects frameworks.

And this is a paradigm you're probably all familiar with. And in WebObjects development, it means the same thing. It means that we divide, we think about the objects in WebObjects in three different realms. The model realm, which is your data and your business logic. The view realm, which is what your user actually sees and interacts with. And the controller, which is the glue between the two.

So let's talk about three of the frameworks that every WebObjects application, no matter what type of client you're targeting, will use. And the first is the foundation framework. This is a set of powerful, fast collection and utility classes, things for managing your application's data structures. It's important to understand that the foundation framework doesn't replace the JDK classes. It's actually built on top of them, and it complements the JDK classes.

But like I said, WebObjects has been around a long time, and was actually not written in Java originally. So a lot of these classes predate a lot of the JDK classes. And they're very mature, and provide a lot of really great functionality, a lot of which you actually don't get in the standard Java classes.

The foundation framework also provides an infrastructure for notification. In a WebObjects application, you have possibly hundreds or thousands of objects running at runtime, and usually they need to communicate with each other. Maybe a user makes a change to a business. Well, chances are that other objects depend on the state of that object.

Well, a notification architecture allows those objects to communicate in a way so that the objects are very loosely coupled. So we have another object that we introduce, which is called a notification center. And objects tell the notification center when something, when their state changes, or when a certain event occurs. And other objects tell the notification center that they want to know about when other objects change their state.

So in the end, we have this dynamic neural network. And we have a very simple system of objects communicating with each other without directly having references to them. This is one of those other great best practices of OO programming that the WebObjects frameworks incorporate. Foundation framework also provides basic infrastructure for validating the data in your objects. And WebObjects 5.2 includes XML serialization classes that make it very easy to serialize WebObjects and enterprise objects.

So the WebObjects framework. Well, this is a framework that bootstraps all types of WebObjects applications. So whether you're building an HTML, a swing, or a web service WebObjects application, this framework helps you get up and running. And it manages something called the request response loop. Clients send requests into your application server. The WebObjects framework helps you dissect that request, and in the end, after all your business logic and application logic have made the decisions they need to make, it helps package up a response and sends it back out to the client.

We talked about the page templates, and the infrastructure for that is rooted in the WebObjects framework. And the most important thing the WebObjects framework does is it manages state. We all know that the web is inherently stateless. There are no facilities for tracking state on the web. So that's really what one of the main roles of an app server is, to provide state. And there are three realms of state. There's global application state, data that you want all of your users in every session in your application to share.

There is per session, or per user state. So if you want to provide a customized, personalized experience to each user as they enter your site, you need to store the state for that session. And even within a given page, you may need to keep track of a session if a user requests that page again. So the WebObjects framework manages state in those three realms.

So we introduced the Enterprise Objects Frameworks before. So if you're having a hard time understanding of what this actually is, there are two industry standard terms that will give you a sense of what it accomplishes. One is entity relational modeling, the other is object relational mapping. And these are ways of thinking of your data in higher level terms than tables and columns and joins, thinking about them more abstractly as an objects.

And like we said, this takes care of writing all of that low level code that you as a human shouldn't ever have to write. So the framework takes care of it. It's much more reliable than you writing four joins to traverse a complex relationship. And it allows you to focus on business objects, like we said. So one thing you have to trust about using EOF, that's what we call it, is that Java invocations you make, so invocations you make on your objects, actually result in the end in certain database operations, such as selects, inserts, and updates.

So once you learn to trust that, you're going to get a lot further as a WebObjects developer. So there are two really important terms in EOF. We talked about business objects. Well, your business objects are actually instances of something we call an enterprise object. And these enterprise objects live in an editing context.

An editing context is a container. And I bring these up now because when you start actually writing code in an application, these are two of the types of objects you'll be interacting with most often. So this is a really important set of frameworks. So we have two slides on it.

There we go. So it also includes a high-level qualifier language. So when you need to write a description and tell EOF what kind of data you want to fetch, well, we allow you to do this in Java with a very English-like syntax. Rather than have to worry about the joins that you need to write, and all of the appropriate SQL, you write in very high-level qualifier objects that then get transposed down to the database layer.

We manage joins for you, like I said, and EOF introduces the idea of keypath. So a very quick example, if we have an address object referred to by the address key, and we have a street property in that object, we can get to that data simply by using this chain of keys.

And this is all enabled by key value coding, like we discussed before. And EOF provides automatic transparent access to multiple data sources. So if you want your business objects to be composed of data from an Oracle database and a front-based database, they can do this, and you don't really have to think about it.

And EOF includes a validation infrastructure that allows you to provide validation on properties, so on the data in your objects, and you might want to validate that data at certain points in the application's execution. If a user requests to save data, you want to make sure you want to validate the data before it actually gets to the database, and EOF provides this infrastructure. And like I said, there's also very rich support for inheritance in enterprise objects.

So we talked about frameworks, so where does your code, how does your code work with the frameworks? Well, if the enterprise objects framework is on the database side, and the web objects framework is on the client side, your business logic plugs in to EOF, and your application logic plugs into the web objects framework.

And in a running application, clients send requests in, they come in through the web server, which forwards it to the application server, the WebObjects framework takes over and helps you make sense of that client request. And in conjunction with your application logic and your business logic, perhaps that user requested data, and if so, UF will help you get that data out of a database, and put that data, get that data in the form of objects, which you can then, you pass back through your application, you use that, those objects to populate these page templates that you write, and then the WebObjects framework ultimately packages that back up in a response that gets sent out to the client.

We talked about rapid development and we're running a little short. So, behind the scenes. So this is one of the examples that ships with the WebObjects product. It's called iShax. It allows -- it's a front end to the real estate database that you saw in -- no, you didn't. It's a front end to a database we ship as one of the examples, which is a real estate database. So how does this page happen? What's going on behind the scenes to actually produce this page? Well, the first layer is HTML.

There's -- this page is made of HTML. Well, where does this HTML come from? Well, it comes from one of these WoE components. And this component happens to be the search page component. And this component includes a bunch of dynamic elements. The values, the content of these dynamic elements is resolved at runtime.

So, what components? We touched on briefly before. They're page templates. They're made up of standard HTML, JavaScript, and other web content, but most importantly, they're made up of these dynamic elements. More components are reusable and nestable, so you can reuse a component within your application. It's very common to have a common page wrapper component that all of the pages, all of the components in your application use.

You only have to write that component once, and you can put it in all of your templates, so you get the same -- that same feel without writing more code. Components are synchronized, and they communicate with one another. Each component has a Java object behind it, and that's really key.

So this isn't just -- a component is not just a set of HTML with a little bit of JavaScript or, you know, maybe even SQL in it, like other kinds of component models, but there's actually a Java object behind each component. So this allows you to store state and allows you to communicate with other Java objects, such as your business objects. And what components have full access to session and application data, so if you need to provide a customized, personalized experience on a particular page, you have access to a user session.

So these dynamic element things, like we said, they're HTML tags. Their characteristics and values are determined at runtime. Let's look at an example. So in that iShax example page that we showed you a few slides ago, there's a pop-up menu. And the pop-up menu allows you to narrow down the scope of your search. And it allows you to choose a state. So each dynamic element has a number of different attributes. And you bind these attributes to values in your business objects, static values maybe, whatever.

So in this case, we're calling out the value attribute. And the value attribute is bound to a key path. We talked about key paths before. So in this case, it's looking for an object that's resolved by the name key. And it's looking for the abbreviation of that state, such as CA for California. So at runtime, that list, that 50 state list, element list, will not include the full name of the state, but rather the abbreviation.

Okay, so we talked about development. We're almost done here. But once you're done developing your application, you actually need to deploy it. And if you attended the WebObjects State of the Union, we introduced new ways of deploying your applications in Panther Server with JBoss. And there are two sessions dedicated specifically to this, so please go see them. But I want to cover two very quick things today. There are two types of deployment. There's a standard WebObjects deployment using our tools and deployment infrastructure. And there's servlet deployment, which allows you to deploy your WebObjects application as a servlet in Tomcat, in JBoss, WebLogic, etc.

Okay, so in sum, with WebObjects, you write less code, you get a lot of functionality out of the box for free, the objects you write are usually reusable, The Enterprise Objects Framework allows you to build database-independent applications. So you might start developing your application on one database and move to another production database when you're finished, when you deploy. We have a lot of innovative, very cool technologies, like the rapid development tools and frameworks for doing rule-based development.

And we provide a number of flexible deployment options. So how do you get started? There are thousands and thousands of pages of documentation on WebObjects. We suggest getting started with these four first. Web applications will take you through building an HTML application. It includes a number of tutorials.

And the ideas that you learn in there are really applicable to all kinds of WebObjects applications. So if you're developing a web service application, you should still start with that book to familiarize yourself with the concepts. And using EOModeler not only teaches you how to use EOModeler, but it also introduces a lot of the important concepts in the Enterprise Objects Framework.

And if you want to learn more about the dynamic elements that we provide for you, you can go to the EOModeler website. There's the dynamic elements reference. And if you're unfamiliar with Project Builder, or even if you are familiar with it, there are a few things that are unique to WebObjects development that a lot of people are confused about at the beginning. So go consult that specialized Project Builder for WebObjects developers document to clear it all up. Who to contact? We always love to hear your feedback, your ideas for the product. So, [email protected] is probably the best way to get a hold of us.