Transcript No Slide Title

J2EE for Smalltalkers
Alan Knight
Cincom Systems of Canada
[email protected]
Who am I
•
•
•
•
Carleton University
The Object People, 1992-2000
Chief Architect for TOPLink
Led TOPLink for BEA WebLogic
integration
• Sun “Expert Group” for EJB 2.0
My Background/Biases
•
•
•
•
Databases (relational)
Web stuff
Weak on mainframes, message queueing
J2EE
– Worked very extensively with EJB and JDBC,
especially entity beans
– Implemented ST version of Servlets/JSP
– Once read a white paper on Connectors
Outline
•
•
•
•
•
Definitions
Quick overview of the simple parts
Servlets/JSP in more detail
EJB in depth
For each
– description, motivation, Smalltalk equivalents
J2EE Goals
• World domination
• Easier distributed (i.e. web) apps
• web for VB programmers (PowerBuilder of
the Web)
• Transparent distribution, transactions,
security, connection management
• Provide Portable Java-Centric API’s for
standard services
Why do I need to know about it?
•
•
•
•
•
Know what you’re missing
Know what you need to coexist with
Know what you’re up against
Hold your own in the battle of the acronyms
“All those dot-coms can’t be wrong”
Battle of the Acronyms
“We want to build our architecture
around browser-based Java clients
talking to a scalable cluster of JTSenabled BMP entity EJBs”
Wrong Responses
• Um, yeah, but Smalltalk is, like, good.
Right Response
• Have we actually measured the gain from
clustering vs. the RPC overhead on fine-grained
entity EJBs. That also implies transaction control
at the client or else many fine-grained JTS
transactions. Since we’re standardized on Oracle,
the only reason we need the JTS overhead is in
fact because of the cluster. Plus the development
overhead is going to frustrate any attempts at an
XP process, or even unit-testing without major
turnaround times. Do we have estimates on the
impact of deployment costs on the development
What’s in J2EE
• J2EE
–
–
–
–
–
JDBC (database)
Transaction Service
JMS (messaging)
JNDI (naming service)
Connectors (“legacy”
adaptors)
– Servlets
– Java Server Pages
– EJB (Enterprise JavaBeans)
• Related Technologies
– CORBA
• RMI over IIOP
• Java bindings
• Transaction Service
– XML
• Most configuration files
What’s in J2EE (condensed)
• Big pile of stuff
• Only a few of them really interesting
• Let’s quickly review basics and Smalltalk
equivalents
JDBC
• Database Drivers
– Standard, interoperable drivers
– Not really standard, but no worse than others
– Most vendors supply drivers
• Smalltalk equivalent
– Vendor database drivers
– But, not as many, not as up to date
– ODBC, but platform-limited, performance and
features may vary
Transaction Service
• JTS: Identical to CORBA Transaction
Service
– Distributed transactions
– Two-phase commit (some of them)
• Smalltalk equivalent
– CORBA transaction service
JMS
•
•
•
•
Messaging Service
Guaranteed delivery and ordering
Transactional (with some issues)
Smalltalk equivalent
– Bindings to proprietary API’s, e.g. MQSeries
– No portable API
JNDI
• Java Naming and Directory Service
– Maps to multiple different services
– LDAP by far the most important
• Smalltalk equivalent
– CORBA naming
– bindings to LDAP, DNS, or others
Connectors
• New mechanism for standard interfaces to
outside systesm
– transactions
– connections and pooling
– security
• Resources map Java concepts onto outside
systems
• Not many exist yet
The Easy Stuff (quiz)
•
•
•
•
•
JDBC
JTS
JMS
JNDI
Connectors
Interesting Stuff
• Fundamentally, J2EE is
– Servlets/JSP
– EJB
– supporting technologies
Servlet Features
•
•
•
•
•
CGI overhead not required
Very simple and lightweight
Full flexibility and control for programmers
Automates header parsing etc.
But, awkward, pages must be built by
programmers
Smalltalk Equivalents
•
•
•
•
•
•
VisualWorks 5i.4 (Web Toolkit)
Whitecap (VW + Apache Jserv)
Wiki
Swazoo/AIDA
Commanche
Servlets are like commands, not like objects
that know how to render themselves.
JSP
• Templated approach
• HTML containing code
<%= aPerson name %>
• Compiled into servlets at run-time
• Various conveniences inserted automatically
• Answer to Microsoft ASP (with add-ons)
JSP: Smalltalk Equivalents
• VisualWorks 5i.4 Web Toolkit
• Tsunami (custom tags only)
• Various templating schemes
–
–
–
–
Squeak SSP (but html in browser)
VisualAge + VisualWave file templating
WikiWorks
Others?
JSP + Servlets
• Together make up a reasonable web
presentation layer if used well.
• Servlets for input processing
• JSPs for presentation
EJB
•
•
•
•
Enterprise Java Beans
Very large and complex topic
Not well understood
In flux (1.1 widely implemented, 2.0 still
quite new)
• Strongly-hyped
• Fractal (the superficial complexity conceals
the underlying complexity)
About EJB
• History
– Server-Side component model
– Attempt at a Java answer to MTS
• Objectives
–
–
–
–
–
Server-side component model
Portable beans
Easy for “typical” developers
Scalability
Automatic distributed transactions
EJB Basics
•
•
•
•
Beans: server-side, remote, RMI semantics
No relation to JavaBeans
Roles: author, deployer, user
Several types
– Session: services (instances not shared)
– Entity: domain objects (instances are shared)
• Very web-focused
Session Bean Types
• Stateless
– only lives for the duration of one method call
– very scalable
– like MTS, Tuxedo, CICS (sort of)
• Stateful
– Explicitly created and destroyed
– Maintain transient state
Entity Beans
• Shared
– identity provided by primary key class
• Persistent (relational ~assumed)
– Container-Managed Persistence (CMP)
– Bean-Managed Persistence (BMP)
Beans are Distributed Objects
• RMI Semantics
– Non-beans always passed by value
– Beans always passed by reference
• Users never see the bean
– EJBObject acts as a stand-in
• Related beans can see either the remote or
local (but only one - no polymorphism)
Conceptual View
Container generated class
implementing the Remote
Interface - instances are called
“EJB objects”
client
“RMI”
“container”
Employee
(EJBObject)
EmployeeBean
EmployeeHome
(EJBHome)
Container generated class
implementing the Home Interface
Developer defined class instances are called
“Bean instances”
Generated Classes
EJB and Domain
RMI
Account
EJBObjectImpl
EntityBean
Account
AccountBean
AccountBeanEOImpl_Stub
AccountBeanEOImpl_Skel
AccountBeanEOImpl
bean developer defined
remote interface, container
generated remote implementation
AccountHome
EJBHomeImpl
AccountPK
bean-developer
defined serializable
primary key
AccountHome
Interface
AccountBeanHomeImpl_Stub
AccountBeanHomeImpl_Skel
bean-developer
defined domain class
Class
extends
AccountBeanHomeImpl
implements
server-generated
RMI stubs and skeletons
bean developer defined
home interface, container
generated home implementation
container generated
developer defined
Deployment
• Adds remote wrappers, generates all the
additional classes
• Declaratively specify
– transactions (participates, requires, requires
new, none)
– security (who can invoke this method)
– lots and lots and lots of other stuff
– typically multiple deployment descriptors,
much larger than the bean class.
EJB Issues
EJB Issues
• Overall Complexity (current spec ~500 pgs)
– 18 pages on Assignment Relationships”
• Component Models
• Development Process
• Threading and Concurrency
• Performance and Scalability
• Usage Patterns
• Persistence
Component Models
• Widget-like
–
–
–
–
–
java beans, visualage parts, COM
stand alone, re-use in many contexts
strong author/user distinction
coupling via events
no visible inheritance/polymorphism only to the
general “widget” interface
– reflection-based exensibility, visual manipulation
– e.g. widgets
Component Models (cont’d)
• Service-like
–
–
–
–
–
session beans, COM/MTS
stand alone, re-use in many contexts
strong author/user distinction
very little coupling
no visible inheritance/polymorphism only to the
general component interface
– reflection based or no extensibility
– e.g. legacy system wrapper, complex i/o library
Components vs.Domain Objects
• Domain Objects
–
–
–
–
–
strong relationships with complex interactions
difficult to re-use despite decades of research
weak author/user distinction
heavy use of inheritance and polymorphism
e.g. most “business objects”
Component Semantics
• No inheritance
• Entity relationships
– undefined in ejb 1.0
– strongly specified in ejb 2.0
•
•
•
•
container-maintained
specified in the deployment descriptor
remote or local
heavyweight (sometimes very)
Development Process
• Concerns
–
–
–
–
–
Very heavy on code generation
Beans cannot run outside container
Turnaround time for changes
Testability
Debuggability
Development Process (cont’d)
• Suggests
–
–
–
–
–
fine-grained (non-bean) business objects
test and run outside of container
very thin session bean wrappers
no entity beans
advantage vs. direct business objects?
Development and Deployment
• Deployment is very complex
– especially in ejb 2.0, more complex than
development
– CASE tools required
– targets component assembly
• up-front design/build re-usable components
• later application assembly phase
Threads
• No need to worry about threads,
transactions, or security
• Thread Isolation
– at most one call to a bean instance at a time
• Therefore only two concurrency options
– pessimistic in-memory locking
– per-user copies of the bean
Threading and copies
• One call at a time
– distributed calls, no distinct process stack, so
“loopback” calls are prohibited (recursion,
double dispatch, etc.)
– Beans can be marked re-entrant, but thisi s
strongly discouraged
• Pessimistic locking bottlenecks too easily
• Per-user copies use a lot of space
– must copy even on read
Persistence
• Session beans
– serializable for timeout/clustering purposes
– database persistence left to the user
• Entity beans
– Bean-Managed Persistence
– Container-Managed Persistence
• A wide variety of issues
• Actively hostile to OODBs
Performance and Scalability
• Scalability usually costs performance
– e.g. stateless components
• Scalability-related features
–
–
–
–
–
–
distributed transactions (~100x normal)
all calls distributed
instance pooling + passivation
maximum numbers of instances
thread pooling
database connection pooling
Clustering
• Scalability to multiple servers
–
–
–
–
global locking issues for entity beans
server cross-communication issues
can force transactions to be distributed
complicates some issues (e.g. write order)
Overall Usage
• Entity beans essentially unusable
– performance
– development
– 2.0 probably worse than 1.0
– semantics
• Sesssion beans as thin layer quite workable
• Typically Servlet/JSP->Session Bean -> domain objects
• Doesn’t add a lot vs. Servlet->domain objects
EJB Smalltalk Equivalents
• None
• Declarative transactions, security interesting
• Automated failover for sessions interesting
J2EE in Smalltalk Terms
•
•
•
•
•
Depends on view of component assembly
Servlets, Server Pages useful
EJB for domain not useful
Session beans -> some extra infrastructure
Supporting technologies: portable LDAP
useful
Battle of the Acronyms Revisited
“We want to build our architecture
around browser-based Java clients
talking to a scalable cluster of JTSenabled BMP EJBs”
Right Response
• Have we actually measured the gain from
clustering vs. the RPC overhead on fine-grained
entity EJBs. That also implies transaction control
at the client or else many fine-grained JTS
transactions. Since we’re standardized on Oracle,
the only reason we need the JTS overhead is in
fact because of the cluster. Plus the development
overhead is going to frustrate any attempts at an
XP process, or even unit-testing without major
turnaround times. Do we have estimates on the
impact of deployment costs on the development
The End
Extra Slides
Homes and Finders
• Used to create, destroy and lookup beans
• Registered with JNDI
• Finders
– Entity Bean Queries
•
•
•
•
Defined as methods on the home interface
Static
EJB 1.0 no definition
EJB 2.0 EJBQL query language
Persistence
• Strong assumption of relational
– actively hostile to OODBs
• Sessions beans not shared or persistent
– may use persistent domain objects or entity
beans
• Entity Beans
– BMP
– CMP
Bean-managed
–
–
–
–
–
–
“complete” control, but only per-bean
conventional wisdom prefers
inefficient on read-many
no control over write order
assumes write-through/no sequence numbers
impose a lot of limits on what a good
framework can do
CMP 1.0
• Very limited
–
–
–
–
–
–
only simple types
one bean per table
relationships undefined
vendor-specific enhancements available
queries undefined
no control over caching or locking
CMP 2.0
•
•
•
•
•
invents new query language
no dynamic querying
no intetgration with cache, locking
adds “local” beans with relationships
breaks normal programming language
semantics
• assumption of write-through
Primary Keys
• Entity beans have Primary Key classes
– For simple keys, can be primitives
– For composite keys, a class whose inst vars
mirror the key inst vars of the bean
Activate/Passivate
• Maximum number of instances at a time
• Surplus or not recently used instances are
passivated
– serialize or equivalent to persistent storage
– re-use memory
2.0 notes
• Relationships can be local now
– local not polymorphic with remote
– permissions not checked
– so beans can be essentially local objects. Where
does the cmp intercept come in?
– the code-generation crap is in there
– may or may not have local interfaces
– there *are* dependent values
– is the relationship fixup in there? yes