Enterprise Software Architecture Study Group

1. Enterprise Software Architecture Study Group Introduction

2. http://wiki.daimi.au.dk/esasg • Form • Plan including time • Contents Enterprise Software Architecture Study Group, Q3 2006

3. Literature • [Dyson and Longshaw, 2004] • Dyson, P., and Longshaw, A. (2004). Architecting Enterprise Solutions: Patterns for High-Capability Internet-based Systems. Wiley • s. 11-44 • [Hohpe and Woolf, 2003] • Hohpe, G., and Woolf, B. (2004). Enterprise Integration Patterns: Designing and Deploying Messaging Solutions. Addison-Wesley • s. 1-15, 39-56 • [Fowler, 2002] • Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley • s. 1-53 Enterprise Software Architecture Study Group, Q3 2006

4. [Dyson and Longshaw, 2004] • Defining and evolving architectures for high-capability Internet technology systems • ”Internet technology”: builds upon the (TCP/)IP stack • ”High-capability”: ”high” performance and scalability • Types of Internet technology systems • {Business, Consumer, Employee} x {2} x {Business, Consumer, Employee} • Here concerned with systems with ”high levels of certain system qualities” • Examples • Amazon.com, Boeing Supplier Portal, MS Market, blog.com, letsbuyit.com intranet extranet public Enterprise Software Architecture Study Group, Q3 2006

5. Why? • Advantages • Ubiquity (of Internet technology on platforms) • Simplicity (of Internet protocols) • Reach (of potential customers) • Cost (to build) • Skills (needed of employees) • Disadvantages • Unpredictable response times (for TCP/IP traffic) • Limited user interfaces (capabilities of HTML) • Performance (problems of text-based protocols) • Slow standards evolution • Expectations and bleeding edge development Enterprise Software Architecture Study Group, Q3 2006

6. ’Bleeding Edge’ • E.g., W3C status ws-addressing is ”Candidate Recommendation” Enterprise Software Architecture Study Group, Q3 2006

7. System Architecture • System architecture • Software elements that implement functionality • Hardware elements that provide execution environment for software • Concerned with balancing non-functional characteristics in order to fulfil non-functional requirements • NFR describe tolerances, boundaries, and stardards that must be adhered to • NFRs are interdependent • System architecture is a determinant in the non-functional characteristics of the implemented system • (’System architecture’ ~ ’software architecture’ in, e.g., [Bass et al., 2003]) Enterprise Software Architecture Study Group, Q3 2006

8. [Dyson and Longshaw, 2004] System performance Availability Performance Short-term scalability System control Security Manageability Maintainability System evolution Flexibility Portability Long-term scalability (More in line with [ISO/IEC, 2001] than [Bass et al., 2003]) [Bass et al., 2003] Modifiability Availability Performance Security Testability Usability (Just make sure that we know what the requirements and characteritics are...) ’Non-Functional Requirements’ vs ’System Quality Attributes’ Enterprise Software Architecture Study Group, Q3 2006

9. NFR Characteristics of Internet Technology Systems • Availability • Often need to be available ”24x7 all year around” • Performance • Public Internet: Based on users’ expectation of ‘fast’ Internet. Users cannot be ‘educated’ • Extranet/Intranet: Users can be educated • Scalability • Public Internet: Often very hard to predict number of and growth in users • Intranet: Often possible to predict number of users accurately • Extranet: Both types • Security • Public Internet: Open registration, secure when connected • Intranet: Perimeter-based often OK • Extranet: Very high security requirements • Manageability • Public Internet: High monitoring and parameterization requirements • Intranet: Monitoring • Extranet: Both types • Flexibility • “Based on business objectives” • Portability • “Based on the likelihood of the environment to be changed” Enterprise Software Architecture Study Group, Q3 2006

10. Building Blocks of ITSs • Web Server • Apache, Microsoft IIS, iPlanet Web Server • Jetty, Tomcat • Application frameworks • IBM WebSphere, BEA WebLogic, Microsoft .NET framework, Macromedia ColdFusion • JBoss, Apache Geronimo • Databases • Oracle, Microsoft SQL, IBM DB2, Tamino • MySQL, PostgreSQL • Routers • Firewalls • Load balancers • Email servers • Management consoles • IBM Tivoli, HP OpenView Enterprise Software Architecture Study Group, Q3 2006

11. [Hohpe and Woolf, 2003] • Overview • Solving integration problems with patterns • Integration styles • Patterns • Messaging Systems • Messaging Channels • Message Construction • Message Routing • Message Transformation • Messaging Endpoints • System Management • Examples Enterprise Software Architecture Study Group, Q3 2006

