My name is Daryl Lee and I'm the WebObjects Engineering Manager. And I'm just curious, because this is a huge crowd, how many of you have actually used WebObjects before? Wow. I'm impressed. You guys have really showed up today. That's great. And who has used Web 2.0 or is currently-- who is using Web 2.0 or building Web 2.0-like applications or even knows what Web 2.0 is? OK, so there's a few of you guys out there. So what I'd like to do is actually split today's session into a couple parts.

First part, we'll do a lot of fun stuff, talk about Web 2.0, what's in Web 2.0, how you can use WebObjects to build Web 2.0 applications. And then we'll take the second half to talk about more current things, what's going on in the Leopard time frame, what was just released this last week, and what you can expect in the future.

So I've got a couple things just to keep you in your seats here. And I want to show you a teaser demo. Hopefully it's all good. We had a little problem with the demo machine getting it all set up here. But I want to tease you with a demo.

And then if you guys are really nice, and maybe some people will have a little surprise at the end. And maybe you guys might have some fun with that too. So can we pop to the demo machine really quickly? The D machine? Okay, so this is a little summer intern project. Oops.

Oops. There we go. Okay, reload. So this is a little intern project, or summer intern here, Chuck, wrote this summer. I just thought I'd give you a quick taste of it and give you a quick tour. It's a real fun photo browsing app. You can see it's really interactive.

There's this really nice thumbnail bar and all kinds of features in here. By the end of this session, you'll get an idea of how to use WebObjects to build an app like this or some techniques. And we'll dig a little bit deeper in a little while. So this will hopefully keep your butts in the seats and interested in listening to me. Okay, back to slides.

Okay, so what I want to get into is actually talk about the definition of Web 2.0 and the Zen of Web 2.0. When I looked and searched on Google, I looked at Wikipedia, what is in Web 2.0? There really wasn't a definitive spec. W3C hasn't really pushed anything specifically what this, what's in Web 2.0.

And so what I did find was a lot of interesting quotes, and I thought I'd share them with So ZDNet had a bunch of fun articles and one of them said Web 2.0 is an attitude, not a technology. So I'm not sure what to do with it, but you have to be in the right frame of mind to build a Web 2.0 application.

Web 2.0 is about giving up control and setting your data free, so it's quite metaphysical, you know? And this next one kind of connected a little bit more with me when data interface and metadata no longer go hand in hand. Okay, so they're not buddies anymore, but it sounded like a more model view controller kind of data pattern that you guys might be more familiar with.

So, okay, so that's something that's in the Web 2.0 space. I saw another thing about the Web 2.0 conference last year, and they did this big brainstorming session, and they threw all these terminologies, these concepts, technologies on the board. They said, "This is what's in Web 2.0." And I found this image on the net of this guy who actually etched a PowerBook, and they put all that terminology on the PowerBook. And so there is Web 2.0 right there in front of you. So I'd love to have the PowerBook, but I don't know if I bind everything that's on that book.

So instead of just going into all that terminology, let's talk about what are some benchmark Web 2.0 applications, or what are people actually trying to build nowadays. And a couple of years ago, Google Maps really started this craze. It was about searching for data that you're interested in and displaying it in new interactive ways. In this case, it was putting it on a map. And you could interact with the map. You could drag the map around.

And you could search for pizza plate joints and find all the pizza joints within five miles and have it displayed on the map. And people thought that was really cool. And you didn't need a full page refresh. So this really started off this craze of more interactive browsing.

So another thing that people are doing lately is mashing up data. And what I mean by that is taking data from different data sources and presenting them in new ways and custom ways. And what you're seeing right behind me is a virtual shopping tour of the Notting Hill district. And what makes this unique is that if you look right in the center, there is a Google Map embedded in there with some custom views and waypoints in there.

So they're getting their mapping service from Google. Then they're pulling-- if you look in the right corner, they're pulling weather data and some sights and sounds of the actual shopping district. And that's coming from a different service. And then they're combining that with their custom image data, which I think you're seeing there with the Duke of Wellington and other stuff. So it's the combining of all different types of data sources into new and interesting applications and ways of presenting data.

So how many people are familiar with Flickr? Or any kind of thing like Wikipedia, YouTube? These things are just the craze right now, which is a real collaborative experience. The users and the internet community in general are defining things and sharing their content. In Flickr, what you can do is upload a photo. You can have people comment on it. They can rate it. You can tag it with different keywords. I can say, here's my image of an iPod. It's from Apple, and it's really cool. So this is a new craze that a lot of these sites are jumping onto.

Now, people are taking this whole Web 2.0 and building application, desktop applications into the browsers to a new level now. And this interactivity, and they're building typical desktop applications into the browser. So, Rightly has actually built a Word replacement in the browser. And I think recently Google bought Rightly. But what's interesting about this is that people can collaborate distributively.

