Java 2 Enterprise Edition (J2EE) Overview And Experience Report

1. Java 2 Enterprise Edition (J2EE)Overview And Experience Report David Kamber dk@zuehlke.com Zühlke Engineering AG

2. Who is your speaker? • David Kamber dk@zuehlke.com • Since 1987 working for the banking industry! • Trading systems, real-time information systems, order routing systems, reference data systems, risk analysis systems, limit systems ... You name it! • VAX, Pascal, RMS • C++ RDMS on UNIX • C++, Java, CORBA, OODBMS, RDBMS on UNIX • Java on UNIX • J2EE on Windows and UNIX • Java since 1.0 betas Used to be dk@netscape.com in the early web days.

3. Agenda • You should get an idea what J2EE is all about, what it can do and where it may fit in and where not: • Short history walkthrough to present (and motivate) the features • Look at the model application according to the architecture blueprint • Look at some typical issues • Look at successful features • Discussion, discussion, discussion ...

4. Where did J2EE come from?Web programming in the very old days • CGI Programs: • Perl CGIs • Python CGIs • C/C++ CGIs Primitive Lifecyle model: • invocation per request • no state • no resource sharing • communication with web server via stdin/stdout

5. Where did J2EE come from?Web programming in the old days • „CGI Processes“ • FastCGI • External „keep-alive“ Perl process • Same interface as CGI • Only compatible with very clean CGI scripts(variables survive requests) • Netscape IIOP „Servlets“ • IIOP communication with Netscape webserver • Almost exactly same API as Servlets 1.0 • Kiva Application Server • Proprietary but almost J2EE 1.3 !!! • Mixing possible with C++ „Servlets“ • Amazing product!

6. Servlets • „CGI programming with state preservation“ • Servlets receive the request from the Webserver • Generate HTML output stream (writeln !!!) • Session state per user • Application state per application (group of servlets) • DB access usually via JDBC

7. Servlets: why anything else? • Tedious to generate pages using writeln statements • No separation between representation and code • All HTML and JavaScript as writeln statements within java code! • Business logic intermingled in between output statements

8. Java Server Pages (JSP) • “A HTML page with Java code” • HTML page with a different extension • In the HTML there is Java code within special tags (XML-like tags) • Gets translated at the first hit into (almost) a Servlet • Almost no writeln anymore

9. JSP: why anything else? • You end up with lots of different languages in the same page: • HTML • JavaScript • JSP tags • Java • HTML editors (the tool) will “eat” your Java code (its not tags!) • HTML designers (the person) will somehow break your Java code

10. JSP Tag Libraries • You define your own tags • Your Java library code gets called whenever a tag is encountered • You can pass parameters • You can access request parameters • There is now a Standard Tag Library form the Jakarta project that even includes support for database access!

11. JSP Tag Libraries: why anything else? • What about non-browser clients? • Your business logic is hidden inside the Web Container • You cannot reuse it: you cannot call Servlets, JSPs or Tag Libraries from within your application (they are not library code!) • HTML pages are not Webservices!

12. Enterprise Java Beans (Session EJB) • Isolate your business logic (the mechanics) from its visual representation. • Something like a Servlet but with Java objects as request and Java objects as the response • Not multithreaded as Servlets are, you get your own object • Can be stateful or stateless • Support for something like paging (passivation/activation) • Transaction management is taken care of (if you want)

13. Enterprise Java Beans (Entity EJB) • Persistent objects built for you by the container • No worries how they get are read from the DB and stored in the DB • Some (limited) support for relationships and navigation • Query language (very similar to SQL) • Container should worry about consistency and performance related issues

14. EJBs: why anything else? • Everything is synchronous request/response. • How do I access backend systems that are not databases? • Batch jobs? Cron jobs? • Revision of the J2EE and the EJB specification

15. Message-driven Beans MDBs • Some sort of queue endpoint • You can send asynchronous messages to a EJB container • Pool for consuming messages from the the queue (JMS) • In most cases contains no business logic calls EJBs • EJB local interface should be called