12. Why Do We Need Integration? • Enterprises are comprised of hundreds or thousands of applications • Custom-built, acquired, legacy systems, ... • Writing business applications is hard and complex • Diversity and choice is good (e.g., in selecting an accounting package and a CRM package) • Users want to execute business functions • Implies need for integration • ”connecting computer systems, companies, or people” • With the purpose of providing unified business functions – at least when considering systems • Efficient, reliable, secure, ... Enterprise Software Architecture Study Group, Q3 2006

13. Integration Architectures • Information portals • Data replication • Shared business functions • Service-oriented architectures • Universally available functions • Service discovery and negotiation • Distributed business processes • Introduce business process • management component • Business-to-business integration • Integration of externally available business functions Enterprise Software Architecture Study Group, Q3 2006

14. An Aside: [Thomas and Nejmeh, 1992] • Presentation integration • How similar is interaction? • Data integration • How are data maintained and kept consistent? • Control integration • How are services used across applications? • Process integration • The degree to which the integrated application supports an integrated process Enterprise Software Architecture Study Group, Q3 2006

15. Criteria when Integrating • Coupling • Intrusiveness • Technology selection • Data format • Data timeliness • Data or functionality • Remote Communication • Reliability Enterprise Software Architecture Study Group, Q3 2006

16. Loose Coupling • Reduce the assumptions that two elements have on each other when they exchange information • i.e., maintain a minimal interface (in the broad Parnas-sense of interface) • Assumptions • Platform technology • Location • Time • Data format Enterprise Software Architecture Study Group, Q3 2006

17. Integration Styles • File transfer • Shared database • Remote Procedure Invocation • Messaging Enterprise Software Architecture Study Group, Q3 2006

18. File Transfer Enterprise Software Architecture Study Group, Q3 2006

19. Shared Database Enterprise Software Architecture Study Group, Q3 2006

20. Remote Procedure Invocation Enterprise Software Architecture Study Group, Q3 2006

21. Messaging Enterprise Software Architecture Study Group, Q3 2006

22. Messaging Systems • Messaging (in this context) • Distributed communication by sending messages • Asynchronous, reliable delivery • Channels (AKA queues) • Connect applications by conveying messages • ’Messaging systems’ provide messaging capabilities Enterprise Software Architecture Study Group, Q3 2006

23. [Fowler, 2002] • Architecture • Shared understanding of a system’s design by the expert developers (?) • Business logic • Sets of interacting business rules (?) • Enterprise application • An application used by an enterprise (?) Enterprise Software Architecture Study Group, Q3 2006

24. Patterns • Alexander • ”Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of a solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice” • Characteristics • Rooted in practice • Non-trivial to apply • Relatively independent • Form here • Name • Intent and sketch • Motivation • How it works • When to use it • Further reading • Examples Enterprise Software Architecture Study Group, Q3 2006

25. Layering • Dependencies • Layers vs tiers • Responsiveness and disconnected operation Enterprise Software Architecture Study Group, Q3 2006

26. Organizing Domain Logic • Choices • Transaction Script • Organizing domain logic around procedures • Processes, validates, calculates input from presentation; stores in DB • Domain Model • Organizing domain logic around classes • Often combined with a more procedural Service Layer • Table Module • Organizing domain logic around tables • Service Layer • Often a facade for domain logic • Use case-oriented API • Transaction control, security, ... Enterprise Software Architecture Study Group, Q3 2006

27. Mapping to Relational Databases • Data source is most often a relational database • Impedance mismatch SQL <-> programming language • Anecdotal evidence: A third of programming effort spent on mapping • Data Mapper; Active Record, Table Data Gateway, Row Data Gateway • ”The Behavioural Problem” • How do you handle persistence vs. objects at runtime? • Tracking modifications, reading only once, transactions, • Structural mapping • Connection management Enterprise Software Architecture Study Group, Q3 2006

28. References • [Bass et al., 2003] • Bass, L., and Clements, P., and Kazman, R. (2003). Software Architecture in Practice. 2nd Ed. Addison-Wesley • [ISO/IEC, 2001] • ISO/IEC (2001). Software Engineering - Product Quality. Part 1: Quality Model. ISO/IEC 9126-1 • [Thomas and Nejmeh, 1992] • Thomas I. and Nejmeh B.A. (1992). Definitions of tool integration for environments. IEEE Softw 9(2):29–35 Enterprise Software Architecture Study Group, Q3 2006