So, I'm pleased to announce that here we're going to unveil Apple. I know there's been a lot of interest in Apple's JavaBean Strategy. I'm here to unveil our new JavaBean Strategy. Tied closely to our QuickTime Distribution Strategy. Here it is. This is the Enterprise scale JavaBeans here. Those of you. So hopefully that will satisfy a lot of you. For those of you who won't, I am pleased to announce Rory Lydon, the Tools Manager, often known just as the Tool Guy. And he's here to tell you about the other kind of JavaBeans.

Thanks, thanks. Good afternoon. Thanks for coming, everybody. It's a little dangerous to tackle such a soporific subject matter in that witching hour between lunch and coffee, but we'll see if we can keep each other awake. As Ernie said, I'm Rory Lydon, and the subtitle of this session is "Making the Best of a Bad Thing." All right, so obviously this session has two topics, WebObjects and EJB. I'm going to cover a little bit of each. It's certainly not going to be exhaustive of either topic, but if there's anything I don't cover that's a curiosity to you, please ask a question at the end.

All right? So, first thing we're going to do is kind of talk a little bit about what EJB is. How many of you here--I saw some people have used EJB. How many of you think you know what it is?

Then we'll talk about the differences between WebObjects and EJB, kind of the competition or tension between the two. And then we'll talk about WebObjects and EJB, how they can and will work together. And then we'll do Q&A. Okay, so what is EJB? First and foremost, it's over 300 pages.

Here's the specification. This is my copy. If you want to understand it, there's really nothing for it. You've got to read this thing. It's a very interesting document. We'll come back to that later. EJB is part of J2EE. This is very interesting. It's packaged separately and it's not a prerequisite to be a J2EE vendor to support EJB, but the two are actually very closely bound. And you can't in fact ship the interfaces for EJB without shipping the J2EE package as well. So it's a little, they're very closely bound. It's a very impressive marketing achievement.

I mean, anybody who deals with IS or IT managers knows that, for a long time, as application servers and web-based applications came to the fore, they were freaking out because there were absolutely no standards. And they never knew -- they barely knew the nomenclature; they didn't know how to compare different products.

So for them, this was a godsend, right, because they heard from Java Soft, "This is the way things are going to be." And suddenly they realized, "Oh, well, as long as vendor A and vendor B both implement Java beans -- enterprise Java beans, I can just stack them next to each other, run a test suite, and whichever one is faster will buy and use," right? So -- and at this point, the truth be told, it's impossible to be competitive in the application server market without supporting EJB, for better or worse.

So it is a very impressive marketing achievement. And it's also the death of EOF, according to a wide variety of people. We even had people in our hallways running around saying that there was no need for EOF anymore. We're just going to do everything with EJB. We'll come back to that later. All right.

Now, specifics. Several times today, I'm going to quote from the specification. There is some very interesting material in it, and it is ultimately the definition of the product. It's an unusually turgid piece of technical writing. It has phrases in it like, "The EJB is the best." Yeah. Yeah. container provider container provider for short And my personal favorite, the EJB server must also provide a container for the Enterprise Beans which is called an EJB container.

Slightly less humorous note, the Enterprise JavaBeans architecture will be the standard component architecture for building distributed object-oriented business applications in the Java programming language. That's the fundamental goal of Javasoft for EJB. In terms of what is EJB, the Enterprise JavaBeans architecture is an architecture for component-based distributed computing. Okay, so that's the core definition here.

We'll take a look at that. First of all, what does it mean to be component-based? This is very interesting to me. There's been a big surge in the media and in the industry about component-based development. But when you try and find out what component-based development really is, it's pretty hard to get a concrete definition.

So what is a component? People say it's more than an object. Now, I personally find this very interesting because to me the whole genius of the object-oriented programming paradigm is that it's all-encompassing. All the things that we see around us in the world and even a surprising number of the thoughts that we have in our heads are easily renderable as objects, right? So, I'm not sure why anyone would need to come outside that paradigm, but they're composable, as the name would suggest.

and they're portable. Alright, so if you'll indulge me, I'd like to back up a little bit and if components are more than an object, I'd like to take a quick look at what an object is, alright? Most of you probably are already familiar with the concept, but an object consists of data, fundamentally, and a wrapper of code around that data, which is that data's interface to the outside world. Some objects have just a little data. Some objects are almost nothing but data. They just have this candy veneer of logic. But objects always have data. They always have data. Even if the data is just other objects.

