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