And what I mean by that is you can have someone working on the same document that's in Tokyo, in New York, in Paris at the same time. They can merge the changes and make the revisions, and everybody gets updated. And so there's a lot of stuff going on in the server to keep everybody synced up. So, we think that's really cool. But people have even been going farther, and they're getting this brushed metal, really embedding full-featured apps like Outlook Express. And Zimbra did this pretty well.

And they got a lot of buzz last year in the Web 2.0 conference, and they won a lot of awards for this. And so, as you can see, they've embedded what really looks like a full-featured mail client. There's calendaring in there. There are RSS readers in there. And they also do a lot of extra things to scrape data from your emails and such to add more context to it. So, like, if you had a UPS package and you had a tracking number, they could actually add more context to it. So. That's like the gold standard right now. Zimbra is getting a lot of buzz.

And finally, I want to just share with you a real fun one that I found out about the other day, which was this Flyakite OS X. And what someone actually did was use JavaScript to make a Finder-like experience within the web browser. It's a little strange here, but as you can see, there are stickies available. It has a hierarchical browsing of a pseudo file system there. They have an iTunes-like app in there and system preferences, et cetera. So people are taking this whole interactivity level to a new level. So I thought I'd share that with you.

So what I want to do is just boil down some of the concepts out there that we saw in that PowerBook to some things that I think are interesting. And I bet you a lot of you guys have heard of AJAX. I mean, who hasn't heard of the buzzword AJAX? Asynchronous Java and XML. People are really using this kind of development pattern to fetch small chunks of data or UI bits and dynamically change their UI on the fly.

So traditional Web 1.0 apps, you had to do a full page refresh to write new data into your web page. But what people are doing now is pulling in small chunks and then manipulating the DOM tree to actually insert this data into the UI. Other things that people are doing a lot, and I'm sure you've heard of a lot, is syndication and leveraging things like Atom and RSS to publish and subscribe to data.

People are also trying to find new ways to make their data public. So a number of years ago, WSDL and that type of web service was supposed to free up people's data and actually allow people to share data more freely. But actually what it's done is it's been so complex that a lot of people haven't jumped in. And so people are looking for simpler ways to access data, provide interfaces, whether it be JavaScript or Flex or any number of lower or simpler SOAP objects.

And as I mentioned earlier, Flickr and Wikipedia and other stuff are doing tagging and collaborative and matching up data in different new ways. And finally, I just wanted to mention microformats is becoming pretty popular. And what that is actually doing is embedding structured data within your Web page. Yahoo recently said they're going to support microformats. And so that'll be an interesting way to present your data and pass data to the clients.

So, what technology do I need to learn or do I have to have in my toolbox to actually build a Web 2.0 app? Now, if you look right behind me, there is nothing new there. There is absolutely nothing new. XML Soap, been around for the last 10 or 12 years. JavaScript, 10 or 12 years. I think it's only being used in new ways.

And I think about six years ago, XML HTTP request object was kind of introduced, I think, in IE. And that is being leveraged in the AJAX style of architecture. And then JSON, JavaScript Object Notation, is also something people are leveraging more, which is a way to optimize passing data from the server to the client.

Adam Spex, they're quite straightforward and pretty simple to learn. Those aren't that new either. It's been around at least four years or more, five years. CSS, DHTML, that's not new. And REST, ideas of REST services, which are just a new way to interface into data, those aren't new either.

So what I thought I'd start doing is just show you guys a few building blocks and how to build and start off with Syndication and show you how to build a really reusable RSS feed and an Atom feed and just give you ideas on how to break those down into components and use WoE XML nodes as your base components to build a feed. So can we move over to the demo machine? This one right here. I need to switch it? Yeah. Okay. So let me fire this up really quickly.

So we like Eclipse at Apple, and we like Xcode, but I thought I'd demo in both worlds. So you're going to get a mixture of both IDEs here. And all right. It's taking a minute or two to come up. So other things when you're thinking about building a syndicated feed is to leverage direct actions. Syndicated feeds do not need to have state associated with it. It does not need to have a session associated necessarily with it. So let me just fire up my app really quick and give you guys a preview.

Alright, so I've got a basic feed, lots of cool stuff here. There is one data source and here's another data source. So what I've, I'll get into the details a little bit more, but it's really easy to build any type of data source or feed components that can be mapped to a different data source.

So I've mapped one data source to this Atom feed and my initial RSS feed, and then I've actually created a different data source for this alternative data feed. And it's all dynamic. So let's just add something, Project Wonder. 3.0 came out today. Let me just put a link in here really quick.

That's really cool. I submit that. As you can see, in my RSS feed, it's updated dynamically. And here in my Atom feed, it updated dynamically. So I just wanted to show how easy it is to actually put something together like this. If you look at the left gutter here, I broke down the spec into their base components, each entity component, and used WillXML nodes to represent that. And you can actually dynamically, codelessly bind these components up to your display group or your data source. So I think that just gives you a flavor of how to build a feed.