16. The Java Connector Architecture JCA • A “plug-in” framework for J2EE • Allows you to define any kind of extension • It will be possible to have your own network connections/server - Opens up J2EE for almost any kind of interoperability as long as you do it yourself

17. Webservices • Leverage HTTP and XML for integration • Mostly HTTP as transport • Because its there • Gets through all firewalls • Very platform agnostic, can integrate with almost anything out there • RPC-like communication (XML-RPC and SOAP) • Some messaging possibilities proposed (SOAP can be run asynchronously) • Nice interfaces that should hide the complexity • Webservice-enable any EJB without writing any line of code

18. The J2EE Security Model • It is a fairly simple trust based model • Authentication happens when you enter the J2EE world (mostly through the web container) • Throughout the protection domain your credentials are supposed to travel with you • Vendors should enable integration of protection domains

19. The J2EE Security Model • Access control based on identity and role • Possible to restrict access to certain identities only • Possible to restrict access to certain roles (basically groups) only • On a per beans or per method basis

20. The J2EE Security Model • In newer J2EE Versions (1.3+) it gets more flexible with JAAS extensions: • Can have your own credentials • Can “batch” credentials (Identities) together • To a large extent you can have your own security model

21. Architecture Blueprint: how it fits all together

22. What works well? • The Java Pet Shop

23. What works well? • The Java Pet Shop • Typical Internet shopping application • Catalog, search, shopping basket • Uses the mainstream features: Servlets, JSP, Session EJB, Entity EJBs • If you have questions about J2EE most of them are answered in the code! A very valuable resource for understanding how the nitty-gritty J2EE details work. • Newest version even contains Webservices examples! • So can we do Amazon now?

24. So can we do Amazon now?What is missing in the example? • How does the checkout work? • How does the user register a profile (and possibly verify the mail address)? • How do we do offline credit card checks? • How do we do mail notices (CC billed, item shipped) • How do we do any kind of workflow, batch job, mail processing … • Lets look at a few problems and issues …

25. J2EE Issues • Can you keep track of all the APIs and the continuous revisions that go into J2EE? • This is a serious issue. It is simply impossible to track all the new stuff that just got added into J2EE 1.4 … we’re still trying to digest J2EE 1.3! • If this goes at the same pace this it will ultimately harm the platform: • Your have to keep up with the platform • Vendors have very short release cycles • No long-term stable platform • What was OK yesterday is a bug today! • You may have to adapt your application to newer platform releases

26. J2EE Issues • Programming models do not match: • Servlets have to be reentrant (this is more than thread safe!) • Any number of threads can run concurrently the same method in the same Servlet even for the same user session! • No thread-safety built in, e. g. it is possible to kill the Session object by doing non-stable operations on it • You are on your own for synchronizing access to shared objects • EJBs are guaranteed single thread execution • All requests run within different instances of an EJB • For stateful Session beans this implies synchronized access for concurrent requests • You cannot have threads! • This mismatch has shown to be a massive challenge for a lot of developers!

27. J2EE Issues • How do you do batch processing or cron jobs? • EJB 2.1 knows a timer service • A bean can register a timer so that it gets called again later • But how does it get called initially to set the timer? • Unusable for timed batch processing! • Potentially useful for workflow oriented processing • It is not clear how queued timers survive a container restart

28. J2EE Issues • Could our pet shop really use entity beans for persistence? • What about this: • get all bills that have not yet been paid and are 30 days overdue • get all deals that should be billed tomorrow • Cannot! • EJB QL has no support for any date data type! • For Enterprise ( as in Java 2 Enterprise Edition) systems plainly unusable! • Will most probably be replaced by Java Data Objects JDO • We need serious performance, good queries (joins!) and support for data types that store dates and money values!

29. J2EE Issues • How do you run multiple parallel queries? • How do you run queries in the background? • The simple request/response model has serious limitations: user is blocked until the answer returns! • Threads are not allowed in the EJB container and would only solve the parallel queries problem. • Parallel queries could (theoretically be done in a JCA Connector) • Only way to do queries in the background would be an application, thus having a fat client that runs multiple threads and issues queries in the background. • Wasn’t that want we wanted to get rid off in the first place?

