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]