WWDC2000 Session 407

Transcript

Kind: captions Language: en so I'm please announces here we're going to unveil I know there's a lot of interest in Apple's javabeans strategy I'm here to unveil our new javabeans strategy tied closely to our quick time distribution strategy here it is this is the enterprise scale javabeans here those of you so so hopefully I'll satisfy a lot of you for those of you won't I am pleased to announce our 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 thanks for coming everybody it's a little little dangerous to tackle such soporific subject matter in that witching hour between lunch and coffee but we'll see if we can keep each other awake on as Ernie said I'm Roy Lydon and the subtitle of this session is making the best of a bad thing all right so obviously this session has two topics web objects 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 the secure easá to you please ask a question appearance 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 DJB how many of you think you know what it is see well that's an improvement over the last crowding spoke to so so we'll talk about that then we'll talk about the differences between web objects and ujb kind of the competition or tension between the two and then we'll talk about web objects 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 got to read this thing it's a very interesting document we'll come back to that later a JB 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 you JB 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 we 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 javabeans enterprise javabeans I can just stack and next to each other run a test suite in which everyone is faster will buy news 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 very impressive marketing achievement and it's also the death of Els according to a wide variety of people we even had people in our hallways running around saying that there was no need for UF 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 container provider container provider for shorts 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 java software EJB in terms of what is vjb 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 component based development but when you try and find out what components base 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 meet a 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 rental role as objects right so I'm not sure why anyone we need to come outside that paradigm but there 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 all right 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 is interfaced to the outside world some objects have just a little data some objects are almost melting but data they have this candy veneer of logic but objects always have data they always have do even if the data is just other objects okay so 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 objects habitat or environment okay so there are two parties 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 habitats 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 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 an object is a component it's just a well-designed object it works so that's that's the component based part so what about distributed well or actually sorry before we go into that what is this notion of component based technology mean in terms of EJB well there's a contract for every JB called Enterprise Beam this is a basic interface in the technology that all EJB is 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 an API as part of an acronym but 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 uni-directional 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 okay and so you have an EJB you have the concept of the container and then a server which contains the container turns out the server is actually remarkably similar to a j2ee server all right j2ee also supports these other technologies like Java server pages Java messaging system and again our friend Java mail but the jndi JDBC and the user transaction component of JTA are the only components of this system that are really required for ujb 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 zjb looks excusing okay so let's see let's take a closer 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 a 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 they're 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 and it's slightly more sophisticated world such as korva 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 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 all right typically on a client site on the server side you have larger objects and 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 or it could have again mostly data and just the thinnest veneer of logic but you want to have that flexibility in terms of distribution the alternative is to have some kind of stub object which represents the remote object but doesn't really allow you to execute any of the the objects logic locally or access any of its data without going across the network now and you know to me this isn't really object distribution because every time you want to invoke a method on the object you still have to go across the network and you still incur that overhead so this is a very very crude form of distribution okay so going back to the definition of EJB again you have your enterprise beam it's in a container the convention in EJB for distribution is to have a remote stub called an EJB object which communicates back to the enterprise being 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 okay 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 specification every method call to an entity object that's a form of EJB via the remote in-home interface the only way to get at any JB is potentially a remote call even if the calling and called entity beam 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 inter component calls the overhead of an inter component call will likely be prohibitive for object interactions that are too fine-grained so obviously this is a very coarsely grained heavyweight technology right 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 ok so that's that's the distributed portion just a word here like I said I'm going to I'm not going to go into too much detail and that's not because it is an 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 meaning the fundamental difference really is that an entity bean is very similar what we call a neo 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 right a session bean is much more of a process it's more akin to a web objects direct action typically you'll find that a session being in order to implement its functionality will manipulate a whole slew of what would be entity beans but 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 it's an object or at least 50% did 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 being managed persistence and container managed persistence so let's talk a little bit about being managed persistence again going back to this this contract between container and enterprise javabean there's a bunch of API associated with entity beans for managing persistence essentially the container evokes these methods and the EJB the entity being is expected to react to them and behave appropriately so when the container sends an EJB or an entity being specifically a create message it's expected to initialize its data as appropriate on the basis of the arguments communicate with JDBC and introduce the data associated with itself into either a table or tables in the database so the entity being itself in the case of B managed persistence is responsible for performing all those operations now 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 beam 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 beam okay same thing for EJB load in this case there's this really weird couple really weird semantics in EJB in this case even though the entity beam has been initialized it hasn't been initialized in other words it doesn't have it yet it doesn't have its primary key yet the only interface between the container and the logic that you've implemented is the beam so it kind of initializes an entity beam and then tells itself to load itself okay so the entity beam 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 okay same cycle same responsibilities for the entity game again when the container tells the beam to store itself it's responsible for figuring out what portions of its data have changed communicate those changes today to BC 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 print lin to standard out you'll see that the slew of invocations of EJB load and EJB store that transpire and evil even the simplest operation okay 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 desegregate phenomenally all right and really EJB does not provide any assistance in this process for entity beans with being managed persistence okay the final the final two cases are eg be remove the 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 it should be find which I'm not even going to get into again this is a 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 it's a little weird okay the bottom line though the bottom line 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 okay this means that EJB EJB persistence is limited to JDBC the only tool that in any being has at its disposal to implement all of that logic that we just saw is pure row oriented JDBC essentially SQL okay in the case of container managed persistence the theory here is that the container will manage all that hard work for the entity being I mean who really would want to deal with all that only just leave it to a container so well it still invokes all these methods on the entity being the entity Venus it's just it isn't supposed to do anything when it gets these messages but the container is what manages the relationship between the beam and the database it invokes JDBC it performs all these operations for the anti-tb according to the spec the disadvantage of container range persistence is that sophisticated tools must be used at deployment time to map the entity beans 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 beam provider this is the person who writes the entity beam son defines all these roles which typically coalesce into one or two people if the beam 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 providers tools okay because entity beans are typically coarse-grained objects the contents of the container manage 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 well 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 the compliant hav container is not required to provide any support for mapping the container managed fields to a database schema a beam provider of entity beams that need a particular mapping to an underlying database schema instead should use being managed persistence so they just threw the ball right back in the beans court an entity beam designer who runs into the limitations of container managed persistence should use beam managed persistence instead I guess I'll be using be 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 web objects versus egv web objects is a contract - we call these things objects not components but same basic principle our contract is called enterprise object all right 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 bi-directional and editing context can contain many enterprise objects and a web objects application contains many editing contexts so you can see there's a certain similarity here web object persistence is a little different the editing context I mean there's just no notion of enterprise object managed persistence okay the whole idea is that the editing context takes care of all that hassle for you okay so it communicates with the database driver and manages conveying data from the datastore 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 objects have been modified alright so it's able to optimize this communication you see in web objects 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 mean I'm simplifying things but actually it isn't it is in the editing context that communicates with 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 okay the fundamental assumption of an enterprise object is that it does have data and believe it or not that data will persist right so the the whole architecture of web objects is designed from the ground up to support this notion so the editing context communicates with the object store the object store communicates with JDBC and JDBC communicates with the database okay well logics 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 dis 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 Java client applications if you saw we have an object on the server side and a proxy or another rendition of the object it's actually another addition 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 okay it's just another object store so the editing context behaves just as it would as if this if this was a single unified process keep-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 web logics 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 that control over that distribution is essential to creating scalable applications scalable distributed applications okay so that's a gloss on web object versus EJB now I'd like to talk very briefly about what our plans are for web objects and EJB our first goal our first and foremost goal is to create a container whoops excuse me is to create a container so that third-party vendors can drop their ejbs into a lab object application now in order to really support enterprise javabeans you have to implement a container you can't really fake the semantics so we're going to have a full-blown container inside metal objects application that way if someone hands you an enterprise javabean you'll be able to install it in your web of biologics application and act as an EJB server okay so two clients of that EJB you'll be indistinguishable from any other ejv server that's a good start but there's obviously little or no integration between the way we do things and EJB in that case so the next thing that we want to do is make 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 web objects 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 our 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 web object 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 air prize object and in editing context you can't really make an enterprise object seemed like an enterprise javabean without embedding an editing context and enough of web objects logic and web objects contract inside the bean well once you've done this though there's really no need for a web objects 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 vendors container and have it execute just as if it was something they had developed or something that was running in a well objects application so this represents a very interesting opportunity for our technology because this interface is contract between the enterprise javabean in the container will be something of a Trojan horse we're suddenly going to find our technologies running in foreign platforms in ways that they never could have previously so that's 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 directed Java client the client side is not a traditional web logixx 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 ok so our goals are to provide a container very basic container expose enterprise objects as entity beams now I'm emphasizing entity beans because they map pretty well to enterprise objects for example if you have an entity and model or chances are that that will map pretty well to an entity being one has to be very careful because 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 beam you're probably going to want to go in subsequently in 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 in the EJB distribution model but you know it's a great way to get off the ground and finally we want to generate exportable web objects ejbs so be able to create a system with logic in web objects using our tools our patented object relational mapping all the goodies that editing context takes care for you and then export that into some other vendor if if a company has a deployment requirement that they use some other vendors technology no problem you'll be able to take our beans put them in there and deploy all right that's that's really about all I had planned so now I'd like to turn it over to QA [Applause]