J2EE for Smalltalkers

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 JTS-

enabled 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 cycle?

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)

Employee(EJBObject)

EmployeeHome(EJBHome)

EmployeeBean

“container”

“RMI”client

Container generated classimplementing the Remote Interface - instances are called“EJB objects”

Developer defined class - instances are called “Bean instances”

Container generated classimplementing the Home Interface

Conceptual View

Interface Class

extends

implements

container generated

developer defined

EJBObjectImpl

AccountBeanEOImpl

Account

EJBHomeImpl

AccountBeanHomeImpl

AccountHome

AccountBean

EntityBean

AccountBeanHomeImpl_Stub

AccountBeanHomeImpl_Skel

AccountBeanEOImpl_Stub

AccountBeanEOImpl_Skel

bean-developer defined domain class

bean developer definedremote interface, container generated remote implementation

bean developer definedhome interface, container generated home implementation

RMI EJB and Domain

server-generatedRMI stubs and skeletons

AccountHome

Account

AccountPK

bean-developer defined serializable primary key

Generated Classes

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 JTS-

enabled 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 cycle?

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– 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 it’s 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. They’re literally enforced. See 10.3.71