Here's my two RSS feeds, and basically I just bound those same components to different data sources. So hopefully that gives you a quick idea. I'm not going to give a complete hands-on demo on how that works, but you can definitely come and ask me at one of the sessions or the labs or the feedback forum for more information about this. So back to the keynote slides.

So one thing I mentioned earlier was about open APIs and actually sharing APIs or data or client libraries amongst the community and then allowing them to leverage that and map new types of data or information on top of that. And so what I wanted to do is experiment and show you guys how to make a reusable component that wraps all this, an API of a Web 2.0 type of library and then allow you to share or give you an idea of how to make that component codeless so people can just bind to various options in that component and not have to recompile and not have to write any code or have any inherent knowledge.

So what I did was actually take the Yahoo Maps API and I combined it with some of our WebObjects componentness and repurposed that and pushed that to the client. So this is just a quick diagram of what is going on. Let me just jump in really quickly to the demo and show you how that kind of might work.

So let me start it. I call this my Will Map container. And what you're going to see here is a real basic map. There's not anything that interesting, except maybe there's a navigation window in the corner there. But I want to really customize this and make it more interesting and put some data on there and have some fun with it. So let's go drop in and let me just show you the component really quickly.

So I created this WoW Map Container component, and I dropped it in here to my main component. So there's my WOMAP container. And then there are a whole bunch of bindings available here. Is it draggable? What's the height? Let's change zoom levels, latitude and longitude for where it's centered and stuff. And so what I can do is actually modify these bindings on the fly. So what I'd like to do is add some interesting waypoints.

And a great thing about WebObjects is actually that we have a rapid turnaround mode. And so if you don't actually change any of the Java source code, you can modify your components and then just do a page refresh, which I'm going to do right now. And boom, you're seeing my changes updated really quickly. Now we're drawing a bunch of custom waypoints up here.

And the zoom level's changed. And I'm waiting for some of the other stuff to show up here. There we go. I mapped it to a feed that shows the state parks within the California. And here are some traffic feeds here, too. So there's an accident on Marsh Road, in case any of you guys are driving down that way.

Okay, so that's just a flavor. What's great about this is, as you notice, I just changed bindings right here, and we always encourage reusable components. And this component can be shareable with your colleagues, and they won't have to know, okay, what's the JavaScript API call to actually turn on these options within Yahoo Maps? What do I have to do? What do I have to learn? How much docs do I have to read? All I have to do is actually look at your bindings here. And they'll have an easy access, or it's really pretty obvious what those things do.

So like I said, there's no innate need to know the internals if you wrap some of these Web 2.0 APIs correctly. Okay, so the next thing I wanted to do was actually do a little bit more server-side crunching. And I thought about, okay, well, let's combine some of the syndication aspects of the Web 2.0 API or specification, and let's go scrape a bunch of RSS feeds and data mine it for data or information. And then let's dynamically pull that back and forth, update that on our WebObjects server, and put that data into a database. And while we're scraping that data, geocode that information, so add some geocoding context to it.

And then on the client, present in a new way using Yahoo Maps again, because that's pretty interesting, and put a new kind of customized look and feel of the app and the interactivity of the app. So if I can jump to the demo machine really quickly, and we can talk about this.

So I call my app the Woe Rentals Application. And Woe Rentals Housing. So what you're going to see is I've customized my map even more. And what happened there was the WebObjects server had scraped a bunch of Craigslist feeds. And it data-mined the rental information for it, for rental housing. And then we geocoded it. And then we displayed the data in a custom way.

In this case, we found all the image data. And we added a little bit more context to the waypoints and such. And as you can see, now I have a really quick and dirty kind of rentals application where you can get an idea, give a geographic context to all this scraped information from the feed. Other things you can do is talk back to the server and let's just... Look for only places in San Francisco and we can go over here, we can zoom in a little bit more and take a look.

We're pulling from Yahoo Maps, so it might be a little bit slower here over our network here. Anyways, so every time I change this search, we're actually going back and forth with WebObjects server using XMLHB requests to fetch small chunks of data and display those small waypoints there.

Hopefully that gives you an idea of how you might want to integrate with other APIs, how WebObjects might be in the back end. I'm only giving you a flavor. I don't think this is not a hands-on session, so I'm not going to dig into all the details, but it's pretty straightforward to build something like this. So can we switch back to the keynote slides? So what I created was a kind of a server-side aggregator.

I used EOF a bunch to actually save my data that has been geocoded and then actually query on it. And I used direct actions quite heavily because it was the simplest way to implement this. You don't need a lot of sessionful, kind of stateful information to be contained in here. So hopefully you get an idea of how to build an app like this. So.

Our summer intern this year, he was given the project of, of course, using WebObjects. He had to make something really cool and interactive, so we wanted a nice Web 2.0 app that showed off some of the best of what people are doing out there. And so it needed to be really interactive, a lot of user input, and a real snappy interface. And of course, since our fearless leader always talks about having insanely great apps, we thought it should be insanely cool. So if we can switch to the demo machine really quick. Okay, so the demo machine to the left here.

