By Sayed, June 25th, 2008
* Single tier applications are easier to design. Single tier applications mix data, presentation, business logic altogether. It is easier design but workload distribution becomes difficult. Moreover, software maintenance becomes a big headache.
* Multi-tier applications can address these challenges. Here, the application, hence, the workload is divided into multiple modules - tiers. The presentation, data, business logic can be separated from each other. This provides well organized software development. The workload can be divided among several developers more effectively. Also, software maintenance becomes easier.
* Multitiered Applications Benefits:
o Availability: Accessible at all times - more accessible. Move parts of your applications into separate machines
o Extensibility: Ability to add more capabilities. Can add more capabilities without breaking the systems
o Scalability: Support more users: Add extra computing resources to each layer,
o Reliability: Maintain the accuracy and integrity of the data. Separating business logic from the rest of the applications, grouping operations into transactions
o Maintainability: Ability to update software code
* Design considerations for Distributed Applications/Systems
o Event handling: Generation and notification of distributed events
o Persistence: How distributed objects are stored and accessed
o Concurrency: Acquiring and releasing locks in distributed environments
o Security: Mechanisms to provide distributed authentications, authorization, encryption, and auditing
o Transactions:
o Language dependencies
o Platform dependencies : Provide seamless operations irrespective of the underlying OSs or processors
* Distributed object management issues:
o Create and delete distributed objects
o Reliable communications among distributed objects
o Provide interfaces for object mapping
o Activating distributed objects and binding them to names
o Advertising and accessing objects and services
* Design distributed systems:
o Partition the problem into modular
o Make the module small enough to be individually solvable
o Findout the application and communication layers/requirements
* Transaction Management
o
Core J2EE Component Technologies [ More in this category ] [Add your comments]
By Sayed, June 25th, 2008
Core J2EE Component Technologies
* J2EE Application Components: Web Components, Business Components
* Web-Component:
o Software entity hosted by a web-container on a J2EE Server
o Generate user interface for web-based applications
o Two Types: Servlets, JSPs
o Servlets: Process requests dynamically, format responses
o JSPs: How to process requests, and format responses
* Business Components: EJB Components or enterprise beans: Contain business logic of an enterprise application. Three types: Session Beans, Entity Beans, Message Beans
J2EE Services
* Distributed Communication Services:
o Distributed Communication Services provide J2EE components distributed communications capability and EIS access
o Web-container Service Components: JMS, JNDI, RMI-IIOP,CORBA and Java IDL
o Roughly: RMI-IIOP, CORBA and Java IDL: Applet and Application Container to Web-Container Communications
o JMS, JNDI: Between web-container and EJB container components. For application components not for users
o JNDI: Naming and directory services.
o CORBA: Objects to communicate regardless of their implementation language or the operating system
o Java IDL API enables J2EE applications to utilize CORBA functionality
* Other support technologies
o JDBC, Java Transaction API, Java Transaction Service, J2EE Connectors, JavaMail
o JDBC: Provides database access from Java.
o Latest JDBC: Provides connection pooling and distributed transaction support for the J2EE platform
o JDBC Drivers: Java, Partial Java, Java Native Interface (JNI)
o J2EE connector architecture provides supports to connect to EISs
o JavaMail API to handle mailing
J2EE Architecture: J2EE Design Patterns: Related Concepts [ More in this category ] [Add your comments]
By Sayed, June 25th, 2008
* Design Patterns
o What are design patterns? Design patterns are specific/(context-based) solutions/approaches to address specific problems/situations. Some problems are general/open problems and very common problems in a particular type of applications. Design patterns can be created to solve such problems in a specific context and that can be re-used every time that type of situations arise. Design patterns help designers to easily communicate their ideas (in a common concept).
o Benefits: Proven solution to a specific problem, saves time as you don't have to come up with an original solution each time you encounter a particular problem
o Design patterns can be applied at different levels of abstractions such as, Analysis, Architectural, Behavioral, Creational, Design, and Structural
o J2EE patterns are mostly for design and architecture purpose and for three architectural tiers: Presentation, Business, and Integration
* J2EE Applications: Client Tier (Clients for J2EE Applications): Design Issues
o J2EE supports many types of clients. Hence, you need to decide which types of clients you want to make use of. Also, based on the clients you need to decide how to solve a specific problem. Design patterns can be client-specific and problem-specific
o J2EE clients: laptops, desktops, palmtops, and cell phones.
o Connection Mechanisms (to J2EE Applications): an intranet, the Internet, a wireless network, a wired network, and a combination of wired and wireless networks
o Clients can be thin, server dependent, browser based, rich, and stand-alone
o Client design issues: Concerns: which types of clients to use, should more than one type of clients be supported?, network types to support, security considerations, platform considerations, and unreliability of networks
o Clients should: Connect to the network on an ad-hoc basis, transmit minimum amount of data, should consider situations when firewalls may block particular protocols, mobile clients should consider that they have small display screens and limited resources
o More design issues for J2EE clients: Logic for user interface presentation, validate user inputs, communicate with the server using a common protocol, maintain the conversational state
o Browser clients - design issues: can not function independently of the server, easy to design and implement, widely available, well-familiar to the users, provide limited functionality, can perform user input validation, servers can also do the validation, uses HTTP protocol, needs to maintain conversational states using Cookies, URL rewriting, or server side session
o Java clients - design issues:
o Client types: applications, applets, MIDlets are the Java client options
o Applications like usual desktop applications - can run offline, use JFC/Swing for user interface, provide richer user experience, more responsive than thin clients, use less bandwidth than browser clients, and can create fewer connections than browser clients
o Applets run mostly under browsers, use JFC/Swing for user interface
o MIDlets are mostly for small applications for cell phones, two-way pagers, and palmtops - use MIDP user interface APIs
o Java clients (Applications, applets, MIDlets) can handle most user input validation and hence, reduce network overhead, can connect to J2EE applications, directly to the web tier (using HTTP though face some complexity of translation), EJBs, EISs,
o Applets and applications can connect to EJBs directly,
o Java clients can access EIS tier directly (not recommended as it would bypass J2EE server and transaction management)
o Java clients have the facility to cache and manipulate large amounts of state in memory and manage session effectively
* Web Tier
o Servlets, and JSPs are web-tier component
o Manage the interaction between web-clients and the application's business logic.
o Output from this tier: mostly HTML and XML content
o Business logic can be implemented entirely here, though, enterprise beans are recommended
o Servlets should be used to: implement web-application logic, generate binary content, act as a web-tier controller
o JSPs are better suited to generate static HTML text
o JSP Purpose: produce structured textual content, generate XML messages, act as templates
o In JSP, custom tags are more desirable than scriptlets. Why? scriplets - not reusable, mix logic with content, make JSP pages difficult to read and update, errors can be difficult to interpret, difficult to test (including unit testing)
o Web-Tier Application Framework
+ Many web-tier application requirements are not met by the actual J2EE platform. A framework working on top of J2EE can meet these requirements such as, dispatching requests, invoking model methods, and compiling views.
+ Making use of existing ready-built and proven application framework is recommended than creating your own [it takes time and may be all your designs will not be the best]
+ Some frameworks: J2EE blueprints Web Application Framework, Apache Struts, JavaServer Faces
o Model View Controller (MVC)
+ Well-suited for interactive applications such as web-applications.
+ Divides applications into three modules - model, view, controller
+ model: data representation and business logic, view: data presentation and user input, controller: controls information flow
+ Benefits: separation of design and implement, decreased code duplication, centralized control
+ Servlets are ideal as controllers
+ Controllers receive all incoming client requests and direct them to the appropriate business logic component, after processing the requests, the controller selects the right view to return to the client.
o Model 1 and Model 2
+ Model 1: No controller, direct access to the JSP pages, decentralized application, simpler and hence suited for small and static applications
+ Model 2: Uses a controller, are favored as they are easy to maintain and extend, provide a single point for security and logging
* EJB Tier
o Hosts business logic of a J2EE application
o Provides system level services to the business components
o Developers can focus on business-logic problems
o J2EE platform handles the system related problems (complex many times) such as, state maintenance, transaction management, and availability to local and remote clients
o EJBs provide a good interface between presentation components in the web-tier and business data and systems in the EIS tier
o EJBs - entity, session, message driven
o EJBs can provide remote or local access by providing remote or local interfaces. EJBs are mostly designed for distributed environments and hence typically provide remote interfaces
o When to use entity beans: for business objects when it represents persistent data and requires persistent storage, multiple client access, data access in portable manners, server managed transaction handling is preferable
o Entity beans: Persistence can be managed by yourself or by the EJB container
o When to use Stateful Session-beans: for client centric business logic, business objects are short-lived, and non-persistent. Works for the client to maintain conversational state
o When to use Stateless session beans: Provide server side behavior, do not maintain states for a specific client, good for reusable service objects, to minimize resources and support a large number of clients, when the business object does not operate on instance variables.
* EIS Tier
o J2EE EIS technologies: J2EE Connectors to integrate J2EE applications with existing EISs using resource adapters - synchronous
o Java Message Service: To be used with enterprise messaging systems - asynchronous
o JDBC - integrates J2EE applications with relational database systems
o asynchronous: high quality and reliable message-delivery service, provide higher volume of messaging, more work for the developers
o synchronous - suitable to handle two or more EISs synchronously.
