J2EE Architectural Guidelines

Transcription

1 J2EE Architectural Guidelines J2EE Architectural Guidelines... 1 Introduction... 1 Architecting Process Methodology Selection... 2 Architecting Process Toolkit... 2 Formal Architectural Verification... 2 Application Architecture... 2 Steps in getting right architecture... 2 Architectural Evaluation... 3 Designing Business/Technology Services... 4 Developing Business/Technology Services... 4 Handling Changing Business Rules and Business Logic... 4 External Systems Integration... 4 Enterprise Architecture Guidelines... 4 Think at Enterprise Level, Act at Application Level... 5 Resources:... 5 About the Author... 5 Introduction J2EE gives flexibility to the developer and designer to use it for different business needs. This is both a boon and bane. 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 architect constantly evaluates his architecture for important architectural attributes of the system like scalability, performance, usability etc.,

2 Architecting Process Methodology Selection Architecting Process Toolkit Architect Corner ( has this artifact, which has one view of different architecting processes and brief introduction on relevance of usage and how to use. Enterprise architecting is quite different from a solution architecting and solution architecting different to Application architecting. The choice of methodology depends on at level the architecting process is 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. Steps in getting right architecture Looking at all use cases and grouping them into different functional modules Among the groups identifying CRUD (Create/Read/Update/Delete) use cases and complex use cases. (Business logic and business rules) Non functional requirements of the system (concurrent users, transaction rate, total number of users, max/min size of the data transfers, response time expected for the complex use cases, response time for other use cases) Reusability, Portability, Scalability, Usability and Extensibility requirements are the drivers for n-tier layered J2EE architecture System sizing templates (from sun site etc.,) will help you identify the hardware and the draft deployment diagram comes up with different nodes for web server, application server, database, LDAP server (security requirements) and other external interfaces.

3 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, Persistence, Data Access, Data Transfer, Naming and Looking up, Concurrency, Transaction Management, internationalization, Authentication and Authorization 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 DTO s. Business Events are handled using JMS\MOM. MDB s are used if the events are triggered by business rules involving Entity\Entities. External system event triggers are handled through messages (publish\subscribe or point-to-point) 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 will be 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 and 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 At different phases of the iterative project lifecycle, one needs to use SAAM or ATAM to identify the risks and the goodness of the architecture. In both of these methods, a set of critical use cases are checked for the architectural attributes

4 Designing Business/Technology Services Biz/Technology 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, Portability, Extensibility, etc.,) are addressed using J2EE Design Guidelines and Design Patterns. J2EE Blue Prints is a good place to check for similar situations or architectural requirements Developing Business/Technology Services During developing Business/Technology 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. 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 system integration like JNI, SOAP (Web Services), RMI, MOM, JavaCOMBridges, Mainframe Connectors (CICS) should be evaluated against the architectural concerns. Enterprise Architecting process help in looking at enterprise level business/data/technology architecture. In a heterogeneous technology platform, the architectural guidelines and standards need to be addressed and to be in sync with the technology vision of the enterprise. Enterprise Architecture Guidelines While architecting an application, the following enterprise architectural concerns are important to be considered.

5 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: Architect Corner ( Precise Java ( J2EE Blueprints( ATAM ( About the Author Bhagvan Kommadi, Senior Technical Architect has 8 years of IT experience in diverse areas such as manufacturing, packaging, aerospace, supply chain planning product development, ebusiness and mobile commerce solutions with J2EE and.net Technologies. Extensive experience in managing people coupled with ability to blend business needs and technology capabilities into business solutions. Delivered several large-scale, mission-critical projects on time, using leading-edge technologies.