So I'll just log into our app really quick. I really didn't give you guys that much of a tour earlier of this app. Let me show you some things that you might not have seen, which is if I scroll quick enough, this scroll bar is actually lazy loading all these thumbnails. And we're using a lot of XMLHPU requests to fetch small chunks or batch chunks of data over to the client.

Other things that are really fun with this app is that it's got a nice little zoom mode so I can actually look at the pixel level almost at the Eiffel Tower and see what people are looking at. If I pop out of that, Let's go, another fun feature is a fine feature we have here. If I type tree, it's slowly narrowing down my search query. So it's actually doing a query back and forth to the server to update the information that it needs to display here for this thumbnail bar, or image bar.

Another fun thing we did was actually add keywords to all our data. So let me just do an info on...

Oh, whoops, OK. I had something. OK, there we go. I want you to change some ratings here. So as you can see, this is a big round trip.

And we're broadcasting notifications any time the data updates from our WebObjects server that's talking with direct actions back and forth to our data source. Okay, so we thought that was fun, but we want even more interactivity. So we thought that chatting would be fun. So let me say hi to Chuck here.

And so what we're also doing is just doing a lot of round-tripping to our WebObjects server for this chat. Distributely, and as you can see, we're not doing page refreshes. Only that window is updating in small chunks. Okay, so let me just resize here. Oops. There we go.

So anyways, it's a very fun, interactive app. And what I want to show you really quickly, if we can go back to slides, is that...

So if you go to the lab or something like that, I'm sure Chuck will be happy to show it to you. He's very enthusiastic.

Yeah, maybe. So I'll just reiterate what I was talking about before. Each one of these UI components is actually working independently, and it's doing its own chatting back and forth to the WebObjects server independently and fetching in chunks of data, updating, and notifying various other parts of the client that need updating that That's just an idea of how to make a dynamic app and maybe a flavor of what you probably want to do in a Web 2.0 world.

Okay, so that was our quick overview of WebObjects and Web 2.0, but we also have a lot of other ground to cover, which is actually what's coming up in WebObjects. So, I'd like to talk about transitions. And, yeah. We as Apple are, you know, we're looking, I'm sure you guys have seen certain notices, I think we'll address that a little bit later, but we're also looking for new ways to actually, I think, in the next year or two, to work a little bit more closer with you as a community into extending WebObjects and bolting on functionality to WebObjects. And we're also trying to bring WebObjects more to the center of the Java world, and we have some initiatives to do that.

So, what's new in WebObjects? So, earlier this week, Xcode 2.4 came out, and we can talk about that. For Leopard, we have quite a bit of deployment changes, so the way you might deploy an app with an Apache 1.3 server on 10 server has changed. And, you know, some of that is due to Apache 2 becoming the default web server on our platform. We're actually planning to open up a lot of specifications to you guys. And I'll talk about that in a minute. We're bringing an ant build system. So, I don't know if you guys are going to be happy about that.

And there are also some support changes we'll talk about. So Xcode 2.4. So to achieve the most backwards compatibility with our runtime libraries, we use a JDK 1.5 compiler, but we made all of our projects compile with the source 1.4, target 1.4 flag. So we think that as far as backwards compatibility, this is the best way to protect you guys.

and in the future. We made a lot of Xcode compatibility fixes to make sure that IDE and all the apps are talking correctly and working correctly. And then there is a security fix in there. One thing our security team actually asked us to do was turn OpenBase off by default. So release the release notes about that. So I don't know if you should clap for that.

So as far as Leopard goes, we're making large deployment changes. I'd really encourage you guys to go to the WebObjects deployment session tomorrow. There's going to be a lot of good content in there. I'll just go through a little high-level overview. We're bringing non-blocking I/O, so a lot of the well-worker threads that you're used to working with or are used to in that environment are not going to be necessary. So look, we're using a standard Java stack, the non-blocking I/O stack, for processing our request response loops. So tomorrow we'll have more information on that.

We're also providing a new monitoring solution. So we're actually trying to move to JMX, which is a more standard Java-like way of monitoring and managing your applications. So a lot of people have already asked me, OK, so how do I actually monitor these apps? If you look at the next bullet, Java Monitor is not going to be what we're going to be encouraging people to use. Well, JConsole is part of the default distribution in the JVM.

There are also a huge number of open source projects that allow you to do JMX monitoring and management. So you can find out more about that tomorrow. And then Apache 2 is going to be supported. And we're going to have a new way. There's not going to be a mod WebObjects module anymore. And we're going to use the standard Apache mod proxy balancer. So definitely get some more information on that tomorrow.

So another initiative that we have is actually opening up as much of our specifications as possible and giving you guys some tool sets to extend WebObjects, build new apps or technologies or tools on top of it. So our first step today was actually posting the WoE component bundle specification and the EO model specification. Those are in draft form. They're available at the URL above for this session. We'll make them public later. Thank you.