What does it mean to be more than an object then? Well, what they're really talking about here is it's an object, but it's got an interface outside it, okay, which essentially constitutes a contract between the object and the rest of the world. Essentially what is often referred to as the object's habitat or environment, okay? So there are two parties to this contract: the object, which implements its half of the interface, and the habitat, which supports the object and provides the infrastructure it needs to get its business done.

When they say that it's composable, they just mean that given this contract, you can take objects from a variety of different sources and they can communicate with the habitat, leverage the habitat support. They can communicate with each other in terms of that support. And in an ideal world, in the most sophisticated systems, they can communicate with each other purely in terms of their own logic and the environment is essentially transparent.

When they say that components are portable, well, what they really mean is that because of this contract, as long as the objects support this contract, you can essentially rip out the habitat and replace it with another habitat, excuse me, with another habitat, and the objects will be perfectly happy. They won't even know that the rug has been pulled out from underneath them. So that's what they're really talking about. So they say that a component is more than an object. It's composable, it's portable. To me, a component is just a well-designed object that works.

So that's the component-based part. So what about distributed? Well, or actually, sorry, before we go into that, what does this notion of component-based technology mean in terms of EJB? Well, there's a contract for every EJB called Enterprise Bean. This is a basic interface in the technology that all EJBs implement. The counterpart in that contract is something called a container. It's providing services to the object that allow it to do whatever it needs to do.

Some of these services, well actually all of these services: JNDI, this is the Java naming and directory interface. It's essentially a distributed naming scheme and lookup technology. JDBC, Java Database Connectivity. A single class in a larger interface called the Java Transaction API. I don't know in terms of these mnemonics which is funnier using two words for database or using the A in API as part of an acronym.

The only part that you have to support is user transaction. You're also supposed to support Java mail, but whatever. Okay, so these are the big three for EJB. Now it's interesting because the relationship between the container and the contained object is unidirectional. The container messages the contained object, but the contained object has absolutely no access to its container. So it has really a kind of implicit relationship with these services. It acquires them indirectly.

These services actually inhabit a larger outside object, which is the server. In EJB you have the concept of a container and then a server which contains the container. Turns out the server is actually remarkably similar to a J2EE server. J2EE also supports these other technologies like Java server pages, Java messaging system, and again our friend JavaMail. But JNDI, JDBC, and the user transaction component of JTA are the only components of this system that are really required for EJB.

Okay, now a container can also obviously contain more than one object, and a server can operate more than one container. This is actually important because this is how you achieve scaling and distribution with EJB. Okay, so let's see. Let's take a close look at distributed. Well, again, if you'll indulge me, I'd like to delve into the definition of distribution a little bit, especially as it pertains to objects. You have some process.

That process lives on a network and there's a boundary between the process and its client. In traditional client-server world, one side is called the server, the other is called the client, but in a truly distributed system, that definition disappears. You really have a democratic topology where there isn't really a subordinate process, there are really just two processes communicating. One process invokes something in another. In the simplest world, in a procedural world, this is an RPC, something we're all pretty familiar with.

In a slightly more sophisticated world, such as CORBA, one is actually invoking a method on an object contained in the remote process. And of course in a highly sophisticated system, you're just talking about object-to-object communication. Now, the big problem with this, of course, is that objects tend to be chatty. And the amount of overhead associated with communicating back and forth over the network can really bring a system to its knees. This is a very, very interesting problem.

One solution to this problem is essentially to introduce a proxy on the remote side of the network such that objects manipulating that proxy have the opinion that the object is local. And you have some distribution system which manages synchronizing the proxy with the original. I don't know how many of you were here for the Direct-to-Java client session this morning, but that's what our distribution technology is all about.

And indeed, this balance of the remote object and the local object is kind of one of the key skills in the modern development world. Especially moving forward, it's all going to be about deciding how much of the logic you put on what side of the network. Typically, on the server side, you have larger objects than you do on the client. But the client-side object can have a lot of unique logic to it that isn't even present on the server side.

is to have some kind of stub object which represents the remote object but doesn't really allows you to execute any of the objects logic locally or access any of its data

Okay, so going back to the definition of EJB, again you have your Enterprise Bean. It's in a container.

