J2EE Connectors and Large Scale System Design
The morning kicked off with an extensive discussion on J2EE Connectors and the benefits they offer in integrating with legacy systems. Connectors are Java adapters which your J2EE applications call to connect with back-end applications. The technical value of connectors are that they allow you to leverage various container services such as J2EE-EIS (Enterprise Information System) transaction integration, J2EE-EIS security, and J2EE-EIS connection pooling. With J2EE-EIS transaction integration, you can start a transaction in your J2EE system and finish it in the EIS system because the transaction context is propagated through the connector; in this way, the EIS becomes a transactional resource. The connector architecture defines a transaction contract between an application server, a resource adapter, and the underlying resource manager. The client controls the transaction using The Java Transaction API (JTA), or declarative, container-managed transactions in which the container handles transaction context propagation from J2EE to EIS for you.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Towards noon, discussion gradually progressed into Large-Scale System Design. Large systems need to be Reliable, Available, and Serviceable (RAS). Clustering is a technique that enables reliability, and availability. You can cluster just about anything including your app server, databases, operating systems, and networking infrastructures. Storage Area Networks (SANs) combine LAN networking models to mass storage devices, allowing clients to view an entire storage infrastructure as a single logical drive. Highly available networks contain features such as redundant gateway routers running the Hot Standby Routing Protocol (HSRP), redundant links to different ISPs running the Border Gateway Protocol (BGP) having different Internet backbones, and redundant and failover-capable firewalls. Application servers can support the clustering of JNDI servers, HttpSession objects, EJBs, and JMS Destination and ConnectionFactory objects. The WebLogic Server was used as an example of how the clustering of these features is supported. In-Memory Replication allows for the replication of HttpSession objects and stateful session EJBs. Proxy servers and 'in-cluster routing' were looked at as methodologies for directing incoming requests to the appropriate server.
A Look at Web Architectures
This unit served as both a review and comparative study of various web architectures. Several approaches were looked at that progressively became better in terms of decoupling the presentation layer from application logic. Some of the design paradigms we progressively looked at were: 1) the 'Just Servlets' approach, 2) Model 1 (just JSPs), 3) Model 1+ (just JSP + Beans), 4) JSP + taglibs 4), Model 2 (JSP + Servlets), 5) Model-View (JSP + Servlets + Beans), 6) Model-View-Controller (Central Dispatching).
The main problem with the 'Just Servlets' approach is the fact that Java code has to generate all the html through 'out.println()' statements. By tightly coupling presentation logic and the view, roles on the development team also become tightly 'coupled' as programmers now have to maintain html and debugging becomes a real headache. With the 'Just Servlets' approach, it is difficult to do any kind of major overhaul in terms of redesigning the look and feel of your view. The good thing about this approach is that if you have a lot of small snippets of html, you can store them in a DB, and offer a more flexible look and feel. If your application is extremely dynamic, the 'Just Servlets' approach may be a feasible option.
The Model 1 approach is useful mainly for rapid prototyping and when maintenence is not a priority; however, as the amount of Java code embedded inside your HTML increases, maintenence eventually does become an issue. In the Model 1+ approach (JSPs + JavaBeans), Java code is encapsulated inside regular Javabeans which are loaded by the HTML. The JSP now only embeds Java for presentation logic while all data access Java code is left to the Javabean. The design issue that arises with the Model 1+ approach is the specificity of data returned by the Javabean: a page may only need specific data and doesn't require the entire contents of a bean to be loaded. 'Customizing' the beans in this sense may require additional Java code in your JSPs which defeats the original purpose of decoupling HTML from Java.
Using JSPs with tag libraries is another way to remove Java code from your HTML. Taglibs are custom HTML tags which are implemented as Java classes and processed by the JSP Server. There are special styles of taglibs that encapsulate different functionality that may be needed by your JSP page. Application Logic taglibs contain database access code, Presentation Layout taglibs contain conditionals and loops for rendering complicated HTML, and HTML taglibs (Quidgets) which output snippets of HTML. There are also combination taglibs of the preceding.
In the Model 2 approach, a servlet receives an HTTP request from a client, queries a DB and populates a JavaBean. The JSP displays the bean's data and all subsequent updates made to the data by the client are sent to the servlet which updates the database with the changes. In the Model-View paradigm, a JSP receives an HTTP request from a client and instantiates a JavaBean which populates itself from the DB; however, in this case, the servlet only acts as an event handler for updates. The Model-View architecture represents a more efficient decoupling of the presentation logic from application logic, combining the strengths of the 'JSP + Bean' approach with the 'JSP + Servlet' approach. In the Model-View architecture, the JSP now truly represents the view, with the Bean acting as a bridge between the View and the Model.
The main problem with the Model-View approach is the hardcoding of URLs (if there are multiple use cases) in the Servlet event handler. The Model-View-Controller (MVC) architecture solves this problem by delegating the management of all use-cases to a separate 'controller' servlet. The MVC architecture not only manages the navigation of a site, but also enables additional technologies and features such as Bound Objects, Security, Caching, Multi-Frame Management, Parameterized Pages, amongst others. Using Bound Objects, before the controller servlet dispatches to another servlet, it can extract the values from an array, bind them in a session or send them in the request object. For example, JSP1 may send two fields (a string and a float) for the purposes of creating an account. JSP2, on a subsequent request, may send five fields. The controller servlet can reflect on the request object containing the parameters and based on the number and type of the parameters, can create and dispatch a bound object to the appropriate servlet.
There was no formal ceremony marking the completion of EJB For Architects, which seemed to be in accordance with the informal, interactive nature of the course. No podium. No hat toss. No valedictorian speech. There was however, modest applause from the class as each student received his certificate, marking a sort of J2EE, architectural 'coming of age' for all participants. What people gained from this course was not only an increased awareness of J2EE architectural issues, but real-world methodologies which could be used on their own projects at work. In a sense, EJB For Architects was a sort of a 'final frontier' of classroom learning about J2EE for many of the attendees. This knowledge was now going to be used to develop new enterprise applications and re-architect existing ones using the J2EE best practices, design patterns, and the multitude of APIs and server side technologies that were covered and discussed in class.