The other thing, in order to support some of those specifications, is we're planning to release the WoE Component Parsing Code. And that will be just available to everybody in developer examples to play with. It will hopefully enable you guys to consume WoE Components easier and do interesting things with them.

Since this Eclipse project entity modeler is actually already parsing EO model components or bundles, we're actually encouraging people to look at that because I think they do a pretty good job as far as showing how to parse EO model components or bundles. Another request we've had for quite a number of years is, can you guys give us the Java U UtilSource? And I don't know how many of you use that, but it's a real convenient utility for exporting and importing data from databases.

And it's a little switchblade knife of doing a lot of different kinds of things. So we thought we'd throw that out there. We had a number of requests for that. And we think that that will help people that want to bolt on functionality to their apps to do more stuff with that.

And of course, I mentioned Java Monitor. So we're providing the source on disk with the developer tools. And we've heard a lot of requests over the years that you want the source so that you can customize Monitor or WOTASD for your deployment environment or specific needs. So we're giving you that stack to play with and do what you want with. We're also encouraging you to check out our new stack and new way of deploying on 10th server. So there's a lot. options available to you guys.

So as I mentioned, the build system, we're really interested in leveraging Ant and using a more Java-like build system. Many of you weren't so enthusiastic about the Jam build system, and so we're making that move this year. And we're trying to make the build system compatible with other IDEs, so we'll try to support as best as possible the integration aspects.

So if you want to use Eclipse or NetBeans, et cetera, to build your WebObjects apps, we're trying to provide that integration. And of course, that means that the old build system is deprecated, but we're not going to remove it from disk, so there'll be a long transition period where you guys don't have to migrate your apps right away, but we're really encouraging you to.

So a lot of this openness and what we're trying to do is actually prop up you guys. And we're really trying to help these projects especially, because we think they're doing a really great job. I don't know how many of you use WoeLips or WoeProject, but it's really cool.

Rule Modeler, people think it's a great replacement for Rule Editor, and we'd like to encourage the further development of that. And then there's a recent application or plug-in to Will Lips called Entity Modeler, and we think it's a really full-featured modeling plug-in. So we'll talk about that in a minute.

And then Project Wonder, of course, has just been a great support to the community. And a lot of Apple engineers have contributed to that in the past, and we're encouraging you guys to look at that, too. So what I'd like to do right now is actually bring Mike Schrag up here. He did the Entity Modeler. So I'm going to see if we can take the picture here because I don't know what better way for the mailing list to see that it's not actually dead.

Demo machine number two. Yeah, thank you. So what's that? No problem. All right. So what is Entity Modeler? I'm going to equip the Eclipse that they're running and run the 24 hours ago build of Eclipse. So we get the... Latest and greatest. For people that have been around for the past, oh, say, 10 years, you may be familiar with EOModeler.

And you may be familiar with the fact that EOModeler may not have actually changed much in those 10 years. And it carries around several bugs that may not have really changed much in 10 years. So at the Will Lips Project, Will Lips Project Enterprises, we basically were looking at what were our options going forward because we'd like to provide better support because obviously things like EOModeler app being deprecated and things moving towards the Xcode plugin and, of course, demo guides being what they are. That's a whole new one. That's not even our fault. Talk to the eclipse people on that one.

Of course, yes. All right. We'll take two there. So what we basically wanted to do was provide some mechanism to support EO model editing inside of Eclipse. And they're just going to make me jump through hoops here, aren't they? Take three. The other nice thing at WoLips, we don't have to care about things like release cycles and code quality necessarily as much as Apple might.

We just fixed this and put out the fix later today for that. Oh, nice rendering bugs there. All right, so for anyone who has not seen Eclipse, this is what Eclipse looks like when you open it up in the traditional Java perspective. And the way that Eclipse is configured is the concept of perspectives and views, where perspectives are sort of collections of related views of your project.

And so one of the new perspectives that's in here, if you notice this icon up here, is the entity modeler perspective. So I have a project here called Secret Santa, which is actually an app that my family uses to manage Secret Santa. And so you see in the Java package perspective, or Java package explorer view, the Secret Santa EO model here that has the entities inside of it.

We actually are parsing these things so we can actually tell you that this is actually an entity and this is an EO model. If I were to actually open this, if you used Eclipse before, you would see that this is actually an entity. So if you know the open EO model, there's now an open entity modeler. And so, yes, I always wanted to. This is entity modeler. This may look somewhat familiar for people who have used EO modeler in the past. In fact, the icons may look very familiar to you.

and in fact, if you were TMD5 some, the icons would look really familiar. So, what we really wanted to do was provide a full replacement for EOModeler. I started out saying, all right, well, I'll just kind of do the things that I use because I really wanted an EOModeler replacement. But very quickly, I started getting emails from people from all over saying, well, what about stored procedures? You don't support stored procedures. And what about fetchbacks with stored procedures? You don't support those.

So, before long, it basically was the full EOModeler replacement. So, the organization of this is slightly different. Inside of Eclipse, or inside of EOModeler and Xcode, you have the concept of inspector panels. It's not really a very common idiom inside of Eclipse. Inside of Eclipse, we have these sort of property panels and these other views. So, this is actually a properties view, just like properties view inside of the other perspectives, but with some custom contributed inspector views, essentially.

And so, when I select an EOModel, I see my adapter configuration and I can get user info and I select an entity, I get all of the things you would expect. So, some of the things that I'll assume that you pretty much know how EOModeler basically works. So, I won't go over the little stuff, but I'll show you some of the things that we do a little bit differently. One of the big ones is prototype support.

If you've used prototype support inside of EOModeler, you know that it has some issues. In particular, my most hated one, I call the brown column of death. Inside of EOModeler, if you change your prototype, you lose your column name in EOModeler. You don't lose your column name in entity modeler. It stays.

One of the other things, if you happen to use Project Wonder, for instance, we support the prototype naming scheme and resolution for those that appears inside of ER model, or sorry, Project Wonder. For instance, ER prototypes and your ER front-based JDBC prototypes, we find those and actually hook those up properly.

If you notice my, actually let me select one of the, you notice this ID is of type integer because I'm on front-based right now. If I were to go into my adapter and change this over to Oracle. and TabOut. I come back and you notice that changed to number. We dynamically resolve prototypes in the fly.

What we do is basically, that's much faster than I thought it would be. On the fly, we take all of the JAR files that comprise your project and all their dependencies. We find all the EO models in that, and we find all of the WebObjects JAR files you point to, and all the plugins that you point to, more importantly.

We actually SQL generate using the exact same plugins that you get at runtime. This SQL generation here matches exactly your SQL generation at runtime, which is not necessarily true in old EO Modeler. You get kind of a weird Java 1.1 JDBC old SQL generation. That's a particularly nice feature. In addition, there's some ways you can hook into this process and actually tweak. You can catch delegate events before we generate SQL.

You can mess with the model in memory to do custom things. After we generate SQL, you can grab it and actually literally inject your own SQL into this flow on a per-project basis. You can literally drop a Java file in your project that implements a particular interface that we hook into on the fly. That is SQL generation. One of the other big ones is Java source code generation. In EO Modeler, they have their own custom method of generating Java.

We actually use EO Generator. For anyone who has not looked at EO Generator, I highly recommend it. That's rubicode.com. It's basically a much, much more advanced templating system for generating Java files based on EO Models. In this case, one of the paradigms in Eclipse is sort of incremental on-the-fly building. We sort of support that same concept, which you can turn on and off if you don't like it.

In EO Modeler, you can actually build a project on your project, this billing workspace, and it actually figures out which EO Generator configurations are associated with this model and auto-builds everything all the way down on all your dependent projects that might depend on this. For instance, if I go and add a new attribute here, I can see that I have a new attribute here. So, tell it this is a Boolean, call it new attribute, column name. I always forget which ones are editable, which ones aren't.

And when I save now, which didn't save my column because I was in it. So one of the things we hook into the new Jface data bindings in Eclipse, which is a brand new specification that's not actually public in Eclipse yet, and so it has some issues. So when I save, it now auto-EO generates, and if I actually go and look at the code, this on the fly generated code and changed the methods which now are a compiler because I have things that are, you know, my EO generator file specifies sort of pseudo-constructors.

So it's showing me that I had a new not null field that now has to be added to this so that the Java file is totally on the fly, Eclipse is refreshed automatically, and so everything is just sort of kept in sync. So and of course I closed my model.

So the big takeaway here is this is open source. It's available now in beta form. We've had several people with fairly complicated models actually hitting this thing. Thanks, Alan. And so it seems to be fairly robust at this point. I actually use it on my own models. So I do eat my own dog food also, except I used it two weeks ago when it destroyed things. So I encourage you to give it a try. If you haven't tried Eclipse, give that a try. Contribute to the source. Objectstyle.org slash woelips is the wiki page that has all the information you need to get it.

And get on the mailing list, submit requests for features. We are perfectly happy to add new features in. Some of the things we have planned, index support. One of the big missing things in NeoModeler is you can't define an index other than your primary key. Entity Modeler in the relatively near-term future will add support for defining arbitrary indexes for multiple columns on all your entities. Some of the other things are hooking into the refactoring system in Eclipse. You notice I have these class names here.

When I change a class name in Eclipse, it would be very nice to actually contribute to the refactoring and automatically update my model so it reflects those changes as well. And hook into EOGenerator to be able to update my underscore versions of those. So some of those things we have planned also. And any other ideas, things that you're sick of NeoModeler doing or not doing, let us know and we'll be happy to do it.

So one of the last things I just wanted to point out is Apple has been really cool about supporting this. We've gotten direct support from WoW developers and the release of those specifications, which they're really nice to give us sort of pre-releases of to see, oh, hey, there are keys in NeoModeler files that are 10 years old that aren't used anymore that we need to support.