The convention in EJB for distribution is to have a remote stub called an EJBObject. which communicates back to the Enterprise Bean on the server side. Every time you want to invoke any business logic on the object or access any of its data, you do a round trip on the network.

and incur all the overhead associated with that. Now one might think, well, what if I managed to have an Enterprise JavaBean in a container that's local? So even though the object has this distribution paradigm, it's actually in the same process and in the same VM as me. Won't that make things faster? Well, in fact, according to the specification, every method call to an entity object, that's a form of EJB, via the remote and home interface, the only way to get at an EJB, is potentially a remote call. Even if the calling and called entity bean are collated in the same JVM, the call must go through the container, which must create copies of all the parameters that are passed through the interface by value.

The container is also required to check security and apply the declarative transaction attribute on the intercomponent calls. The overhead of an intercomponent call will likely be prohibitive for object interactions that are too fine-grained. So obviously this is a very coarsely grained, heavyweight technology. Even when two EJBs are in the same process, there's an inordinate amount of overhead for them to communicate. Hardly the most hospitable habitat. Okay, so that's the distributed portion.

Just a word here. Like I said, I'm not going to go into too much detail. And that's not because it isn't interesting or because I'm attempting to avoid it. It's just I'm trying to keep this as simple as possible. There are two flavors of EJB: a session bean and an entity bean.

The fundamental difference really is that an entity bean is very similar to what we call an EO or an Enterprise Object in that it has a primary key and it really represents A business object, a single business object within your system. A session bean is much more of a process. It's more akin to a WebObjects direct action.

Typically you'll find that a session bean, in order to implement its functionality, will manipulate a whole slew of what would be entity beans. The basic idea is that if you're going to be interacting heavily with an object, you don't want to use an entity bean, you want to use a session bean in order to avoid the overhead problem.

Okay, so now I'd like to talk just a little bit about persistence because persistence is essential to EJB. I mean, the bottom line is that objects are at least 50% data. Well, I mean, the ratio may vary, but you can't have an object without data. And chances are, most meaningful data is going to have to be stored somewhere. So persistence is very, very important. There are two flavors, again, of persistence in EJB: bean-managed persistence and container-managed persistence. So let's talk a little bit about being a managed persistence.

Again, going back to this contract between Container and Enterprise JavaBean, There's a bunch of APIs associated with entity beans for managing persistence. Essentially, the container invokes these methods and the EJB, the entity bean, is expected to react to them and behave appropriately. So, when the container sends an EJB or an entity bean specifically a create message, it's expected to initialize its data as appropriate on the basis of the arguments, Communicate with JDBC.

Introduce the data associated with itself into either a table or tables in the database. The entity bean itself, in the case of BeanManagedPersistence, is responsible for performing all those operations. It's interesting when one considers this is a method. If you implement this method in your code, and the only interface you have at your disposal is JDBC, you're going to wind up writing essentially SQL code in your entity bean. So what happens when you change the schema? Let's say you do something as simple as change a column name, let alone change a database vendor. You're going to have to recompile a bean. Same thing for EJB_LOAD.

In this case, there's a couple of really weird semantics in EJB. In this case, you're going to have to write a code that's going to be in the database. In this case, even though the entity bean hasn't been initialized, in other words, it doesn't have its identity yet, it doesn't have its primary key yet, the only interface between the container and the logic that you've implemented is the bean.

So it kind of initializes an entity bean and then tells itself to load itself. So the entity bean at this point doesn't have its data. It's expected again to go through JDBC, go out to the database, get its data, populate itself appropriately. Same cycle. same responsibilities for the entity.

Again, when the container tells the bean to store itself, it's responsible for figuring out what portions of its data have changed. Communicate those changes to JDBC so that JDBC can update columns or rows in the database. Now, very interesting thing to do if you download the reference implementation of EJB from Sun, just take one of the entity beans, change it so that the only thing you do in any of these methods is, you know, println to standard out, you'll see that the slew of invocations of EJB load and EJB store that transpire in even the simplest operation.

So, if this process of loading oneself from the database, let alone storing oneself on the basis of only that data that has changed, isn't very carefully managed, performance just degradates phenomenally. And really, EJB does not provide any assistance in this process for entity beans with bean-managed persistence. The final two cases are EJB Remove.

