WWDC2001 Session 609

Transcript

Kind: captions Language: en thank you Tony thank you good morning welcome to session six zero nine developing desktop applications with web objects I'm Ron Luce Aang and I'm an engineer with the web objects group so everyone that we've told come to session 6:09 and you'll find out about desktop applications with EOF now you're finally here this is what you came for so to start things off I want to emphasize that web objects offers incredibly powerful database connectivity for desktop applications it's not just about web applications we also we also offer incredibly powerful desktop application connectivity to databases to that there are two architectures that web object supports two-tier architectures with AOF with cocoa AOF where your cocoa client talks directly to your database we also offer three-tier applications we're using Java client or direct to Java client your swing based application speaks to a web objects application server which in turn speaks to your database so what you'll learn today I'll go over the architecture of cocoa EOF and some of the functionality that it provides and then I'll ask Andres renderer to come out and talk about Java client and its architecture so first cocoa EOF this is kind of the overview of what layer's cocoa EOF has of course there's cocoa and EOF as the name implies cocoa if you haven't heard apples incredible technology it's a set of object-oriented advanced api's for building Mac OS 10 native applications and then of course there's a o F our enterprise objects framework and here I've set out two special parts of EOF first being the JDBC adapter the JDBC adapter is what actually connects to all of our databases it and so any database for which we have the appropriate JDBC version 2 driver we can talk to that database using AOF the other layer there is yo interface cocoa which actually bridges the two worlds of AOF and cocoa so in a little more detail first Coco Coco and EOF cocoa and AOF work together the cocoa part provides all the application logic so everything that you get that you're used to with a regular cocoa application you get in cocoa EOF this includes all of the cool widgets that you're used to well the views the windows the menus the matrices everything that you all the widgets that you're used to and then of course the responder chain that you're used to for receiving events the run loop for getting events from the user interface and we even support custom views it's everything that you expect from cocoa as a cocoa application now how does data get from cocoa and into EOF and back and forth well a general idea of the date of the data flow is let's say you've got an application that displays some values in a table so if you edit the value in the table cocoa will fire an event off to a class an object in yo interface cocoa this object has already set itself as the delegate for any edits in the user interface so it gets the event it realizes something has changed I'll tell yo F about it and the value is then set in the business object in EOF where you can save it or something happens in your business logic and maybe something changes because of that one change from the UI well e Oh F then says something's changed and yo interface cocoa gets that event from a Oh F and then pushes the value back into the user interface setting the display value in cocoa in your UI so that's pretty simple pretty simple setup right you've got cocoa you've got yo f and you've got yo interface cocoa the bridges the two worlds now speaking of bridges we do still use the Java bridge if you're new to cocoa development or new to web objects the bridge is a cool technology developed by Apple for allowing your Java code to access Objective C classes so in the Objective C world of cocoa where cocoa is really implemented in Objective C there is a wrapper of Java API so you can actually use NS window NS application and it's found all the NS foundation and app kit utilities classes in Java so while cocoa is available in Java and implemented in Objective C EO F now is all Java the web objects 5eo F is implemented in all Java which is different from previous versions where there was also a bridge for e.l.f but now that we're pure Java all of your custom business logic must also be written in Java this works out well for you anyway since once you've written your business logic in Java you can use that business logic in any other web objects application HTML based applications cocoa applications or Java client applications the same business logic can move between the three architectures and as I said your custom business logic has to be written in Java but your application logic everything that takes care of the cocoa interaction with the human interface that can be written in Java or Objective C you still have a choice there now actually so if you have worked with cocoa or web objects in the past you may think oh no not the bridge the bridge has been kind of a source of headaches in the past we don't believe it's much of an issue anymore there's two main reasons for this the first being it's been rewritten for Mac os10 it uses it takes advantage of Java 2 on Mac OS 10 it's much better and the second most important thing is we hardly cross the bridge again since we don't have to use the bridge in every EOF call and most of the calls that actually go across the bridge are just a NiO interface cocoa we don't use the bridge much at all the two worlds of VOF and cocoa are pretty well separated very well separated so this works out well for stability as well as performance since you don't pay the hit of morphing objects from the Java world to Objective C and back that doesn't happen nearly as much anymore but it is still there so you need to be aware of the different memory models between Javas of course garbage collected memory model and the Objective C memory model where you have to explicitly retain or release objects so what that means is you can occasionally be using a pure Java object in your bridge java method and the bridge will decide to forget about your object well we offer some utilities to utility methods to help with that to make sure that the bridge doesn't automatically clear out ear objects retain object and release objects are two methods in yo cocoa utilities and yo cocoa utilities lives in yo interface cocoa these two methods help you do the retain and release calls that you would normally do in Objective C except you can do them on your java objects now so back to our original graph of cocoa and EOF so there you have cocoa two special parts of AOF the JDBC adapter and yo interface cocoa well of course yo F has more layers than just this we also have vo control yo access and EO interface in there and in a little more detail I'd like to go through exactly what it does what BOF is doing here so the first layer there eel control eel control is really the core of EOF it's it's what handles all of your business logic it's where your business logic lives and as such there's the editing context yo editing context which which handles which it holds all of your business objects for you know control and it maintains an object graph of all of your business objects so that means that contract changes to objects as well as relationships and the objects in certain new objects delete objects all the all the change tracking can be handled in yo editing context so that includes undo and redo support and everything and of course your control is also very very performant so we offer things like faulting which allows you to not fetch your entire database into your application when you're not actually using all of those rows so that's a little a little brief overview of vo control we also have yo access yo access is the part of EOF that actually connects two data sources and it's built as you saw in an anon and adaptor architecture where our default adapter the JDBC adapter is what talks to databases using JDBC to drivers well you can also slip in your your special adapter classes here your special adapter layer to connect using jndi to LDAP servers or xml adapters whatever custom data sources you can come up with and the real functionality of EO access of course is object relational mapping so that means mapping all of the the relational rows in your data source it's real objects in EO control and that mapping between the two is held in an EO model file to build with EO modeler ichiro model contains a definition of all of the attributes of your business object as well as the mapping from your business object attributes to two individual columns let's say in your database and another important layer to EOF physio an EO interface all the classes in this layer are responsible for actually displaying data in the user interface this is where it this is where yo display group lives yo display group you'll use most it's our common gateway to multiple data sources it wraps an array of business objects that it gets from a it's data source which is typically an editing context and it handles coordinating updates of the user interface getting the values from the EOS it contains and setting them in your cocoa interface or actually any into any any widget interface cocoa or swing as you'll see later so your display groups work with yo associations for for updating the user interface keeping the user interface in sync with all of your business objects yo associations are the parts that actually connect display groups to widgets in the air user interface so that means we've got text associations for example to display data in your databases that comes up as text or even dates numbers so that things are formatted properly in the user interface we also have other associations for displaying let's say images in NS image views or handling all the data in tables and table columns so the associations really keep the display group connected to your interface widgets but there are also other associations that can connect display groups to other display groups as an example there are detail master detail display master detail associations which can connect a master display group in which you're fetching possibly all of the people in your database and it connects that display group to a detail display group which could be displaying all of the addresses for those people this means that once you've selected a person in your persons display group the Association will automatically tell the detail display group to display that person's address information all these are available for just in yo interface and don't let all to talk about Coco fool you we also keep yo interface very separated from the details of any specific widget set it's abstract away from all of the details using plugins so you can actually use yo interface in in Java client applications as well as cocoa applications its widget set agnostic so why all the all the layer talked though well as I said just now knowing that yo interface doesn't depend on any specific widget set but code doesn't depend on cocoa let's say you know that when you code when you write code right let's say new associations that you can use them anyplace yo interface is used so new associations can be used in Java client or cocoa client so the plugins though that do know about the widget set specific details live in yo interface cocoa all the plugins in this layer know how to handle targets and actions and know how to connect up to become data sources or delegates of certain widgets they all handle certain specific tasks typically type morphing so that an image of an image Association plugin will know that NS data coming from yo interface can be displayed as an NS image in an NS image view and it knows how to do set and get so set object value and object value in cocoa with cocoa widgets and it also there are many plugins that also handle events from cocoa so they can register as delegates for methods and as data sources and of course this plug-in set is extendable to other widgets we know that you go you all have widgets that you may like that aren't available with the default cocoa set so you can build your own NS views custom views your own custom widgets and create a plugin for it that you can use in your cocoa EOF applications so how does everything how do all the layers interact when you're actually trying to do something let's take another example of trying to fetch objects into the user interface so a cocoa widget I hope you can all read this actually a cocoa widget will fire off an event to the plug-in that's registered for it in yo interface cocoa the plug-in sees oh something's changed and tells its association the association in turn makes sure that the display group qualifies for your fetch let's say the display group then goes and tells its editing context to a new fetch gives it a new fetch specification and the editing context goes to its data source which is the database context Ennio access yo access will fetch any new objects that it needs to and change that raw raw data into full enterprise objects into your business objects and then any subset that's related to the fetch will be sent to the display group so this way group now contains a certain subset of the iou's in your editing context that it fetched for the display group then of course tells the association new values have come in and the association gets those values and hands them off to the plugin that it's associated with the plugin takes the value that it's related to and knows how to do set and get methods in cocoa to put the values into your user interface so it's a pretty simple chain up and down the cocoa EOF stack with cocoa at the top and EOF at the bottom and that thin layer of yo interface cocoa in the middle so I'm going to ask Andrei Linde occur to come out and give a demo show you exactly what cocoa EOF applications look like so here we've got a pretty simple model maybe kind of hard to read back there but it's based around a person and some information about that person so that's the model we're going to use in our application so we just go to project builder and create a new project one of the types that you can choose here is cocoa EOF application you go ahead and you do everything you would with a normal project you name it you choose a place for it to live and then you add any frameworks that you need we're going to skip frameworks and directly add a model so the one we're going to choose the layout that we're going to choose is a master-detail layout and all you do is you choose your main entity and any attributes that you would want to show in your tables the master detail layout by the way by default shows you a table for your master display group and another table for your detail display group so you choose your master detail your master entity and your detail entity and all the attributes you want to show in those tables so we go ahead and we build the project for you and as you can see this is really just a cocoa application with a few extra things in it we've got our main dem we've got our main menu nib and actually we've added a few other frameworks we've added Java EO cocoa as well as some of the standard EOF jars that you'll get with web objects 5 oops we've added our education model and to show you the nib this is the nib that we build for you that our assistant builds for you by default using a master detail template we fill in all the all of the details of putting in table names table column names and labels for your forms and of course give you the ability to do some of the simplest things you would do add and remove objects fetch new objects and save back to the database you can tweak the nib and add everything and it add anything you want edit it any way you want it's really just a cocoa nib so you can see Andres is here just beautifying some of the names and we can go ahead and save and once we build the project and run it so remember we've written no code and then all of a sudden we have a Coco application that can talk to EOF and talk to our database browsing live data in our database editing values saving values the whole the whole nine yards without any code so far but of course you're probably not going to just sit there and use our assistant built application you can add stuff you can add even other display groups that we may have missed from building it in our assistant so you can simply drag a new display group from yo modeler and wire it up in interface building this is another one of the beautiful things that we can do with with objects that we've added the functionality that we've added to interface builder being able to connect these display groups to the widgets so we can choose a pop-up and connected to person type so we can now choose from a pop-up list what type of person we're editing so we can edit the person and as you can see you can actually traverse relationships so person to person type and notice that andreas hasn't recompiled you may be aware of the test interface functionality of interface builder well you can still use that with cocoa EOF no more recompiling simply back to the slide so I'll hand it off to undress now and he'll talk a little bit about Java client thank you so my name is andreas venca and I'm the manager of the web objects rapid development team and I'm going to use the rest of the session to introduce you to our Java client technology so Java client is another technology inside the Bob projects you can use to develop desktop applications it has a lot of things in common with cocoa and EF but there are also a couple of differences one of these differences is that Java client is implemented in pure Java so the user interface we use the Java foundation classes of swing and that basically makes travel client platform independent in the sense that it runs on all platforms that support JDK 1.3 the other important difference between Java client in cocoa uf is their Java client uses a three-tier architecture not a two-tier architecture so we have a client that displays the user interface and interact with the user we have a server that accesses the database and we have a database that stores the data now it's important to know that the client never directly accesses the database right all the database access goes through the server so the server has full control over what the client can do with the database and what it can do the other thing interesting about Java client is that it uses HTTP as the communication protocol between client and server so you basically get the connectivity of an HTML application running the browser right you can access it you can access the server from anywhere in the world but you get a much richer user interface let's take a look at what we have to do with the architecture to make this work with Java client so you already know that instead of cocoa we use Java client so outlet cocoa and in sorry I said if you sling so in this thing using swing us means that we need to no need to use a new plugin layer right we have this plugin layer that connects the interface layer and cocoa and we have a new plugin layer that connects the interface layer and saves the swing this you layers called you interface I also mentioned that we don't access the database directly anymore so if we don't use you access into JDBC adapter and instead we use layer that we called you distribution that takes care of connecting to the server also for your convenience we added another layer which is called your application I talked more about that in a minute and something you should notice is that the you control and the you interface layer stay the same in both architectures so code that you write against your interface or the your control layer that mostly means your business logic can be used in both architectures now let's take a look at these new layers in more detail you application layer exists because swing doesn't offers all the functionality that cocoa gives us swings a relatively plain widget set it has a lot of user interface elements like text fields buttons windows but it doesn't help you a lot that higher level tasks like simply starting your application what else like implementing a document management maybe managing user defaults or handling menus and so we created the application layer to help you out with these tasks it's a layer that provides you a lot of utilities that you can use to manage your user interface and another very important feature of the application layer is that we edit the ability to load interface files that you created an interface builder that's actually pretty cool because you can use the same tool to create user interfaces for both cocoa applications as well as Java client applications there's just a little problem with that because out-of-the-box interface builder doesn't allow you to edit swing nib files right if you can only edit cocoa or carbonate files so how do we deal with that well you're a little extension that translates the cocoa interface file into a swing interface file right you don't really see this this translation it just happens for you whenever you save your nib file but what it means is that you can create the file if interface in interface builder and then use it in the Java client application and we will show you how that looks now let's talk about the distribution later the distribution layer replaces the EU access layer as the data access layer so clients fetch business objects not from the database but they fetch the objects from the server and if they have changes that they want to say they also save the changes through the server and on top of exchanging business objects the distribution layer gives you a convenient API to do remote method invocation so if you have something you know that you need for your client application to deal with some kind of resources or so that is independent of business logic the distribution layer has an API that you can use to contact the server so the complete picture then looks like that so there are lot of boxes but the important piece is that we basically pushed the you access they and the JDBC adapter to the server side and the server is actually pretty normal about this application to use of excess and JDBC adapter to exit the database we have you control to manage business logic your fehb objects do the things like sessions and we also have a server side component for the distribution layer which flex interval objects and make sure the Java client works fine as web options something there's very interesting about our distribution area is that it uses a copy distribution mechanism for business objects that's very different from what most other technologies for 3ts use most of the technologies use some kind of a client stuff but that means is that the client business object is just some kind of an extension to the object that really lives on the server and the client has to ask the server for every little detail right so there's a lot of communication going on in our distribution layer business objects actually copied an affair and the effect from the server to the client and they live as fully functional objects on the client side I think a good way to think about Java client is that editing context on the client-side behave like a nested editing context to an edited context leaving the session of your server side what does that mean well those of you familiar with UF probably know that a new editing context which are by the way abbreviated with EC in this diagram it's just a special form of an object store an object stores have parents the parent object stores the the object that is really responsible for providing data in the normal case if you're just on the server if you write an HTML based application the OP the parent object stuff in editing context is a database context abbreviated DC in this diagram the Java client we introduced a new type of object store which is called the distributed object store deos the distributed object store lives on the client side and it's task is to connect the editing contexts on your client side to the editing context on your server side so as you can see from this diagram the only way for your business objects of your business data to get from the client into you into the database is through the editing context on the server side and that's where you have all the control right so you can control exactly what goes to the database let's take another look at this diagram just quickly I want to point out again that the control layer that's really important is used on both sides of the architecture now the java client you have the choice to either use the same identical business logic on both client and server or you can use what we call petition business logic petition business logic means that the implementation of your business logic of your business objects on client and server is different and it can be different in two ways you can limit the visibility of properties to the server so that you don't even send to the client what you don't want to see and also you can use different implementations for the two Business Objects so you can actually force the client to make a round trip to the server and use an implementation provides there that adds a lot of value to the application and it adds value in two areas in the area of security and in the area of performance I think the area of security is pretty obvious because you don't send any data to the client that you don't want it to see and you don't even send a compiled code to the client that you don't want it to know about because since we use Java you all know that the code can actually be pretty easily decompiled so if you have code that you consider secure or secret and you don't want to send it to the client but then you can keep it on the server and force the client to invoke that code the other at the area is performance business logic petitioning helps you with the performance because if you have the great server with 500 processors and lots of gigahertz then you can make your clients use the high computing power of your server today that probably doesn't matter that much anymore because most clients are fast enough but more importantly you can use business logic to avoid that too much data is transferred between client and server you can minimize the amount of communication between client and server so if you have an algorithm some kind of computation that requires you to look at a lot of data but you don't really want to display that data on the client you just want to display the end result then the right thing to do is to execute that computation on the server fetch the objects that you need for the computation only on the server and then just send the end result which is much smaller the Java client we have two different options to deploy you can deploy the client as an application it's a full desktop application there's an IP that you can double click on the desktop or you can deploy as an applet embedded in some HTML running inside the browser I would like to take a moment and compare these two options for you the most compelling advantage of the applet is the simplicity of the installation process because there is basically no installation process when applets start they download all the classes that they need to execute the program from the server side and then execute the program inside the browser with applications we have to install a start program on the client machine and all the classes that you need to execute the client so you have to give your end-users some kind of an installer that installed or that read but that just puts the application on the desktop now if you have something if you want to upgrade your application you get a lot of trouble so if you have some back fix this you get a lot of trouble with the desktop application because now you have to make sure that all your clients install the new version the applets that's so much easier because you just upgraded on the server the next time the client launches the new classes are downloaded and the client has automatically updated nevertheless application score much higher in the area of user experience it's just so much nicer for users to start an application from the desktop to not have to wait 30 seconds until all the classes are downloaded and to have an application that is actually fully embedded in your desktop environment applications you can hide you can minimize windows you have access to service menus etc you don't have that with applets you will also find that applications perform a little better than their applets and the reason is that they are very isolated applications run as standalone processes while applets all the app that's running in one browser share the VM the the other code and it can have all kinds of negative side effects and both performance as well as stability from your perspective as the developer applications also have the advantage that you don't have to deal with security restrictions in applets there's a security manager installed which prevents the application the program from accessing your filesystem from accessing your arm so the system prep system parameters you don't have to deal with that in an application so if you have the need to store something the FIDE system it's much easier for you to do that as an application but the users might see that it is different and that's why I got a little dot here in this diagram from the users perspective applets are usually executed as untrusted code and the Java VM ensures that the program can't mess to the computer so users might see that little different than you but we think that in the environments where you install Java client will use Java client applications which is mostly intranet it probably doesn't matter so much because your users should trust the system administrator that the software's are good so another advantage that might come in handy with applications is that you full control over all the VM parameters let's say you need a very large heap size you can adjust the heap size with an application because you have control of the star program you can in applets it's not I would like to ask Ron to come out and give you a demo or a Java client you're basically going to create the same application that we created with Coco the Java client so if you go into project beta if you create a new project to is a different kind of project type give it a different name then we add some frameworks this time we actually do at a framework it's called Java class loader it's just for the demo purposes it's not part of every objects 5 just makes our our demo seem really easy so it was the same model if you did for cocoa and then there's something interesting this is different than in cocoa it asks us for so-called interface controller class the interface controller class is a class that we generate in the assistant and it's a very convenient class for you that helps you to manage user interfaces and to especially load interface files so the assistant creates for every interface file that you create you also create an interface controller class now we do the same thing the rest of the assistant is basically the same which was the master data layout justperson it's the main entity and lastly first name person type chamber last time interesting for the forum attributes choose addresses as the relationship e1 to display and we pick a few attributes that we want to display in the table for the addresses and in the forum and that's it so this project now looks a little more complicated than the one for Koko the reason is that now be happy for the object's application if all the components that you know via familiar bits of the server-side and actually projects that web objects have two different targets once the application server target the other one is the web server target the application server target contains all the objects and resources that you need on the server-side web server target the ones for the clients file and this little donut see on the left side they ways to show you to which targeted a file on so as you can see we have a normal application we have an application in class the session asset ID action class and if you look inside the main that thought for a second you can see that it's a reusable Java client the applet and we specify the interface controller class name here it's the interface we're going to do so this is our connection from Java client from the client side into the server that we use the special class for Java client applet now let's take a look at the client side so there are two files there's the code the Java internet Java client interface controller class and there's the interface file why don't we open that an ID so it's a space with the same interface file that we had for cocoa and every one is going to beautify it again so we get in vendor a bit tighter you modify a few flavors okay I think that you do and then you save and now we go back to project beta and actually compile this particularly longer then with cocoa because now we have a client and a server certain needs to be compiled okay and run is not starting the server side of the application the nice thing about this little framework that we added is that it hard-code some of the port numbers we want to use and it allows us to use a little Start program that we wrote which is a Java client launcher and then you can just enter the new air and it happens to be the right one and our client connects to the server and this is the client application so as you can see it looks pretty similar to what we had this cocoa we have a table you can enter values you can change values it just behaves the same way and all that without writing code okay if you want to show you something else in earlier releases of our objects the snipper translation had a bunch of problems and it's still a little problematic because there are these two different worlds cocoa and swing and they don't always match exactly but we think that interface builder is really the greatest tool on the planet to it to create user interfaces and it's especially the only tool that allows us to set up connections and in UF we really need connections we need to set up all these associations so interface builders with the best choice for us to generate interfaces and build objects five you try to fix all the bugs and we would like to show that to you by just overlaying the interface fire and running application and then minimizing the window in the interface process you can see let me see it Maps pretty good there are a few differences just you know maybe swing draws the text one pixel higher in a button then Coco does or so but basically if you overlay the two nib files it looks pretty much the same okay can we go back to the slides please the Java client we also have a technology because I director Java client director Java client is an infrastructure that helps you developing Java client applications very easily and very rapidly and that's so by providing you with a lot of predefined application functionality that you can make use of and it relieves you from the burden to create user interfaces by hand instead it actually generates the user interfaces dynamically for you and it does that by analyzing the you model and coming up with a good scheme to display and edit your data and you'd actually like to give you a short demo about that it's very we would have a full session about it later this afternoon but we'd like to show it to you here as well so if you could go back to the demo to see so we go back to project beta again to create a new project just a different project type this time it's director Java client you give it a better name if we add our little Java client class loader framework just that our demos are easy and it was the same model again and the last option is to build and launch the application automatically for us so run if you expand all the groups again so you see there's still a tab objects application the one thing that is different about it is that if you go to the main dot but again it now uses another application class it's the new dynamic application and that's just a special class that makes sure that your client does something sensible even if you didn't give it any interface why because as you can see here there is not a single interface for I defined there's actually not a single file related to the client that you have to create so the program automatically compiled and launched for us and all we need is a Java client launch again to connect and the reason why this works are simply is that we have this little framework and this is the application we get into okay so as you can see this application here has a little more complex UI we have a QA interface for purses and departments we see much more entities in our model we can search for persons and then you can open them and if you open them you get the detail in those and why don't you make that and you can switch around to addresses phone numbers so as you can see the just a very few steps we were able to create a fairly complex UI but it allows us to browse the whole database and you know display and edit all the values in your database okay thank you Ron and I think can we go back to the slides please before we go into question answers I would like to take a moment and compare the two technologies that the introduced to you run introduced the two-tier Co Co UF applications and I talked about the three tier Java client applications what are the differences well Coco is a mega stand only technology so Coco you have applications you can only deploy on Mac OS 10 the Java client you're basically platform independent you just need a platform that's supposed to dedicate 1.3 but if you want to give your users the optimal user experience unlike us 10 you would have to use Coco swing is platform independent but that also means it's not especially designed for the Mac so if you want the best user experience for your users on Mac OS 10 then you have to use cocoa Java client and swing still gives a very good user experience and especially with all these optimizations that Steve narrows team is working on the applications get faster and faster and it's really hard it starts to get really hard to distinguish cocoa and its thing when it comes to deployment you have to have an installation on the client machine with cocoa applications the Java client we have two different options you can deploy an application or as an applet we usually recommend to deploy as an application because the user experience is so much better the form is a little better and you can tune out the parameters but you have both options from the administration perspective cocoa applications you know you it's like every other desktop application the Java client it's a little more complicated because now you suddenly have two things you have a server that you need to administer it you need to make sure that it performs fair and you have to have and you have to client so it's a little more complicated need more work for you the performance of cocoa application is just fine the performance of Java client applications is still fine but you have to make sure that you that your petition your business logic correctly so that the communication between client and server doesn't become a bottleneck and also buts being the user faces a little more sluggish than Coco I personally don't think it matters it's really close enough and when it comes to security cocoa applications you can only use in the internet intranet because the application directly access your database but you don't want to give that anybody outside your company the Java client gives you all the tools you need to make your clients or your database secure but there are still these complications with either did installing the application or you face this 30 second at least download time of classes if you deploy an applet so that's why we think it's not really a technology that is suitable for high traffic internet sites and Java client is also mostly in Internet technology the reason why I wrote internet plus plus is that since you have all the tools to make it secure enough you can actually use it in you know in what I call controlled environments so let's say your software company you have a backtracking system where you lock all your bugs and you have a few customers if you prefer customers that you want to give a diet login into your database right it makes perfect sense to give them a Java client education right but as I said it has to be a controlled environment because of the installation complications okay so you have some time but we care a lot about desktop applications right if you care so much about it that you give you two technologies to implement them you introduce to you the Koch ouf applications which are two two-tier and introduced Java client applications reserved treat you the both architectures you get incredibly powerful database connectivity for your desktop apps and it's something to keep in mind is that the business logic code you write can be used in all architectures can be used in Java client it can be used to cocoa and it can be used in a bib object HTML application who has not seen that good the sessions I recommend to you related to this topic our session number six net six later this afternoon about directed Java client and number six net 14 tomorrow advanced java client you