So Apple's been great. And I think all of these recent announcements are really exciting. So again, WoW is not dead. Thank you. Thanks, Mike. So what I'd like to do-- that's great stuff. We're really happy about what Mike's been doing. And we encourage you guys to check out the projects. What I'd like to do is actually invite Max Muller up to talk about Project Wonder.

As Daryl mentioned, my name is Max Muller. I am the manager of the content engineering group within the Music Store. And it is amazing how fast time flies. So in 2001, I announced on behalf of NetStructure that we were open sourcing two of our base frameworks, ER Extensions and ER Direct Web. So six months later, Project Wonder was born on SourceForge to host those two frameworks. And here we are five years later with over 30 frameworks.

And with the help of Mike and Andrew, who have just done amazing, amazing jobs on enhancing, there's now close to 900 commits just since January. So they've done an amazing job bringing all sorts of things from SAP integration, IAM integration, Apache 2.2 work, and most recently, essentially, the rule modeler and the AJAX support. So for those of you who are interested in AJAX, the AJAX frameworks have all of kind of the basics.

So we have the base integration with WebObjects in there. So JS proxies, essentially the draggable actions, and just provides a really great framework for building your AJAX work on. And it comes with a very cool demo. So I highly, highly suggest that those of you who are interested in the AJAX work essentially check it out. Likewise, Andrew recently announced on the mailing list, and it's official today, that essentially the 3.0 version of Project Wonder is now out. And yes. No.

Andrew and co. So that basically-- I won't go through all the enhancements that it adds, but it adds stuff like JDBC connection pooling, cursor support. It adds some of the AJAX stuff and a number of other slew of enhancements. So go and check out the latest release there. There's a lot of stuff that is very relevant.

So for those of you who are new to WebObjects, Project Wonder also essentially has a lot of great example code and was written by people who really understand the technology well. Now I'm not just saying that because I'm a committer, and there's a lot of my code out there, but where I'm also a user. So within the Music Store, we're all essentially WebObjects, Project Wonder. So if you browse the Music Store and languages other than English, and UK English does count, then you're going through essentially all the localization extensions within the Wonder framework.

If you received a receipt email from the Music Store, and I hope all of you have and received many of them, then you basically were going through an ERC mail message. So we've basically leveraged it heavily within the Music Store development, and it's obviously very robust and fully featured from our perspective. Likewise, about 20% of our developers are actually committers within Wonder, and regularly essentially contribute back bug fixes and enhancements to the actual Wonder frameworks.

Likewise, we also work very closely with Beryl's group for essentially looking at some of the new stuff within the NIO, looking at essentially the deployment, some of the enhancements we can do around the deployment, as well as contributing back bug fixes. So within the next release, you'll be getting a lot of essentially the stuff that we basically found and enhanced within the base product.

And earlier this year, thanks to a lot of the help from the Woe Lips group, we now have the Music Store completely building in AMP, and our developers are split about 50/50 in IntelliJ and Eclipse, and just actually in the past year, we've been basically playing around with Entity Modeler and loading up a number of models from essentially the Music Store.

And we basically take advantage of all the tricks, the inheritance, both vertical, horizontal, prototyping, all the kind of bells and whistles, cross-model relationships. And it's actually been working out rather well for us. So we hope to essentially have been moved over on that front. And with that, I will turn it back over to Daryl. DARYL FOX: Thanks.

Hello, my name is Francois Jouaux. I manage the Java and WebObjects engineering teams at Apple. I've been with WebObjects since 1995. Actually, yeah, 1995, the original WebObjects engineering team. And since that, there's hardly a day when I don't have a new idea on how to use WebObjects or -- and there is not yet a technology that has stumbled WebObjects, prevented WebObjects prevented us to use WebObjects to take advantage of it. Well, they always call me for the hard part. Let's get to it. What the future holds. So let's talk about JDKs, the Java Bridge, Iokoko Client and Java Client, and the WebObjects tools.

I thought I would quote Carl Gretton, and we stumbled on this quote yesterday on the mailing list, and it's a perfect summary of what we're going to be dealing with today. The Objective-C Java bridge is old. It has served its purpose. It was built on the original JDK from Sun and it suffers many flaws. It's time to move on.

JDK support. So as you've heard, we are moving to JDK 1.5 since the OS is already on Java 2.0 SE5. This means that in Leopard, the baseline will be 1.5. And we will be supporting Java 1.5 for WebObjects. One of the reasons is that the necessary JMX specifications that we want to, the dependencies we want to introduce are in 1.5 JMX specifications. And as soon as Java SE 6 is available, we will also support it.

Cocoa Java. What does that mean for the different versions of Xcode? In Xcode, in the Xcode 2.x family, you have today all these possibilities for Java bridge and Cocoa Java development. Project creation, building existing projects, adding new bridge classes and so on, and running Cocoa Java applications. In Xcode 3.0, product creation will be gone and you will not be able to create new Java bridge applications from scratch.