30. J2EE Issues • Message-driven beans have some particularities: • Messages can get lost: • Assume the called Session EJB throws an exception! • The message gets delivered multiple times, but fails each time! • JMS gives up: behavior undefined! • There is no user associated with requests in MDB: • In an MDB there is only a role (assigned in deployment descriptor) • No way to assign a user principal in any way! • You can run into race conditions: messages overtake each other! • MDB pool means messages get processed in parallel • Requires messages to be truly independent of each other • Cannot batch messages together into one transaction

31. J2EE Issues • Identity propagation is not really the J2EE-way of doing things … • All sorts of pooling results into anonymization of requests • Scalability built on pooling (e. g. JDBC Connection Pools) • If you need to login with the users ID into a backend system, then you are on your own! • You will end up either re-implementing access control logic in your J2EE container again or hampering your performance (no connection sharing) • This is not only a J2EE issue! To ease integration we need protocols that allow for user context switches, i. e. login with a(highly privileged) system ID and the possibility to switch context to certain user ID (like UNIX “su”).

32. Identitiy Propagation Problem • Pooling looses IDs Pooling /ID Mapping

33. J2EE Issues • RMI! • RMI is a plain nightmare! • Supports polymorphism: no clear interfaces! • Lacks load-balancing and fail-over functionality • Network class-loading means you have no real control over what runs in your system! • Because of RMI there are client stubs! If you change an EJBs deployment descriptor, the client stubs will potentially change! • Nightmare in a large-scale enterprise environment! • How do you reuse your EJBs from non-Java environments? (Forget about IIOP-RMI it is just is not an option! Try!) • Why did Sun not take CORBA?CORBA has NONE of these problems!

34. J2EE Issues • Webservices can be a security problem! • You potentially run a peer protocol (SOAP) through your company firewall! • The big plus “gets through every firewall” is a nightmare for security people: you can get any kind of stupid application interaction through the firewall without any control whatsoever! • God have mercy with the poor souls that implement some kind of “file fetch” service and “request routing”!

35. J2EE Issues • The J2EE role ”Deployer” • According to the specification the Deployer will take your beans and customize them (change the deployment descriptor) according to the needs of the deployment environment • The deployment descriptor defines a lot of the behavior of your EJB on an architectural level: • Transaction model • Security requirements and roles • Clustering and fail-over behavior • This is just not feasible! There are very few things that you can actually tune in an deployment environment, but even these parameters require massive J2EE knowhow in order not to break the system.

36. Now what works well? • Servlets/JSP • Huge benefit from the memory managed environment • Huge benefit from the crash resistance of the web container • Huge benefit from rich APIs to access DBs and all other sorts of backend systems • Rather performant … sometimes even amazingly performant … • Easy to scale • Proven and stable environment: big time spec revisions are over (and it did not start from zero!)

37. Now what works well? • Session EJBs (stateful and stateless) • Mostly to isolate business code from your Servlets/JSPs • Hot deployment helps a lot in development • Scarce use of stateful Session EJBs does not cause any problems • Keep state information as small as possible • Keep state as close to the source as possible • Actively manage the life-cycle: call remove when you know you’re done!

38. Alternatives? • Mixed architecture: • Webcontainer a la J2EE • Synchronous: CORBA based backend (all the ORB features you probably need are built into J2EE1.3!) • Asynchronous: JMS (or some other MOM middleware, or CORBA) • You will get all the benefits on the Web tier • You get all the possibilities on the “Enterprise” tier • POA dispatching for imitating Session EJBs (stateful and stateless) is trivial • Use LDAP-based JNDI for federated namespaces and easy discovery!

39. Conclusion • The first generation Java Server functionality is rather mature! • Good implementations are available and broad tool support (especially for Webservices) is showing up. • The Enterprise tier is still weak, it shows in the onging revisions and additions to the standard. We still need some major improvements! • Some stuff should plainly be removed: RMI, Entity EJBs • There are goods implementations out there that try to manage the shortcomings. • J2EE offers a big tool chest if you are willing to actually use it!

40. Thanks a lot for your attention!http://www.zuehlke.com/