Document Sample
J2EE Powered By Docstoc
					Java 2 Enterprise Edition (J2EE)
Overview And Experience Report

                       David Kamber
                       Zühlke Engineering AG
Who is your speaker?

           David Kamber
              - 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 in the early web days.

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

           „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
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
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
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
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!
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!
Enterprise Java Beans (Session EJB)

           Isolate your business logic (the mechanics) from its visual
           - 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)
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
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
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
                a EJB local interface should be called
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

          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
          - Nice interfaces that should hide the complexity
              • Webservice-enable any EJB without writing any line of code
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
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
The J2EE Security Model

           In newer J2EE Versions (1.3+) it gets more flexible with JAAS
           - Can have your own credentials
           - Can “batch” credentials (Identities) together
           - To a large extent you can have your own security model
Architecture Blueprint: how it fits all together
What works well?

           The Java Pet Shop
What works well?

           The Java Pet Shop
           - Typical Internet shopping application
           - Catalog, search, shopping basket
           - Uses the mainstream features: Servlets, JSP, Session EJB, Entity
           - 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?
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
           - 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 …
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
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
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
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!
                    a EJB QL has no support for any date data type!

              For Enterprise ( as in Java 2 Enterprise Edition) systems plainly
              - 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!
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.
                     a Wasn’t that want we wanted to get rid off in the first place?
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
                 • 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
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

              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”).
Identitiy Propagation Problem

Pooling looses IDs

                                 Pooling /
                                ID Mapping
J2EE Issues

              - 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!
                     a 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!
J2EE Issues

              Webservices can be a security problem!
              - You potentially run a peer protocol (SOAP) through your company
              - 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”!
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
Now what works well?

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

            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

            - 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

             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
             Some stuff should plainly be removed: RMI, Entity EJBs
             There are goods implementations out there that try to manage the

             J2EE offers a big tool chest if you are willing to actually use it!
Thanks a lot for your attention!

Shared By: