Y L N WA1280 Architecting O and Designing JavaN EE ApplicationsIO T A U L A V E
Web Age Solutions Inc. USA: 1-877-517-6540 Canada: 1-866-206-4644 Web: http://www.webagesolutions.com The following terms are trademarks of other companies: Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. IBM, WebSphere, DB2 and Tivoli are trademarks of the International Business Machines Corporation in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others. Y For customizations of this book or other sales inquiries, pleaseL contact us at: USA: 1-877-517-6540, email: [email protected] Canada: 1-866-206-4644 toll free, email: [email protected] O N Copyright © 2012 Web Age Solutions Inc. O This publication is protected by the copyright lawsI of Canada, United States and any other country where this book is sold. UnauthorizedT use of this material, including but not limited to, reproduction of the whole or partA of the content, re-sale or transmission through fax, photocopy or e-mail is prohibited.U To obtain authorization for any such activities, please write to: L Web Age Solutions Inc. A 439 University Ave V Suite 820 E Toronto Ontario, M5G 1Y8 Table of Contents Chapter 1 - Fundamental Architectural Concepts...... 13 1.1 What is Architecture?...... 13 1.2 Architecture vs. Design...... 14 1.3 Qualities of Service (QoS)...... 14 1.4 Common Mechanisms...... 15 1.5 Architectural Description...... 16 1.6 What Architecture is Not...... 16 1.7 The Need for Architecture...... 17 1.8 The Need for Architecture (Cont…)...... 17 1.9 The Architect...... 18 1.10 Roles of the Architect...... 19 1.11 Roles of the Architect (Cont…)...... 20 1.12 Skills of the Architect...... 20 Chapter 2 - System Architecture Development Guidelines...... 23 2.1 Security Risks...... Y 23 2.2 Security Risks (Cont...)...... L 23 2.3 Performance & Scalability Risks...... 24 2.4 Availability & Complexity Risks...... N 25 2.5 Compatibility & Control Risks...... O 26 2.6 Network Considerations...... 27 2.7 Latency and Bandwidth...... N 27 2.8 Minimize Number of Network Calls...... O 28 2.9 Minimize Network Call Size...... I 29 2.10 Firewall Navigation...... T 30 2.11 Firewall Navigation (Cont...)...... A 30 2.12 Firewall Navigation (Cont...)U...... 31 2.13 Secure Communication...... L 32 2.14 Distributed Object Technologies...... 33 2.15 Distributed Object TechnologiesA (Cont...)...... 34 2.16 Distributed Object VTechnologies (Cont...)...... 34 2.17 What is a Transaction?E ...... 35 2.18 Bank Example...... 36 2.19 Multiple Users Sharing Data...... 36 2.20 ACID Properties of Transactions...... 37 2.21 Architecture...... 37 2.22 Reference Architecture...... 38 2.23 Patterns...... 38 2.24 Development Methodologies...... 39 2.25 Open Standards...... 40 2.26 Frameworks...... 40 2.27 Summary...... 41 Chapter 3 - Quality of Service Requirements...... 43 3.1 What are Quality of Service Requirements?...... 43 3.2 Qualities of Service and Design...... 44 3.3 Quality of Service Inventory...... 44 3.4 Performance...... 45 3.5 Scalability...... 45 3.6 Reliability...... 46 3.7 Availability...... 46 3.8 Extensibility...... 47 3.9 Maintainability...... 48 3.10 Manageability...... 48 3.11 Security...... 49 3.12 Cultural Adaptability...... 49 3.13 Portability...... 50 3.14 Testability...... 50 3.15 Usability...... 51 3.16 Upgradeability...... 51 3.17 Recoverability...... 52 3.18 Prioritizing Quality of Service Requirements...... 52 3.19 Inspecting QoS Requirements for Trade-off Opportunities...... 53 3.20 Quality of Service Reviews...... Y 54 3.21 Summary...... L 54 Chapter 4 - Software Architecture Tiers...... N 57 4.1 System Architecture...... 57 4.2 Good Architecture...... O 58 4.3 Cave Drawings to Modern Day...... N 58 4.4 Information Systems Evolution...... O 59 4.5 Continued Evolution...... I 59 4.6 Present Day...... T 60 4.7 Client-Server Computing...... 60 4.8 Client-Server Pros/Cons...... A 61 4.9 Client-Server Example...... U 62 4.10 Tiered Architectures...... L 62 4.11 Single-tier ArchitectureA...... 63 4.12 Single-tier Pros/ConsV...... 63 4.13 Single-tier ExampleE ...... 64 4.14 Two-tier Architecture...... 64 4.15 Two-tier Pros/Cons...... 65 4.16 Two-tier Example...... 65 4.17 Three-tier Architecture...... 66 4.18 Three-tier Pros/Cons...... 67 4.19 Three-tier Example...... 67 4.20 N-Tier Architecture...... 68 4.21 N-Tier Pros/Cons...... 69 4.22 N-Tier Example...... 69 4.23 Summary...... 70 Chapter 5 - Managing Client Tier Considerations...... 71 5.1 Understand client-tier concerns...... 71 5.2 Types of Clients...... 72 5.3 JEE Client Responsibilities...... 72 5.4 Presenting the user interface...... 73 5.5 Validating user inputs...... 73 5.6 Communicating with the server...... 74 5.7 Managing conversational state...... 74 5.8 Understand Client-Tier Security...... 75 5.9 Client-Tier Security (continued)...... 75 5.10 Client-Tier Security (continued)...... 76 5.11 Client-Tier Security (continued)...... 76 5.12 Client-Tier Security (continued)...... 76 5.13 Client-Tier Security (continued)...... 77 5.14 Client-Tier Security (continued)...... 77 5.15 Compare/contrast user interface devices...... 78 5.16 Compare/contrast user interface devices...... 78 5.17 Application of reuse to the client tier...... 79 5.18 Strategies for deploying Java desktop applications...... 79 5.19 Strategies – continued...... 80 5.20 Strategies – continued...... Y 80 5.21 Summary...... L 81 Chapter 6 - JEE Technology Servers...... N 83 6.1 Server Types in JEE...... 83 6.2 JEE Servers...... O 84 6.3 JEE Servers (Cont…)...... N 85 6.4 JEE Containers...... O 85 6.5 Enterprise Information Systems...... I 86 6.6 ERP Systems...... T 87 6.7 Mainframe Transaction Processing Systems...... 87 6.8 Relational and Legacy Databases...... A 88 6.9 Legacy Integration...... U 88 6.10 Selecting a JEE Server...... L 89 6.11 Selecting a JEE ServerA (Cont…)...... 90 6.12 Selecting a JEE ServerV (Cont…)...... 91 6.13 Selecting a JEEE Server (Cont…)...... 91 6.14 Selecting a JEE Server (Cont…)...... 92 6.15 Selecting a JEE Server (Cont…)...... 93 6.16 Selecting a JEE Server (Cont…)...... 93 6.17 Selecting a JEE Server (Cont…)...... 94 6.18 Selecting a JEE Server (Cont…)...... 95 6.19 Selecting a JEE Server (Cont…)...... 96 6.20 Selecting a JEE Server (Cont…)...... 96 6.21 Selecting a JEE Server (Cont…)...... 97 6.22 Selecting a JEE Server (Cont…)...... 98 6.23 Packaging and Deployment Definitions...... 99 6.24 Roles and Responsibilities...... 99 6.25 EJB Modules...... 100 6.26 EJB Module Packaging...... 101 6.27 EJB Module Recommendations...... 102 6.28 Web Modules...... 103 6.29 Web Module Recommendations...... 104 6.30 Deployment Descriptors...... 104 6.31 Deployment Descriptors (Cont…)...... 105 6.32 Summary...... 106 Chapter 7 - JEE Technologies...... 107 7.1 Servlets...... 107 7.2 Servlets do the following...... 108 7.3 The Web Container...... 108 7.4 Servlet API...... 109 7.5 Session Management...... 110 7.6 Servlet Thread Issues...... 110 7.7 JSP (Java Server Pages)...... 110 7.8 How JSPs Work...... 111 7.9 JSP Elements...... 112 7.10 Using JavaBeans in JSP...... 113 7.11 Custom Tags...... Y 114 7.12 Filters...... L 115 7.13 Filters and the Processing Pipeline...... N 116 7.14 Filter API...... 117 7.15 Uses for Filters...... O 117 7.16 Event Listeners...... N 118 7.17 Event Listeners (Cont…)...... O 119 7.18 What are EJBs?...... I 120 7.19 Main Characteristics of EJBs...... T 121 7.20 EJB Architecture Components...... 121 7.21 EJB Container...... A 122 7.22 EJB Container...... U 123 7.23 EJB Container – PersistenceL...... 123 7.24 EJB Container – TransactionsA ...... 124 7.25 Enterprise Java BeansV...... 124 7.26 Session Beans...... E 125 7.27 Entity Beans...... 126 7.28 Message-Driven Beans...... 126 7.29 EJB Classes and Interfaces...... 127 7.30 EJB Container – Relationships...... 128 7.31 Remote vs. Local EJBs...... 128 7.32 Web Services...... 128 7.33 Web Service Implementation in JEE...... 129 7.34 Web Service Deployment in JEE...... 130 7.35 JCA (JEE Connector Architecture)...... 130 7.36 JCA (JEE Connector Architecture)...... 131 7.37 Application Level Contract ...... 132 7.38 System Level Contracts...... 132 7.39 Summary...... 133 Chapter 8 - JEE Technology Choices...... 135 8.1 Client Session State...... 135 8.2 Client Managed State...... 136 8.3 Web Tier Managed State...... 136 8.4 EJB Tier Managed State...... 137 8.5 Business Objects...... 138 8.6 When to Use EJB...... 139 8.7 When to Use Entity Beans...... 140 8.8 When to Use Entity Beans...... 141 8.9 CMP vs. BMP...... 141 8.10 Client Types...... 142 8.11 Web Browser Clients...... 143 8.12 Java Clients...... 144 8.13 Model View Controller...... 145 8.14 Model View Controller in the Web-Tier...... 145 8.15 Model View Controller in the Web-Tier (Cont…)...... 146 8.16 Web Application Frameworks...... 146 8.17 Web Presentation Layout...... Y 147 8.18 Web Presentation Layout (Cont…)...... L 148 8.19 Java Presentation Layout...... N 148 8.20 Message-Oriented Middleware and JMS...... 149 8.21 Messaging Domains...... O 150 8.22 Messaging Domains (Cont…)...... N 151 8.23 Characteristics of MOM...... O 151 8.24 Advantages of Asynchronous CommunicationI (e.g. MOM)...... 152 8.25 Advantages of Synchronous CommunicationT (e.g. RMI/IIOP)...... 153 8.26 Summary...... 154 Chapter 9 - Java Connector ArchitectureA (JCA)...... 155 9.1 JCA Overview...... U 155 9.2 Resource Adapter...... L 156 9.3 System Contracts...... A 156 9.4 Outbound ContractsV...... 157 9.5 Inbound ContractsE...... 157 9.6 Lifecycle Contracts...... 157 9.7 Common Client Interface (CCI)...... 157 9.8 Advantages of JCA...... 158 9.9 Resource Adapter Packaging...... 158 9.10 Connection Management...... 159 9.11 Connection Management…...... 159 9.12 Connection Management...... 160 9.13 Transaction Management...... 161 9.14 Transaction Scenario...... 161 9.15 Client Interaction...... 162 9.16 Summary...... 163 Chapter 10 - SOA Concepts...... 165 10.1 Anatomy of an Enterprise...... 165 10.2 IT Nightmare...... 166 10.3 Understanding by Analogy...... 166 10.4 Service Oriented Architecture...... 167 10.5 Componentization and Reuse...... 167 10.6 Benefits of Service Orientation...... 168 10.7 Defining SOA...... 169 10.8 Aligning the Enterprise...... 169 10.9 What’s a Service?...... 170 10.10 Service Actors...... 171 10.11 Service Layering...... 171 10.12 Is SOA a Flash in the Pan?...... 172 10.13 Service Orienting the Enterprise...... 172 10.14 Service Oriented Thinking...... 173 10.15 Summary...... 173 Chapter 11 - Introduction to JAX-WS...... 175 11.1 What is JAX-WS?...... 175 11.2 Advantages of JAX-WS...... 176 11.3 Why Do We Need a Programming Model?...... Y 176 11.4 Basic Java to WSDL Mapping...... L 177 11.5 Developing a Service Provider...... N 178 11.6 The Service Implementation Class...... 179 11.7 The Service Endpoint Interface (SEI)...... O 180 11.8 The Service Endpoint Interface (SEI)...... N 180 11.9 Service Implementation Options...... O 181 11.10 Developing a Consumer...... I 183 11.11 Static Client Development...... T 183 11.12 The Service Class...... 184 11.13 The Service Class...... A 185 11.14 The BindingProvider InterfaceU...... 186 11.15 The BindingProvider InterfaceL ...... 187 11.16 The BindingProviderA Interface...... 187 11.17 Summary...... V 188 Chapter 12 - JEE SecurityE...... 191 12.1 JEE Authentication mechanisms...... 191 12.2 Basic authentication...... 192 12.3 Form-based authentication...... 192 12.4 Form-based authentication...... 192 12.5 Client certificate authentication...... 193 12.6 JEE Authorization...... 194 12.7 Declarative security on Web Resources...... 194 12.8 Declarative security on Web Resources...... 195 12.9 Programmatic security on Web Resources...... 195 12.10 Security role reference...... 196 12.11 Defining security roles using annotations...... 196 12.12 Delegation...... 197 12.13 Delegation...... 197 12.14 Declarative security on EJB Resources...... 198 12.15 Protecting beans using annotations...... 198 12.16 Protecting beans using the deployment descriptor...... 199 12.17 Programmatic security on EJB Application...... 200 12.18 Programmatic security on EJB Application...... 200 12.19 Delegation...... 201 12.20 Delegation...... 201 12.21 Summary...... 202 Chapter 13 - Web Services Security (WS-Security)...... 203 13.1 The Challenges...... 203 13.2 Public Key Infrastructure (PKI)...... 203 13.3 Digital Signature...... 204 13.4 Certificates...... 204 13.5 Overview of Web Services Security...... 205 13.6 SOAP Message Security...... 206 13.7 Message Integrity...... 207 13.8 Message Confidentiality...... 208 13.9 Message Confidentiality...... Y 209 13.10 Symmetric Encryption Example...... L 210 13.11 Authentication Using Identity Token...... N 210 13.12 Authentication...... 212 13.13 Authentication...... O 212 13.14 Transport Level Security...... N 213 13.15 Audit Tracking...... O 214 13.16 Audit Tracking...... I 214 13.17 Identity Assertion Using SAML...... T 215 13.18 SAML SOAP Example...... 216 Chapter 14 - Prototypes...... A 217 14.1 What is a Prototype?...... U 217 14.2 Conceptual Prototypes...... L 218 14.3 Architectural PrototypesA...... 218 14.4 Advantages of PrototypingV ...... 219 14.5 Advantages of PrototypingE (Cont…)...... 219 14.6 Advantages of Prototyping (Cont…)...... 220 14.7 Advantages of Prototyping (Cont…)...... 221 14.8 Deciding Whether to Build a Prototype or Not...... 221 14.9 Prototypes and the #Software Development Lifecycle...... 222 14.10 Prototype Roles and Responsibilities...... 222 14.11 Throw-away vs. Evolutionary Prototypes...... 223 14.12 Spikes...... 223 14.13 Testing a Prototype...... 224 14.14 Summary...... 225 Chapter 15 - Describing and Evaluating Software Architecture...... 227 15.1 Architecture Description...... 227 15.2 Architectural Views...... 228 15.3 Architectural Views (Cont…)...... 228 15.4 Architectural Views (Cont…)...... 229 15.5 Architectural Views (Cont…)...... 229 15.6 Subsystems...... 230 15.7 Layers...... 230 15.8 Example: Subsystems with Layers...... 231 15.9 Components...... 232 15.10 Decomposing the System Into Components...... 233 15.11 Software Partitioning Strategies...... 233 15.12 Software Partitioning Strategies (Cont…)...... 234 15.13 Software Partitioning Strategies (Cont…)...... 234 15.14 Software Partitioning Strategies (Cont…)...... 235 15.15 Software Partitioning Strategies (Cont…)...... 236 15.16 Managing Dependencies...... 236 15.17 Managing Dependencies (Cont…)...... 237 15.18 Component Diagrams...... 238 15.19 Component Diagrams (Cont…)...... 239 15.20 Deployment Diagrams...... 239 15.21 Deployment Diagrams (Cont…)...... Y 240 15.22 Tiered Architectures...... L 240 15.23 Tiered Architectures (Cont…)...... N 241 15.24 Tiered Architectures (Cont…)...... 241 15.25 Tiered Architectures (Cont…)...... O 242 15.26 Managing Complexity...... N 243 15.27 Evaluating the Architecture...... O 244 15.28 Evaluating the Architecture (Cont…)...... I 244 15.29 Summary...... T 244 Chapter 16 - Data Transfer in Distributed Computing ...... 247 16.1 Data Transfer in Java Local ComputingA ...... 247 16.2 Data Transfer in Java DistributedU Computing...... 247 16.3 Comparing Data TransferL in Local and Distributed Computing...... 248 16.4 Comparing Data TransferA in Local and Distributed Computing (Cont…)...... 249 Chapter 17 - Transactions inV EJB...... 251 17.1 Need for TransactionsE ...... 251 17.2 Transactions...... 252 17.3 ACID Properties...... 252 17.4 Transaction Components...... 253 17.5 Distributed Transactions...... 254 17.6 Distributed Transaction Components - Two Phase Commit...... 254 17.7 Java Transaction API (JTA)...... 255 17.8 Object Transaction...... 255 17.9 EJB Transaction Basics...... 256 17.10 Transaction Propagation...... 256 17.11 Transaction Outcome...... 257 17.12 Container Managed Transaction...... 257 17.13 Transaction Attributes...... 258 17.14 Container Managed Transaction Settings...... 259 17.15 Interacting with Container Managed Transactions...... 260 17.16 Container Managed Transaction – Example...... 260 17.17 Transaction Attributes Support...... 261 17.18 Bean Managed Transaction...... 262 17.19 Using the JTA API...... 263 17.20 Obtaining the UserTransaction...... 264 17.21 Fine Points of Bean Managed Transaction...... 264 17.22 Client Managed Transaction...... 265 17.23 Transaction Isolation...... 266 17.24 Summary...... 267 Chapter 18 - Business and Integration Tier Patterns...... 269 18.1 Business Delegate Pattern...... 269 18.2 How it works...... 269 18.3 Data Transfer Object Pattern...... 270 18.4 DTO Example (Output)...... 270 18.5 DTO Example (Input)...... 271 18.6 Role of DTO in MVC...... 271 18.7 Access Beans...... Y 272 18.8 Types of Access Beans...... L 272 18.9 Data Class Access Bean...... N 273 18.10 Data Class Programming Model...... 274 18.11 Access Bean Constructor...... O 274 18.12 Generating Access Beans...... N 275 18.13 Generating a Data Class...... O 275 18.14 Generating an EJB Factory...... I 276 18.15 Using EJB Factory and Data ClassT...... 276 18.16 Deleting the Access Bean...... 277 18.17 Value Object Pattern...... A 277 18.18 Multiple Value Objects...... U 277 18.19 Best Practice – derive EJBL from the Value Object...... 277 18.20 Composite Entity PatternA ...... 278 18.21 Composite Entity VPattern...... 278 18.22 An example...... E 279 18.23 Class Diagram...... 280 18.24 How the client interacts...... 280 18.25 Value Object Assembler...... 281 18.26 Value List Handler...... 281 18.27 How does it work?...... 281 18.28 How does it work...... 282 18.29 Design Considerations...... 284 18.30 Design Considerations...... 284 18.31 Service Locator...... 284 18.32 Data Access Object (DAO)...... 285 18.33 DAO Implementation Guidelines...... 285 18.34 Service Activator...... 286 18.35 MDB- Integrating JMS and EJB...... 286 18.36 Message-Driven Beans Are Different From Other EJBs...... 286 18.37 Message-Driven Beans are Stateless...... 287 18.38 Message-Driven Bean Interfaces...... 287 18.39 Example: Message Counter...... 287 18.40 Class MessageCounter...... 288 18.41 Class MessageCounter…...... 288 18.42 Class MessageCounter…...... 289 18.43 Processing the Message...... 289 18.44 Deployment Descriptor Entry...... 290 18.45 Summary...... 291
Y L N O N IO T A U L A V E Chapter 1 - Fundamental Architectural Concepts
Objectives Key objectives of this chapter: What is Architecture? Architecture vs. Design Qualities of Service Common Mechanisms Architectural Description & Views What Architecture is Not Y The Need for Architecture L The Architect, Roles and Skills N O N 1.1 What is Architecture?O I IEEE 1471 Definition: T ◊ Architecture is the fundamentalA organization of a system embodied in its components, their relationshipsU to each other, and to the environment and the principlesL guiding its design and evolution A What is Architecture? V E There are many definitions of Architecture in the Information Technology industry. The Institute of Electrical and Electronic Engineers (IEEE) published the IEEE 1471 standard (recommended practice) regarding Software Architecture in October 2000. They provide one of the newer definitions of architecture. The Rational Unified Process (RUP) provides the following definition: “Software architecture encompasses the significant decisions about the organization of a software system. The selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements. The composition of the structural and behavioral elements into progressively larger subsystems, the architectural style that guides this organization, these elements, and their interfaces, their collaborations, and their composition. Software architecture is concerned not only with structure and behavior but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic issues.” Chapter 1 - Fundamental Architectural Concepts
1.2 Architecture vs. Design
Architecture is a higher level of design and deals with:
◊ Subsystems & layers
◊ Components
◊ Interfaces
◊ Qualities of service (architectural attributes)
◊ Common mechanisms
◊ Main uses cases, key scenarios (main control flows)
◊ Architectural/design patterns (e.g. MVC)
◊ Risks Y L ◊ Process N ◊ Infrastructure O Design deals with classes, methods and Ndetailed implementation decisions. IO T Architecture vs. Design A In large-scale applications, the architecture Uneeds to be defined at a high-level so that architects find it it easier to see how the entire system fitsL together. If the architecture becomes too detailed, it is very difficult to reason about the system asA a whole. The architect will not be able to see the “forest for the trees”. V Architects are still concerned withE some implementation mechanisms such as data persistence, transactions, error handling and integration with legacy/purchased components. These aspects require a consistent approach to ensure architectural goals.
1.3 Qualities of Service (QoS)
Also known as architectural attributes Examples include:
14 Chapter 1 - Fundamental Architectural Concepts
◊ Security ◊ Availability
◊ Maintainability ◊ Scalability
◊ Extensibility ◊ Reliability
◊ Manageability ◊ Testability
◊ Usability ◊ Recoverability
◊ Performance
Qualities of Service (QoS)
Qualities of service (QoS) or architectural attributes are of utmost importance to the architecture. Often the architect must make tradeoffs between the attributes in order to meet architectural and business goals. For example, if maintainability is one of the most important qualities, this may have a negative impact on performance (due to additional layers that are introduced, for example).Y L Architecture focuses more on the qualities of service (also known as non-functional requirements) whereas design focuses more on functional requirements. N O N 1.4 Common MechanismsO I Architecture defines the mechanismsT to solve common problems in a consistent manner A Example: persistence, transactionU management, security, distribution, and communication L A Mechanisms are chosenV to satisfy the QoS requirements such as security, availability, performance,E etc Designers follow these mechanisms when producing detailed designs and can be less concerned with QoS requirements
Common Mechanisms
The architecture for an application defines mechanisms to solve common challenges such as data persistence, transaction management, security, distribution, communication, logging, error handling, etc., in a consistent way. It is important for the architecture team to carefully consider the main use cases, scenarios and main flows through the system in order to determine the best way to handle all of these common challenges. If performance is the most important service requirement, this has implications for how data
15 Chapter 1 - Fundamental Architectural Concepts persistence, transaction management and distribution (to name a few) are handled throughout the entire application.
1.5 Architectural Description
An architectural description is a set of products and views that document the architecture. Views are implemented using UML diagrams. An architectural view is a representation of a system from a particular perspective. Each view addresses the concerns of a particular group of stakeholders.
Architectural Description Y L No one view can satisfy the needs of all the stakeholders for the system.N A view of this sort would be far to complex; hence, different views of the architecture are needed O for different stakeholders. N 1.6 What ArchitectureIO is Not Generally avoid duplicating informationT found in other sources such as requirements A Architecture description shouldU be kept at the appropriate level of detail: L A ◊ Include architecturallyV significant aspects ◊ Leave lower levelE details to design
◊ Leave low-level implementation details to design
What Architecture is Not
Architects must refrain from providing too much detail in the architecture. Often it is difficult to determine when architecture stops and design starts. This can vary by project but it is important to establish the definition of each at the start of the project. The architect may need to provide additional detail if the design team is less experienced. Architecturally significant aspects include those that affect the architecture and common mechanisms. For example, security, portability, distribution, persistence, etc.
16 Chapter 1 - Fundamental Architectural Concepts
1.7 The Need for Architecture
Architecture provides guidance to the development team designers It provides a design plan to help manage the complexity of the system It is a place to capture:
◊ Early design decisions
◊ Constraints on design and implementation
◊ Organizational structure for development team The creation of a well defined architecture up front makes the system more consistent and easier to design, develop and maintain Y The Need for Architecture L In large-scale systems, the presence of a good architectural representationN up front pays big dividends during the design, development, testing and maintenance stages. The architecture serves as a high- level vision of the system that stakeholders can use to give them Oguidance when making decisions at a lower level. N The need for architecture has grown significantly since Othe mid-1990’s. Large-scale, distributed, Internet-based applications require careful thinking aboutI how to handle scalability and other risks that were not an issue in pre-Internet systems. ApplicationsT can be successful at meeting all of the functional requirements yet still fail due to theirA inability to meet the non-functional (quality of service) requirements such as scalability and performance.U Often, a failure of this kind requires significant re- architecting, a process that is time-intensiveL and costly. Architecture helps to address the problemsA caused by lack of clarity/communication between different development teams, as well as changesV to software interfaces shared by the teams. For example, communication between teamsE is often difficult, especially if the teams are geographically separated. A well-defined, documented architecture serves as a blueprint for both teams and ensures the components built by both teams work well together. This is especially true in waterfall software development methodologies where integration of components is performed later in the project lifecycle.
1.8 The Need for Architecture (Cont…)
The architectural description is used during many phases of the application development lifecycle:
◊ Training
◊ Maintenance
17 Chapter 1 - Fundamental Architectural Concepts
◊ Testing
◊ Ensuring qualities of service (QoS)
◊ Verification of requirements
◊ Project management
◊ System operation
The Need for Architecture (Cont…)
Training: A well-documented architecture is essential for training new team members quickly. New members can get an idea of the big picture and where various, course-grained elements fit in without being overwhelmed with detail and complexity. Consider the alternative of having no documentation. The new member would need to derive an understanding from the code or verbally from people who may not have as much knowledge as they would like. Y Maintenance: The architecture allows developers to better understand ifL a potential change has an impact on other elements. A good architecture reduces the couplingN of elements and thus increases the likelihood that a change will not affect other elements. O Testing: The architecture documentation helps testers understand what elements require retesting when a change is made. A good architecture makes it less likely thatN unrelated elements will require retesting when a change is made. IO Ensuring Qualities of Service: In order to ensure theseT attributes are covered, it is important to consider them carefully during the initial architectureA of the system. Verification of Requirements: The architecturalU process often reveals issues with business requirements. L Project Management: The architectureA identifies what work needs to be performed, opportunities for parallel development and makes itV clear what items the various teams (development, testing, etc) need to focus their communication on.E It also identifies costs associated with various design options. System Operation: System administration personal will benefit from a high-level, big picture understanding of the architecture.
1.9 The Architect
An good architect is critical to the success of a large-scale project The architect creates a shared vision for the applicatio
◊ This is captured in the architectural description The vision considers the (potentially conflicting) interests of many
18 Chapter 1 - Fundamental Architectural Concepts
stakeholders The vision gives the development team and stakeholders an idea of what the final product will be and the effect it will have
The Architect
A poor architect or the lack of an architect will result in less consistency and will increase the risk of the project. The larger the project, the more this becomes an issue. The architect takes on several roles throughout the project lifecycle and has a broad range of skills and experience. Stakeholders address and understand business needs but these needs often conflict with technical needs. The architect must balance all of these needs, and document and communicate the decisions to the team and stakeholders. Y L 1.10 Roles of the ArchitectN Requirements O Technology risk assessment N Analysis of the problem domain IO T Overall design A Review and approval U L Roles of the Architect A Requirements: The architect is responsibleV for managing the quality of service (architectural attribute) requirements. Furthermore, theE architect must also understand the functional requirements very clearly to produce an architecture that supports them. The architect is often involved in requirements gathering efforts and meets with customers, marketing, and support teams. Technology risk assessment: The architect identifies the technical risks of the application and informs management and other stakeholders. He/she is responsible for reducing these risks as much as possible. Analysis of the problem domain: The architect breaks problems into their constituent pieces and creates solutions. Overall design: The architect is responsible for the overall structure of the application including the critical components, interfaces, policies, design guidelines and coding styles. Review and approval: The architect is responsible for review and approval of subsystem designs,
19 Chapter 1 - Fundamental Architectural Concepts interface design, documentation, and test reports.
1.11 Roles of the Architect (Cont…)
Mentoring Test support Implementation Team leadership Conduit to project management
Roles of the Architect (Cont…)
Mentoring: The architect is an excellent designer and developer and has manyY years of experience. The architect can mentor less experienced designers and developers duringL the detailed design and implementation phases. N Test support: The architect often assists during the test phase by O defining test scenarios (especially pertaining to the qualities of service), executing test scripts,N etc. Implementation: The architect may actually perform someO implementation tasks on smaller projects. This allows the architect to keep their development experienceI fresh, thus supporting their mentoring role. On large-scale projects, the architect should beT very careful not to let implementation tasks get in the way of architectural tasks. The architectureA is of more importance as most stakeholders are dependent on it. U Team leadership: The architect may haveL direct reports as part of the larger architecture team. They may also lead the development team.A Conduit to project managementV: The architect is often the one who translates technical matters to managers in a way that is understandableE to them. The architect knows what level of detail to provide. This includes discussions regarding costs for various design alternatives.
1.12 Skills of the Architect
Software design and development experience Team facilitation skills Communication skills Building consensus skills
20 Chapter 1 - Fundamental Architectural Concepts
Technical skills Domain knowledge Abstraction skills
Skills of the Architect
Software design and development experience: Detailed design and development experience in technically similar systems is crucial to producing a good architecture. Team facilitation skills: The architect leads the architecture team and potentially the development team. Sometimes there are disagreements between team members on which approach to take and the architect must be able to make fast, sound decisions. Communication skills: The architect is often found communicating to project stakeholders including managers, designers, developers, testers, and business users. They need the ability to communicate in both technical and non-technical styles and know when to use each style. Y Building consensus skills: The architect must be able to build consensusL among the various team members including developers, managers and business users. Often,N the architecture will be a result of trade offs that may leave some stakeholders less than satisfied as O their expectations were given lower priority in favor of higher priority requirements. N Technical skills: The architect must stay current with technology.O His/her skills must be broad to ensure that a good approach is taken from the start. AI detailed knowledge of all of these technologies is not possible but they need to know the pros and Tcons of any particular technology and match them to other issues such as project schedule, developerA skill levels and budget. Domain knowledge: Knowledge of the domainU is critical to creating an architecture that meets the business needs. The architect can acquireL this knowledge by working with analysts and business users, as well as by observing. A Abstraction skills: Architects mustV be able to resist the tendency to become overwhelmed with detail. They must be able to think at theE right level of abstraction for the problem at hand.
21 Y L N O N IO T A U L A V E Chapter 2 - System Architecture Development Guidelines
Objectives Key objectives of this chapter: Describe Key Risk Factors in Distributed Enterprise Systems and mitigation plans Describe Guidelines for Effective Network Communication Using Transactions to Control Shared Resources Controlling Costs Through Concept Reuse
2.1 Security Risks Y L Security is much more involved in distributedN enterprise systems ◊ Existing challenges are magnified and new O challenges are introduced Involves integration of different securityN mechanisms from disparate systems IO ◊ Increased risk of flaws in the overallT security model A Security Risks U L Historically, IT departments have hadA more control over computing environments and thus have been able to create a secure environmentV relatively easily. Physical security was often a large component of this. E Distributed enterprise systems that involve less-protected environments that are not under the control of the IT department make it much more important that tight security measures be taken for sensitive assets while less hampered access be given to other resources. Distributed systems often involve heterogeneous technologies that make security more difficult, complex and error-prone to integrate.
2.2 Security Risks (Cont...)
Malicious software (“malware”) Confidentiality Integrity of data Chapter 2 - System Architecture Development Guidelines
Authentication Authorization Denial of service attacks Theft of information Theft of resources
Security Risks (Cont...)
Malicious software is also known as “malware”. This includes viruses, worms, trojan horses, and malicious code downloaded from a remote site (perhaps delivered as: applets, ActiveX, Javascript, remotely loaded RMI classes, etc). A distributed system increases the technical problems with maintaining confidentiality of data. Information transmitted over the network may need to be encrypted, for example.Y Integrity of data is also of concern. That is, we often want the assuranceL that a message sent from a particular party was not modified in transit by a third party. N Authentication problems increase in a distributed system. We may O need to verify that a message sent from a particular party really was sent from that party and notN from another party masquerading as them. O Authorization is the process of determining what accessI should be permitted. Access control then implements the rules. This becomes more complexT in distributed systems with multiple nodes and varying technologies. A A denial of service attack is more likely in aU distributed system. This type of attack is often implemented by flooding servers with multiple,L repeated network requests in an attempt to hinder the servers’ ability to serve legitimate requests.A Theft of information is more likelyV in distributed systems as they are open to a larger number of machines and possibly to the Internet.E Theft of resources is another issue. Hackers could actually take control of a server and use it as a resource for their own gain. For example, hackers could take control of a mail server to send spam. This might be done surreptitiously.
2.3 Performance & Scalability Risks
Performance
◊ Bottlenecks: Bottleneck avoidance and detection
24 Chapter 2 - System Architecture Development Guidelines
High network latency, low network throughput
◊ System responsiveness: Ensuring performance QoS Scalability
◊ Potentially thousands of users
◊ Unpredictable loads
Performance & Scalability Risks
Bottlenecks are the slowest points in the system. A system could be composed of three servers, two with high-performance and one with low-performance but could operate as if they were all low- performance if all of the traffic is bottlenecking on the lower performing server.Y Bottlenecks can occur anywhere: the client machine, servers, network, routers,L etc. Bottlenecks can occur in both hardware and software. N Distributed systems inherently have more nodes and more complexity, making it more challenging to avoid significant bottlenecks in the initial design. This complexity O also makes it more difficult to detect bottlenecks that occur in production systems. There willN always be some bottlenecks but they should be minimized as much as possible. O Network latency is the delay between sending and receivingI data which increases as the amount of traffic on the network increases. Distributed systemsT tend to have many network accesses which makes bottlenecks resulting from network latency moreA likely. The extra complexity and heterogeneity of distributedU systems make it more difficult to guarantee system responsiveness (performance). ThisL is especially true when the Internet is involved. Performance QoS requirements shouldA be carefully managed so the requirement is actually achievable. An example performance requirementV could be: the system will respond to any request within 7 seconds, 80% of the time. ThisE leaves some room for Internet issues (20% of the time). This is measured at the firewall. Scalability is also an issue in distributed systems. In systems exposed to the Internet, you could potentially have thousands of users, at unpredictable times. This has led to the advent of several sophisticated load balancing and scalability techniques.
2.4 Availability & Complexity Risks
Availability
◊ Distributed systems often have multiple points of failure
25 Chapter 2 - System Architecture Development Guidelines
◊ Complex redundancy is required to provide high availability Complexity
◊ In order to cope with the additional risks, the system complexity increases
◊ This increases the risks of errors and makes it more difficult to maintain
Availability & Complexity Risks
Distributed enterprise systems typically have many nodes. The failure of any one of these nodes often renders the system unavailable. If the system must be highly available, redundant nodes are required which leads to more complexity.
2.5 Compatibility & Control RisksY L Compatibility N ◊ Multiple nodes magnifies issues with compatibility O of communication protocols, software and other featuresN ◊ E.g., browser support for HTTP, HTML,IO JavaScript ◊ E.g., version of the JRE Plug-inT in user browsers A Control U ◊ Distributed systems mayL have nodes that are not in your control ◊ E.g., customer firewallsA that disallow your communication protocols or V even HTTP tunnelingE ◊ E.g., users who have disabled cookie support in their browser
Compatibility & Control Risks
Distributed enterprise systems tend to have multiple, heterogeneous nodes running different versions of software. This can lead to compatibility issues in communication and messaging mechanisms, plug- ins, etc. For example, a web page may be built to work for a particular version of Internet Explorer and may not work correctly in other browsers or versions of Internet Explorer. Distributed systems that involve the Internet have nodes that are not in your control. These include customer/supplier browsers, networks, and firewalls, to name a few. The nodes of different customers/suppliers can be configured differently, thus resulting in different behavior for each customer/supplier. For example, one customer may have a sophisticated firewall that interrogates
26 Chapter 2 - System Architecture Development Guidelines outgoing messages and disallows HTTP tunneling. Another example is an email filter at a customer site that disallows certain types of emails based on content or size. A third example is a browser that disallows Javascript and/or cookies. A final example is a customer browser that has the 1.3 JRE installed but your applets require a 1.4 JRE.
2.6 Network Considerations
Consider the following in any network communication:
◊ Latency
◊ Bandwidth
◊ Number of network calls ◊ Size of network calls Y ◊ Firewall navigation L ◊ Security of the network N
◊ Distributed object communication O N 2.7 Latency andIO Bandwidth T Latency is the time it takes to handleA a network call (round-trip time) Bandwidth is the data capacityU of the network L ◊ E.g., 1 million bits/secondA ◊ Bandwidth is sharedV amongst all users Large bandwidth doesn’tE necessarily mean good network performance
◊ E.g., transfer 20Mb message over 100Mb/s network with latency of 4 seconds is the same response time as 1Mb message (i.e., about 4 seconds)
Latency and Bandwidth
Network latency is made up of delays in hardware (e.g., network switches), O/S, and the time to process the request on the client stack, as well as on the server. Large bandwidth doesn’t necessarily imply good network performance for several reasons. Increasing bandwidth may make network latency become the bottleneck as illustrated in the slide. In this case,
27 Chapter 2 - System Architecture Development Guidelines additional bandwidth only offers value if user loads increase. This is further magnified by the number of requests sent over the network. For example, suppose latency is 4 seconds, bandwidth is 1 million bits/second and a 1000 bit message is sent over the network. The total response time will be about 4 seconds. On the other hand, if the message is sent one bit at a time and the sender waits for each response, the total response time will be about 4 * 1000 = 4000 seconds. Furthermore, if the network is experiencing large user loads, the available bandwidth can quickly be consumed.
2.8 Minimize Number of Network Calls
Each network call contains overhead: ◊ I.e., latency, establish the connection, error checking,Y etc. Techniques to minimize number of network calls: L ◊ Make one aggregate call instead of many N ◊ Use client side validations O N ◊ Use caching O ◊ Use jar files for applets I T ◊ Use fewer screens with moreA information on each U Minimize Number of Network LCalls Each network access contains a certainA amount of overhead, latency being the most prominent. Therefore, it is generally preferredV to make fewer, larger network accesses rather than more, smaller network accesses as the amountE of overhead is reduced simply because there are less calls. This simple idea is contained in several concepts such as design patterns, the use of jar files for applets (as opposed to several files), etc. In addition, if you can prevent unnecessary network calls, you avoid the network overhead and latency altogether. The use of client side validations is one technique for achieving this goal. Client side validations (in Javascript for example) prevent expensive network calls and give responsive feedback to the user immediately upon taking an action. This technique significantly improves performance in those cases where users are likely to make errors. The tradeoff is that client side validations are sometimes easy to bypass, so the same validations should also occur on the server. Caching is another option to avoid network calls. For example, read-only or extremely slowly changing data can be cached on the client or web tier to reduce network accesses. Another possibility is to use fewer user screens by creating screens that contain more information on
28 Chapter 2 - System Architecture Development Guidelines them. This is only possible if the user workflow facilitates it. For example, a three part wizard that asks the user for three pieces of information could be merged into one screen.
2.9 Minimize Network Call Size
Store user state on the server
◊ Use HttpSession or Stateful Session EJBs
◊ Avoid cookies for storing user state as they are limited in size, can only store strings and can be disabled by the user Avoid client side transactions
◊ These add additional network overhead Use lighter presentation Y L ◊ Avoid large graphics if possible N Use data compression O ◊ E.g., deploy applets in compressed jarsN O Minimize Network Call Size I T Another guideline for effective network communicationA is to minimize the size of network calls. Sometimes, a smaller sized network call willU perform better than a larger size call. This is the case on low bandwidth networks or networks withL significant traffic. One technique is to store user state on the server, rather than the client. Passing large amounts of user state between the client and server quicklyA uses up network bandwidth. Web applications that use cookies for client state tend to be lessV secure and are limited in how much state and the types of objects that can actually be stored. Furthermore,E cookies can be disabled by the user, although this limits the user’s ability to use many web sites. State can be stored on the server in a variety of ways including HttpSession in web applications, stateful session EJBs and in databases. The tradeoff here is that more resources are required on the server, but this is generally a better approach overall. One exception to this is to use cookies to track the user’s session id. This is a small, unique identifier that a web container assigns to a user the first time they access a web application. This cookie is sent back to the web server on each subsequent request and the web container uses it to associate the request with a previous HttpSession. Client side transactions are transactions that are initiated from the client. These should be avoided for several reasons. Transactions started in the client add additional network overhead and increase coupling of the client to the server implementation. The long duration of client-initiated transactions also reduces concurrency in the remainder of the system.
29 Chapter 2 - System Architecture Development Guidelines
Data compression techniques work well when the size of the data exceeds the available bandwidth.
2.10 Firewall Navigation
Network communication in architectures that have a firewall between a client and server require careful consideration Firewalls typically employ the principle of “least privileges”
◊ I.e., no access except the access that is required To navigate firewalls controlled by your organization
◊ The Architect must work closely with the Network Administration team to ensure the protocols and ports used will be allowed To navigate firewalls outside the control of your organizationY L ◊ The Architect should assume the scenario withN least privileges ◊ I.e., use standard, commonly allowed protocols O and ports N Firewall Navigation O Firewalls secure internal networks from un-trusted networks.I However, firewalls make network communication more complex since they tend to blockT all types of traffic that they do not understand or that look suspicious. A When considering firewalls, it is important toU consider both firewalls within your organization and firewalls outside of your organization. ForL example, suppose you have an applet deployed on your web server for customers to use. This appletA makes network connections back to a process on your web server. This network traffic will needV to make its way from the customer’s PC, through the customer’s firewall, through the Internet, throughE your firewall and to your web server. This is a simple scenario. There could also easily be multiple firewalls in either organization.
2.11 Firewall Navigation (Cont...)
HTTP on port 80, HTTPS on port 443
◊ Outbound: Is usually allowed
◊ Inbound: Is allowed to servers that host web servers
◊ Hence, browser based HTML clients are the safest choice
30 Chapter 2 - System Architecture Development Guidelines
JRMP, IIOP, Proprietary protocols
◊ Outbound: Is usually not allowed
◊ Inbound: Almost always not allowed
Firewall Navigation (Cont...)
Firewalls typically allow the outbound HTTP traffic on port 80 and HTTPS on port 443 (or 80). If your organization has a web site on port 80, your firewall will allow inbound HTTP traffic on port 80 to the server or servers that host the web site. Hence, browser based HTML clients are the best way to navigate firewalls and really are a very good choice for delivering content to users in organizations outside of your control. JRMP, IIOP and other proprietary protocols and ports are usually not allowed both inbound and outbound. For example, suppose your partner with a company that offers a service, which you can connect to, gets some kind of XML information. The service runs on port 3000 (on their server) and uses a proprietary application protocol on top of TCP/IP. You develop a componentY to connect to their service to get the information. There is a good chance that your networkL administration team has disabled outbound traffic to ports other than common ports such as 80N and 443. Therefore, you will have to work with your network team to allow outbound traffic onO this port to the IP address(es) of your partner’s server(s). N IO 2.12 Firewall NavigationT (Cont...) Protocol Tunneling A U ◊ Sending messages of oneL type over a path that was intended for some other type of messageA ◊ E.g., RMI over HTTPV on port 80 ◊ Avoid if possibleE as it reduces security and performance
◊ May be required if firewalls are not in your control (i.e., tunnel out of a foreign network)
◊ Both JRMP and IIOP support tunneling over HTTP
◊ SOAP was designed to work over HTTP
Firewall Navigation (Cont...)
Protocol tunneling is a technique where messages of one type are transformed in such a way that they can be sent over the communication path that was designed for another protocol. It is a way of
31 Chapter 2 - System Architecture Development Guidelines navigating through firewalls that may or may not be in your control. Tunneling is most often used over HTTP. That is, other protocols such as JRMP, IIOP and SOAP all support tunneling over HTTP. In fact, SOAP is meant to tunnel over HTTP. The issue with tunneling is two-fold. First, it hinders performance since it requires all messages to be transformed both at the source and the target. Second, it negatively affects security since you are in essence bypassing firewall rules that have been configured for a certain type of traffic. It is better to be clear with the network administration team about the types of traffic that are being used as well as their purpose so that they can configure the firewall and hence offer the appropriate level of security. For these reasons, if firewalls are in your control, you should avoid tunneling. Unfortunately, if you are providing services to users behind firewalls that are not in your control, you may need to use tunneling in order to navigate through their firewalls. This is another reason why HTML based clients are a good choice in this situation (i.e., you don’t need to tunnel). Tunneling is quite possibly prohibited by company policy, either explicitly or implicitly. In such a case, using it might subject you to disciplinary action. Y L 2.13 Secure CommunicationN
O Use SSL (or TLS) as the transport layer N ◊ The SSL layer lies between TCP/IPO and the application protocol (e.g., HTTP) I T ◊ HTTPS is HTTP over SSL A JRMP, IIOP and SOAP are alsoU capable of working over SSL L Reduces performance A Greatly enhances securityV ◊ Authentication,E integrity and confidentiality Provides stateful connections
Secure Communication
SSL is Secure Sockets Layer. As of version 3.1, it was renamed to Transport Layer Security (TLS) version 1.0, but is still commonly referred to as SSL. The TCP/IP network model with SSL is stacked as follows: Application Protocol (e.g. HTTP, FTP, JRMP, IIOP, etc) SSL/TLS TCP IP
32 Chapter 2 - System Architecture Development Guidelines
SSL uses public key technology to provide authentication and integrity (via certificates and digital signatures), and confidentiality (via encryption). The tradeoff of using SSL is that the additional overhead of hashing, encryption and handshaking reduces performance.
2.14 Distributed Object Technologies
Distributed object technologies allow inter-process and inter-machine method invocation
◊ Examples include RMI, CORBA, DCOM The remoteness of objects is mostly hidden from the developer, making it seem like the remote objects are local These technologies provide tools to create one or moreY proxies that L handle the network communication N ◊ The developer does not have to write the (potentially error-prone) low level network communication code O N Distributed Object Technologies IO Distributed object technologies allow developers toT call remote objects very much the same way as they call local objects. This allows developers Ato avoid writing the complex and error-prone low level networking and multi-threading code. U In RMI, client side proxies (called stubs)L are created using the rmic compiler. Method calls on these proxies are made by the client. The proxiesA handle the calls to remote objects on the server. This includes marshalling of parameters,V return values and exceptions across the network. The RMI subsystem on the server side thenE uses reflection to make the method call on the remote object. CORBA uses a similar approach with client side stubs and server side ties. DCOM is Microsoft’s Distributed Component Object Model.
33 Chapter 2 - System Architecture Development Guidelines
2.15 Distributed Object Technologies (Cont...)
A Simplified View of How RMI Works
Client Server Object Object
Stub RMI subsystem Network Y L Client JVM ServerN JVM Distributed Object Technologies (Cont...) O We say this is a simplified view of how RMI works becauseN this is how it appears to work, not how it technically happens. The server will initially create the Oobjects and then register them. Then when the client needs access to a remote object, it looks up the objectI in the registry. This is done with a request through the stub to the server side RMI subsystem.T The object will be returned as a result of the request and now the client can access the objectA as if it were local. The stub and server side RMI subsystem allows this access to the remote objectU to appear transparent. L A 2.16 DistributedV Object Technologies (Cont...) CORBA uses IIOPE (Internet inter-orb protocol) as its network communication protocol Java RMI uses JRMP (Java remote method protocol) Java RMI can also use RMI-IIOP
◊ This is “RMI over IIOP”
◊ Allows Java objects to make RMI calls to remote CORBA objects and vice versa
◊ Also allows Java RMI to use CORBA services
34 Chapter 2 - System Architecture Development Guidelines
◊ EJB containers are required to support RMI-IIOP
Distributed Object Technologies (Cont...)
Initially, RMI was designed to only operate over JRMP. It was later enhanced to work over IIOP. This allows Java programs to use the best of both technologies. That is, the ease of programming that RMI offers combined with the interoperability and services of CORBA (IIOP). Performance of IIOP is slightly lower than JRMP. EJB containers are required to support RMI-IIOP as of the EJB 1.1 specification.
2.17 What is a Transaction?
A bounded sequence of work with well-defined begin and end points All participants in the transaction are in a consistent stateY before and after the transaction L A transaction consists of many discrete tasks whichN must all complete successfully or be “undone” O N ◊ A transaction that is undone is consideredO rolled back or aborted Avoid the use of transactions if possibleI T ◊ If they are needed, keep themA as short as possible U What is a Transaction? L The following pseudocode illustratesA the general approach that transactions take: begin V begin transaction E operation1 … operationN commit transaction exception handler rollback transaction End Transactions reduce the scalability and performance of the system due to underlying locking mechanisms. The architect should carefully consider which use cases require transactions and which do not. If transactions are required, they should be kept as short as possible. Long running transactions can seriously impact the performance of the system.
35 Chapter 2 - System Architecture Development Guidelines
2.18 Bank Example
Suppose we wish to write a method to transfer money from one bank account to another Pseudocode: public void transfer(account1, account2, amount) { account1 = account1 - amount // line 1 account2 = account2 + amount // line 2 } What if the server crashes between lines 1 and 2?
◊ We would have incorrect data in both accounts (i.e., money would have been “lost” in this example) Transactions allow us to group multiple operations so they are atomic Y L ◊ i.e., either all work or none work N O Bank Example N Transactions provide protection against failures of manyO sorts including hardware, network and software failures for aggregate operations that should Iperform in an “all or none” fashion. T A 2.19 MultipleU Users Sharing Data In enterprise systems, multipleL users often have the ability to read and write to the sameA data at the same time V Example: E ◊ User 1 wishes to transfer $10 from account 1 to account 2
◊ User 2 wishes to get the total of accounts 1 and 2
◊ The processes run concurrently and happen to be sequenced: User 1 process subtracts $10 from account 1 User 2 process reads account 1 User 2 process reads account 2 User 1 process adds $10 to account 2
36 Chapter 2 - System Architecture Development Guidelines
◊ User 2 will have the incorrect total (it will be short by $10) Transactions allow us to group multiple operations so they are isolated from other transactions
Multiple Users Sharing Data
Transactions allow multiple users to access shared data concurrently (at the same time), yet still preserve the integrity of the data as if the users had accessed the data serially (one at a time).
2.20 ACID Properties of Transactions
Atomicity ◊ A transaction is treated as a single task that eitherY completes or does not happen at all, even though it consists of severalL steps one of which may fail N Consistency O ◊ Resources participating in a transactionN cannot be corrupted by attempting to execute a transaction,IO even if it fails Isolation T ◊ The activities of one transactionA do not interfere with the activities of another transaction U L Durability A ◊ Once a transactionV completes, its results must be made permanent E 2.21 Architecture
The creation of an architecture in the beginning helps to control costs by:
◊ Creating a common vision
◊ Ensuring consistency in the detailed design
◊ Promoting reusability by identifying common features
37 Chapter 2 - System Architecture Development Guidelines
Architecture
Architecture helps to create a common vision that keeps developers on track and helps to avoid rework due to a lack of understanding of the goals of the project. It also ensures consistency in the detailed design thus improving developer productivity by reducing the learning curve and communication required. Finally, it promotes reusability by identifying common features sooner rather than later; thus, developers spend less time building similar elements and refactoring when duplication is discovered.
2.22 Reference Architecture
A reference architecture is an architecture for a particular application domain E.g., reference architecture for a power grid operationsY system L A reference architecture can reduce costs by: N ◊ Saving architects time in finding elements O for a particular domain ◊ Reuse of a common vocabulary that canN be used in the industry, thus reducing the level of communicationIO required T Reference Architecture A Sun provides some example reference architecturesU at http://www.sun.com/service/refarch/. This site includes reference architectures for enterpriseL document management, enterprise reporting, data warehousing, data centers, business intelligence,A collaboration, digital asset management, retail banking, pharmacy management, Vetc. For example, a retail banking reference architecture is described at http://www.sun.com/service/refarch/specs.html#RetailBankingE . 2.23 Patterns
A pattern is a proven solution to a common problem in a given context
◊ The context is important; a pattern is not always applicable Patterns reduce costs since:
◊ Development is faster as developers eventually become very good at applying appropriate patterns that require less rework later because they work
38 Chapter 2 - System Architecture Development Guidelines
◊ Maintenance is cheaper as developers can recognize patterns when they are used and can learn the system faster
Patterns
When you are designing a system, you never really start from scratch. Rather, experience and convention will lead you to apply common solutions to common problems. For example, if you are building a Web application, one proven way to do so is to use the Model-View-Controller pattern, in which you clearly separate the business logic (the model) from its presentation (the view) and from the agent (the controller) that keep the business logic and the presentation in sync. By using such patterns, you make your system far more understandable, less prone to difficult issues, and easier to implement, evolve and maintain.
2.24 Development MethodologiesY A development methodology is an approach forL performing development activities in a coherent and repeatableN manner Methodologies incorporate best practices O and lessons learned from previous developers N Examples include: IO ◊ RUP - Rational Unified ProcessT A ◊ Extreme Programming (Agile)U Use of a development methodologyL reduces costs since: ◊ Fewer mistakes areA made because new developers learn from previous V experiences E ◊ Tasks are performed in a consistent manner so people do not need to spend as much time communicating
◊ Necessary communication actually happens
Development Methodologies
It doesn’t matter so much what methodology you use, but rather that you do use one.
39 Chapter 2 - System Architecture Development Guidelines
2.25 Open Standards
The use of standards reduces costs since:
◊ Developers become proficient with standards and can quickly understand new elements that use those standards Versus having to understand different approaches each time they are assigned to a new project
◊ Makes it easier to avoid vendor lock-in so customers can choose less costly solutions if a vendor raises prices and/or fails to provide effective products/services
◊ Makes it easier to integrate systems, thus facilitating reuse of investments that have already been made Y Common standards: L ◊ Java EE, UML, XML, HTML, HTTP, IIOP, SSL,N SOAP O N 2.26 FrameworksO I A framework is a reusable group ofT libraries, classes and modules that applications can extend and buildA upon Once a framework is proven,U it can be reused in many different applications L Applications require lessA testing and are exposed to less risk by using a proven framework V E Example frameworks include:
◊ Java EE EJB, Servlet, JSP, Swing
◊ Jakarta Struts, JSF, Spring, Log4J
Frameworks
Note that frameworks sometimes make it harder to achieve behavior that isn't directly what the framework supports (e.g., file handling inside an EJB container).
40 Chapter 2 - System Architecture Development Guidelines
2.27 Summary
Understand Quality of Services Risks and Mitigation How to optimise Network Communication Understand Transaction
Y L N O N IO T A U L A V E
41 Y L N O N IO T A U L A V E