You will be able to build existing projects but not bridge new classes. Take Cocoa classes, bridge them into Java. I don't think many people have ever been doing this because it's a complicated process. But this is gone. So in Leopard, your bridge application will still be running. You should not create new ones.

The alternatives to Cocoa Java. The advice, again, is to not create new bridge classes today in Nextcode 2.4. Use JNI to access native code from Java. This is a sure and trusted way to do it. That's what we are doing when we are implementing Java on top of Mac OS X.

Use Cocoa for your GUI applications or Swing if you want to stick with Java, but do not mix and match. The Cocoa APIs exposed in Java have been stalled for at least two releases. You don't have access to the latest goodies there, and you should take advantage of them.

Objective-C, not 0.2, but 2.0 is available. And it has many Java-like language features, garbage collection properties, new for loops. And I encourage you to look at this language as well. And it adds hooks for script bridging. If you ever wanted to implement your own data bridge, have fun. Go for it. We tried.

IOCoco Java. So IOCoco Java was introduced in the early 2000s and was meant to provide a Cocoa frontend for WebObjects server. The story, since it is partly built on the bridge, the story is similar here. In Xcode 3.0, you will not be able to create new Iokoko Java applications, but you will be able to build existing projects. And the runtime will stay available on Leopard. I don't know how many Iokoko Java applications are out there. One. Okay. Shipping. Well, it's shipping. It will keep shipping. And it will keep working.

This brings us to WebObjects Cocoa Java Tools. Actually, did I have-- maybe missing something here. WebObjects Cocoa Java Tools. So many of our developer tools, unfortunately, were built on top of the Java bridge. This led to a lot of pain and trouble for my team. As Cocoa was moving forward, as Xcode was moving forward, we've had to go through really convoluted paths to keep the tools working. Today, I am announcing that the following tools are deprecated. EOModeler, WebObjects Builder, Rule Editor, Roa Launcher, and the Web Services Assistant.

Some slides are messed up by Javaclient compatibility. This is similar to Iokoko Java. Since it is built on the bridge, we need to deprecate product creation, but your applications will keep running. Alternatives to EO-Cocoa Java on Java Client. Do not write new projects using deprecated frameworks, client frameworks, which are JavaEO-Cocoa, JavaEO application, distribution, generation, and the interface frameworks, either for Cocoa or Swing.

Use Cocoa and Core Data on the client, or use Swing and the EO-Java frameworks. Use pure web services to communicate with the WebObjects server. This should bring you in line much more with what the industry is doing. These were really proprietary communication mechanisms, and they were very hard to move forward. So let's get back to the WebObjects tools that are duplicated.

The EA Modeler and its plugins should be replaced by Entity Modeler. You've seen the demo of Entity Modeler. There are very few things missing. I could think of maybe two. The diagram view. It's good to show to your boss, but I have never really seen the usability of the diagram view. You're going to do it anyway, so.

and reverse engineering, and that I know is coming. That is very important. WebObjects Builder is replaced by WoeLips. Most of the hardcore developers that were building components were using WoeLips anyway, or a pure text-based editor for the Woe components. WoeLips have syntax coloring and a lot of goodies that it gets for free from Eclipse for editing components. Rule Editor is superseded by Rule Modeler. Web Services Assistant should also be replaced by Role Modeler. And our Launcher is just dropping off.

So in summary, this is all about getting more engaged with the community. We are moving forward with the WebObjects runtime. Our skills are mostly at the runtime level to try to improve the pipeline between the web server and the application server and give you all the building blocks to build the best components and the best models as well as foundation classes that are closer to the Java-based foundation classes. We would like to help open and community--help the creation of open community-led tools.

We want to expose our formats, no more proprietary formats, and provide more example code for the pieces that people still rely on but that we have decided to move further from, beyond. We will ensure compatibility between runtime on these open tools we have talked or demoed today. And the good news for Xcode is that end support is going to be the main way for both Java and WebObjects development, the main build system, and that should allow your team members to pick and choose between any of the different ideas that support end. As a summary, well, Daryl, this is your show. Summarize. Thank you.

What we talked about today, we talked about how to use WebObjects to build Web 2.0 applications, and we think it's a great platform and great foundation to build cool Web 2.0 applications. We also talked about just helping you guys build cool apps and allowing you to extend the WebObjects-based technology and do interesting things with it. And we think, looking at this turnout today, that there's a lot of interest in doing this, and there's a lot of energy in the community.

and of course we have a lot of great Leopard improvements and I would encourage you to look or go to the deployment session tomorrow. There's a lot of good stuff to learn about and find out what's coming. So thank you for coming. One more thing I have is I think we have a little bit of Q&A time. So if anybody has a good question and doesn't flail us or anything like that, I've got some t-shirts up here in front that I'll throw out to you guys.