The bean is supposed to figure out how to destroy any references to itself in store. Do that and then just kind of go away. And finally, EJB.find, which I'm not even going to get into. Again, this is one of those things where the container asks an instance of an entity bean class to go out and find a bunch of other instances of that class for itself. It's a little weird.

The bottom line, though, is that this EJB specification, and the use of the word "this" is actually kind of interesting here, this EJB specification does not define the architecture for data access objects or strategies. This means that EJB... EJB persistence is limited to JDBC. The only tool that an entity bean has at its disposal to implement all of that logic that we just saw is pure row oriented JDBC, essentially SQL.

In the case of container managed persistence, the theory here is that the container will manage all that hard work for the entity bean. I mean, who really would want to deal with all that and just leave it to the container? So, well, it still invokes all these methods on the entity bean. The entity bean is just... is a container that is supposed to do anything when it gets these messages. But the container is what manages the relationship between the bean and the database. It invokes JDBC. It performs all these operations for the entity bean.

According to the spec, the disadvantage of container-managed persistence is that sophisticated tools must be used at deployment time to map the entity bean's fields to a data source. It's kind of strange that sophisticated tools are such a disadvantage, but What they're really saying here is that these tools and containers are typically specific to each data source. Well, typically I suppose they are.

Furthermore, if the Bean provider, this is the person who writes the entity Bean, Sun defines all these roles which typically coalesce into one or two people. If the Bean provider expects that the container managed fields will be mapped to database fields, he should provide mapping instructions to the deployer for realization by the data access classes generated by the container provider's tools.

Because entity beans are typically coarse-grained objects, the content of the container-managed fields may be stored in multiple rows, possibly spread across multiple database tables. These mapping techniques are beyond the scope of the EJB specification. and do not need to be supported by an EJB compliant container. I thought the container was going to handle all this hassle for me, but I guess it turns out that it isn't going to.

And indeed, because a compliant EJB container is not required to provide any support for mapping the container-managed fields to a database schema, a bean provider of entity beans that need a particular mapping to an underlying database schema instead should use bean-managed persistence. So, they just threw the ball right back in the beans court.

An entity bean designer who runs into the limitations of container managed persistence should use bean managed persistence instead. I guess I'll be using bean managed persistence. Okay, so that's a brief overview of what EJB is. Very brief. Now I'd like to talk a little bit about WebObjects versus EJB.

WebObjects has a contract too. We call these things objects, not components, but same basic principle. Our contract is called EnterpriseObject. The two parties of the contract are your business class and something we call an editing context. The editing context is essentially our container. The relationship and communication between the editing context and the Enterprise object is bidirectional.

The editing context, I mean, there's just no notion of Enterprise Object Managed Persistence. The whole idea is that the editing context takes care of all that hassle for you. So it communicates with the database driver. and manages conveying data from the data store to the Enterprise Object and back again. It also manages the relationships between objects, manages rendering them in terms of the database schema, and it also tracks changes. So it always knows what components of the Enterprise Object have been modified. So it's able to optimize this communication.

You'll see in WebObjects 5 for Java that JDBC is the driver. So this is very analogous in that respect to the container. It's worth pointing out here, actually, I'm simplifying things, but actually it isn't the editing context that communicates with the database. The editing context communicates with something called an object store. The editing context is itself a kind of object store, but object store is our general paradigm for persistence.

The fundamental assumption of an enterprise object is that it does have data, and believe it or not, that data will persist. The whole architecture of WebObjects is designed from the ground up to support this notion. The editing context communicates with the object store. The object store communicates with JDBC, and JDBC communicates with the database.

WebObjects distribution. I don't know how many of you were here this morning, but the basic idea here is that you have an editing context containing an Enterprise object on one side of the network. You have an object on the other side of the network that wants to communicate with it.

Again, we want to avoid this overhead of the conversation between the two objects. So what we do is we introduce an editing context on the client side. Okay? Now the reason that we can do this, well, there are two fundamental reasons that we can do this. First of all, from the ground up, again, we have this understanding that objects have data that changes and will persist. So from the ground up, we know that we're going to be editing objects and we're going to want to push those changes to an object store. Okay? So what happens here is that the object store is just on the other side of the network.

