Sunday, April 17, 2005

[itsdifferent] Elements of J2EE

The matter of prime concern is the application architecture, which is to be evolved and is easily integrable with other applications in the enterprise. The risks involved in the architecture are identified by SAAM or ATAM at different phases of the iterative project lifecycle.

J2EE gives flexibility to the developer and designer to use it for different business needs. There is a chance for the architect to miss the big picture while taking care of the low level details. This is an attempt to formalize the architecting process where the architect constantly evaluates his architecture for important architectural attributes of the system like scalability, performance, usability etc.

Architecting Process Methodology Selection
Architecting Process Toolkit
Architect Corner (http://www.architectcorner.com) has this artifact, which has one view of different architecting processes and brief introduction on relevance of usage and how it can be used. Enterprise architecting differs from solution architecting and solution architecting differs from application architecting. The choice of methodology depends on the architecting process being applied. In any process, technology, data application and business, architectural views are created.

Formal Architectural Verification
SAAM and ATAM are the methods suggested to evaluate Architecture.

Application Architecture
Given that data, technology and business architectures are defined, the challenge is in coming up with application architecture, which is easily integrable with other applications in the enterprise. 
The following steps are the inverse of ATAM and SAAM techniques in getting the right architecture:

  • Looking at all use cases and grouping them into different functional modules.
  • Among the groups, identifying CRUD use cases and complex use cases.
  • Non-functional requirements of the system (concurrent users, transaction rate, total number of users etc.).
  • Reusability, Portability, Scalability, Usability and Extensibility requirements are the drivers for n-tier layered J2EE architecture.
  • System sizing templates help in identifying the hardware; the draft deployment diagram comes with different nodes for web server, application server, database, LDAP server and other external interfaces.
  • Connecting the nodes in the diagram will pop up questions related to communication/protocol/network bandwidth/firewall (DMZ/MZ).
  • Different functional groups of use cases with marking of CRUD/Complex will drive the business services.
  • Logging, Error/Exception Handling, External Interface Integration and other features drive the technology services.
  • Business Entities, Processes and Events are identified in each functional group. The functional façade (session bean) has the processes captured. Entities are modeled as Entity beans. Business rules/logic, specific to an entity, go in as a business method in an entity bean. Business rules, which involve multiple entities, are handled at session façade method/level, where façade method hands over DTO or a collection/hash map of DTOs.
  • Business events are handled using JMS\MOM. MDBs are used if the events are triggered by business rules involving Entity\Entities. External system event triggers are handled through messages messaging. Cron type processes or third party scheduler handles batch jobs scheduling events (Timer will be the answer for J2EE 1.4).
  • Web layer typically has a MVC framework like Struts, JATO, XSLT/XML, etc.
  • The requirements in the web layer are governed by user navigation, workflow, user interface input validation, handling complex user interface interaction, validation framework, default values, user error messages mapping to system error messages.
  • Personalization, User State Management, Session Tracking and Application State Management drives the web layer framework design.
  • Thick clients are driven by usability requirements and Swing is used instead of a browser. Swing provides separation of view and model in most of the reusable components in the API. The client side manager will be the controller to manage the state. The data is obtained from the Business Delegate, which invokes the EJB Service Facades.
  • Mobile Client requirements drive the usage of J2ME. 
  • Multiple Client side requirements can be satisfied by Servlet, XSL/XML framework which takes the agent type from the request and appropriately picks up the style sheets and the pagination requirements.
Architectural Evaluation
In the project lifecycle, SAAM or ATAM is used to identify the risks and the goodness of the architecture. In both these methods, a set of critical use cases is checked for the architectural attributes. 

Designing Business/Technology Services 
Biz/Tech. Service requirements are the most important criteria for design. But the architectural attributes in the system should be used as a checklist while designing them. Architectural concerns like Usability, Scalability, etc., are addressed using J2EE Design Guidelines and Design Patterns. A J2EE blueprint is a good place to check for similar situations or architectural requirements.

Developing Business/Technology Services
While developing Biz/Tech. Services, not only the design and architectural guidelines are to be followed but also programming best practices. Best practices for performance, scalability, and extensibility need to be considered during, Code reviews. (Eg.http://www.precisejava.com)

Handling Changing Business Rules and Business Logic
During the project lifecycle or after, the new or changed requirements demand change in business rules/logic in a business process. The usage of rules engine makes the clean separation. Rules engine repository can be accessed by the Process Façade and evaluated for business events and logic.
The other way is to use a policy pattern to model varying business rules and logic associated with a business process. The business services provide the placeholders for passing specific policies to handle a business process.

External Systems Integration 
Decisions specific to external systems integration like JNI, SOAP (Web Services) etc. should be evaluated against the architectural concerns. Enterprise Architecting process helps in looking at enterprise level business/data-tech. architecture. In a heterogeneous technology platform, the architectural guidelines and standards need to be addressed and they need to be in sync with the tech. vision of the enterprise. 

Enterprise Architecture Guidelines
While architecting an application, the following enterprise architectural concerns are important to be considered:
  • Enterprise Reporting
  • Enterprise Identity Management
  • Enterprise Content Management
  • Enterprise Document Management
  • Enterprise Data Management
"Think at Enterprise Level, Act at Application Level"
Most of the architecting methodologies have the similar message. Due to "Time to Market" and budgetary considerations local decisions are taken to optimize on goals like time and cost. Architect can add a great value in providing the visibility to the enterprise and save future costs in constant refactoring of the architecture or living up with a stove piped architecture.

Resources:


Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




Yahoo! Groups Links

No comments: