J2EE for Smalltalkers

1. J2EE for Smalltalkers Alan Knight Cincom Systems of Canada knight@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 API’s for standard services

6. 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”

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

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

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

11. What’s in J2EE (condensed) • Big pile of stuff • Only a few of them really interesting • Let’s 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 API’s, 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 <%= aPerson name %> • 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. Container generated class implementing the Remote Interface - instances are called “EJB objects” “container” “RMI” Employee(EJBObject) EmployeeBean client EmployeeHome(EJBHome) Container generated class implementing the Home Interface Developer defined class - instances are called “Bean instances” Conceptual View

31. EJBObjectImpl Account EntityBean AccountBeanEOImpl AccountBean EJBHomeImpl AccountHome Class Interface extends AccountBeanHomeImpl implements container generated developer defined 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 (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

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

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->Session Bean -> domain objects • Doesn’t add a lot vs. Servlet->domain 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 -> some extra infrastructure • Supporting technologies: portable LDAP useful

50. 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”