All right? But all the optimization is performed locally so that the amount of communication back and forth when rendering those changes back to the server and perhaps or perhaps not to the database, that amount of communication is kept to an absolute minimum. So there's an editing context on the client side. There are editing contexts in the direct to Java client applications that you saw. We have an object on the server side.

and a proxy or another rendition of the object. It's actually another edition of the object on the client side. And as far as the client editing context is concerned, the editing context on the server or more concretely, the distributed object store which connects it to that editing context, is just another object store. So the editing context behaves just as it would as if this was a single unified process.

Keep network overhead to a minimum. Okay, and again, you've got this fundamental need to balance the client and the server. How much logic do you put -- how much logic do you leave on the server? How much do you transmit down to the client? Again, with WebObjects, you have complete control over that.

As you should have -- if you saw, you would have seen this morning, you can specify what class you want to use on the client side. That class can have less data. It can be a much smaller object. It can have a whole lot of client-side specific logic.

But you have complete control over that distribution. And that control over that distribution is essential to creating scalable applications, scalable distributed applications. Okay, so that's a gloss on WebObjects versus EJB. Now I'd like to talk very briefly about what our plans are for WebObjects and EJB. Our first goal, our first and foremost goal is to create a container.

That way, if someone hands you an Enterprise JavaBean, you'll be able to install it in your WebObjects application and act as an EJB server. So, to clients of that EJB, you'll be indistinguishable from any other EJB server.

is making it possible to define one's business objects in terms of our paradigm, in terms of our contract between enterprise object and editing context. and then expose that object, that Enterprise object, as an EJB. So the container will think it's manipulating an Enterprise JavaBean, but in fact this Enterprise JavaBean will be implemented in terms of WebObjects and our contract, so it will have all the power and simplicity of our contract, but appear to the outside world as an EJB.

This is where things get much more interesting because, for example, if one has implemented a lot of custom logic in classes that are Enterprise objects, with the flick of a switch, you'll be able to expose them to the outside world as Enterprise JavaBeans. This is very important in shops where there are several WebObject zealots and a bunch of people down the hall in accounting who are using some EJB server and wonder why these guys are doing something different. To the outside world, it'll all look like EJB.

Okay, and then beyond that, well, when you look at this closely though, because of the tight link between an Enterprise Object and an editing context, you can't really make an Enterprise Object seem like an Enterprise JavaBean without embedding and editing context and enough of WebObjects logic and WebObjects contract inside the bean.

Well, once you've done this though, there's really no need for a WebObjects application to act as a server. This is one of the huge benefits that we're going to see from going to pure Java. This is all pure Java, right? So it doesn't really matter where it's running.

So we'll be able to essentially take our container, Rip it out, throw this Enterprise JavaBean into someone else's container, any other vendor's container, and have it execute just as if it was something they had developed or something that was running in a WebObjects application. So this represents a very interesting opportunity for our technology because this interface's contract between the Enterprise JavaBean and the container will be something of a Trojan horse. You're suddenly going to find our technologies running in foreign platforms in ways that they never could have previously.

So that's a very interesting possibility. There's some obvious technical complications, but we've already gone a long way towards resolving these in implementing direct-to-Java client. The client side is not a traditional WebObjects application. It's a Java application or Java applet. So we've resolved some of the technical mechanics. There are also obviously licensing issues and marketing issues, but this is something that has great potential. Okay, so our goals are to provide a container, a very basic container.

Expose Enterprise Objects as Entity Beans. Now I'm emphasizing entity beans because They map pretty well to Enterprise objects. For example, if you have an entity in modeler, chances are that that will map pretty well to an entity bean. One has to be very careful. Because of the distribution model in EJB, you're going to find that you're incurring a lot of overhead whenever you invoke methods.

So it's not quite like it is for an Enterprise object. So even though with the check of a radio box you're going to be able to render an entity as an entity bean, you're probably going to want to go in subsequently and tune it with the understanding that you don't necessarily want to expose a lot of logic that comes natural in a single process or our distribution model. But it's a great way to get off the ground.

And finally, we want to generate exportable WebObjects EJBs. So, be able to create a system with logic in WebObjects using our tools, our patented object relational mapping, all the goodies that Editing Context takes care of for you, and then export that into some other vendor. If a company has a deployment requirement that they use some other vendor's technology, no problem. We'll be able to take our beans, put them in there, and deploy. Alright, that's really about all I had planned, so now I'd like to turn it over to Q&A.