J2EE for Smalltalkers

1
J2EE for Smalltalkers

• Alan Knight
• Cincom Systems of Canada
• knight_at_acm.org

2
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

3
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

4
Outline

• Definitions
• Quick overview of the simple parts
• Servlets/JSP in more detail
• EJB in depth
• For each
• description, motivation, Smalltalk equivalents

5
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 APIs for standard
  services

6
Why do I need to know about it?

• Know what youre missing
• Know what you need to coexist with
• Know what youre up against
• Hold your own in the battle of the acronyms
• All those dot-coms cant be wrong

7
Battle of the AcronymsWe want to build our
architecture around browser-based Java clients
talking to a scalable cluster of JTS-enabled BMP
entity EJBs
8
Wrong Responses

• Um, yeah, but Smalltalk is, like, good.

9
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 were 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 cycle?

10
Whats 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

11
Whats in J2EE (condensed)

• Big pile of stuff
• Only a few of them really interesting
• Lets quickly review basics and Smalltalk
  equivalents

12
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

13
Transaction Service

• JTS Identical to CORBA Transaction Service
• Distributed transactions
• Two-phase commit (some of them)
• Smalltalk equivalent
• CORBA transaction service

14
JMS

• Messaging Service
• Guaranteed delivery and ordering
• Transactional (with some issues)
• Smalltalk equivalent
• Bindings to proprietary APIs, e.g. MQSeries
• No portable API

15
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

16
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

17
The Easy Stuff (quiz)

• JDBC
• JTS
• JMS
• JNDI
• Connectors

18
Interesting Stuff

• Fundamentally, J2EE is
• Servlets/JSP
• EJB
• supporting technologies

19
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

20
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.

21
JSP

• Templated approach
• HTML containing code
• lt aPerson name gt
• Compiled into servlets at run-time
• Various conveniences inserted automatically
• Answer to Microsoft ASP (with add-ons)

22
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?

23
JSP Servlets

• Together make up a reasonable web presentation
  layer if used well.
• Servlets for input processing
• JSPs for presentation

24
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)

25
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

26
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

27
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

28
Entity Beans

• Shared
• identity provided by primary key class
• Persistent (relational assumed)
• Container-Managed Persistence (CMP)
• Bean-Managed Persistence (BMP)

29
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)

30
Conceptual View
31
Generated Classes
EJB and Domain
RMI
Account
bean-developer defined domain class
AccountBeanEOImpl_Stub
bean developer definedremote interface,
container generated remote implementation
AccountPK
AccountBeanEOImpl_Skel
bean-developer defined serializable primary key
AccountHome
AccountBeanHomeImpl_Stub
AccountBeanHomeImpl_Skel
bean developer definedhome interface, container
generated home implementation
server-generated RMI stubs and skeletons
32
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.

33
EJB Issues
34
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

35
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

36
Component Models (contd)

• 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

37
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

38
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)

39
Development Process

• Concerns
• Very heavy on code generation
• Beans cannot run outside container
• Turnaround time for changes
• Testability
• Debuggability

40
Development Process (contd)

• 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?

41
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

42
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

43
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

44
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

45
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

46
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)

47
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-gtSession Bean -gt domain
  objects
• Doesnt add a lot vs. Servlet-gtdomain objects

48
EJB Smalltalk Equivalents

• None
• Declarative transactions, security interesting
• Automated failover for sessions interesting

49
J2EE in Smalltalk Terms

• Depends on view of component assembly
• Servlets, Server Pages useful
• EJB for domain not useful
• Session beans -gt some extra infrastructure
• Supporting technologies portable LDAP useful

50
Battle of the Acronyms RevisitedWe want to
build our architecture around browser-based Java
clients talking to a scalable cluster of
JTS-enabled BMP EJBs
51
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 were 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 cycle?

52
The End
53
Extra Slides
54
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

55
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

56
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

57
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

58
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

59
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

60
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

61
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
• Dependent objects always serialized. Always
• removing an object must remove it from all
  relationships
• they still have to track any attempt to send a
  message to a removed object
• 10.3.4.1 implies 2 refs to 1 object but 10.3.6
  sounds like must still null out. Looks to me like
  must null out ONLY if its the same kind of
  relationship in another instance.
• What does relationship type mean? (ejb-relation
  and ejb-relationship-role)
• ah. Only affect 1-1 and 1-many. Theyre literally
  enforced. See 10.3.71