Software Architecture & Design

1. Software Architecture & Design 6CCS3SAD / 7CCSMDAS Dr Kevin Lano

2. Session 7:Enterprise Styles andEnterprise Integration February 25th, 2019

3. Learning Outcomes At the end of this session you should be able to: • Explain fundamental enterprise architecture styles; • Apply these styles to .NET-based architecture models; and • Explain the need for and the basic concepts of enterprise integration architectures.

4. Last Week • Application Servers • COM+/.NET, ASPs, web services • But other infrastructures work on the same principles • Enterprise services facilitating enterprise application development • Transactions, JIT, Object Pools, ...

5. Today • Conclude study of enterprise architectures • Important n-tiered enterprise styles • Enterprise integration architectures Martin Fowler et al.: Patterns of Enterprise Application Architecture. Addison-Wesley, 2003. Deepak Alur et al.: Core J2EE Patterns. 2nd edition, Prentice Hall, 2003. Adam Bien: Real World Java EE Patterns. 2012.

6. Enterprise styles Part I

7. Enterprise Styles – Overview • Just like ordinary styles, but • Components specific to chosen application server • E.g., UML2 specialized for COM+ • Address concerns specific to enterprise systems • Typically based on n-tiered (3+-tiered) style • Combinations or configurations of services may have negative impact on performance, reliability, etc • Platform-specific constraints and semantics help avoid this

8. Types of Styles • Styles for... • Maintaining separation of concerns between the tiers • E.g., presentation aspects kept separate from business logic; integration tier managing details of communication with resource tier on behalf of business tier (EIS architectures) • Ensuring efficiency of communication between tiers

9. Some Examples • Presentation tier styles (patterns): • View helper • Front controller • Business delegate • Business logic tier styles (patterns): • Session façade • Data transfer object (aka Value Object)

10. View Helper – Problem • Web-based time-tabling system • Different ASP views for lecturers and students • Each • Uses a COM+ component for authentication • Uses a COM+ component to access time-tabling information • Each includes its own code to invoke authentication and then create a presentation  Code repetition!

11. View Helper – Problem (2)

12. View Helper – Problem (3) • Common system logic scattered over multiple .ASP views • Causes maintenance problems and bugs • Data access and presentation logic tangled in the ASPs • Difficult to develop and maintain • Presentation tier can change often! • Cannot separate roles • Software developer vs Web designer

13. View Helper – Solution • Introduce intermediate view helper components • Implemented as ASPs • Store view’s intermediate data model • Serve as business data adapters • Pagelet ASPs • ASPs that are never directly called by end users, only by other ASPs • Componentize presentation logic for reuse • Multiple views may share same helper • Retrieve and adapt similar model state for presentation in multiple ways

14. View Helper – Solution • Intermediate view helper ASP • Part of presentation tier • Encapsulates logic for authorized accessto restricted information • Common to lecturer and studentASPs

15. Some Examples • Presentation tier styles: • View helper • Front controller • Business delegate • Business logic tier styles: • Session façade • Data transfer object (aka Value Object)

16. Front Controller – Problem • On-line shop • Complex navigation structure between a number of different ASP pages • Navigation needs to change often depending on changing business requirements • All views share some behaviour • E.g., logging of user progress through the shop

17. Front Controller – Problem (2) Many users, calling a range of different ASPs ASPs handle navigation between each other via hyperlinks

18. Front Controller – Problem (3) • Problems • No centralized point for handling of common functionality • Integration of system services, content retrieval, progress logging, etc. • E.g., “The user should always be able to see the status of her shopping basket” • Navigation logic scattered across all views • Difficult to update global navigation structure and maintain consistency

19. Front Controller – Solution • Controller component as initial point of contact for handling any request • Chooses appropriate view • Handles errors • Manages selection of content creation strategies (e.g., dependent on target device) • Globally manages navigation structure • Can reduce amount of scripts embedded in ASP views

20. Front Controller – Solution (2) All users interact with ASPs through controller, which handles appropriate navigation logic. Pages appear to navigate between each other, but the controller intercepts and maintains all navigation.

21. Break

22. Some Examples • Presentation tier styles: • View helper • Front controller • Business delegate • Business logic tier styles: • Session façade • Data transfer object (aka Value Object)

23. Some Examples • Presentation tier styles: • View helper • Front controller • Business delegate • Business logic tier styles: • Session façade • Data transfer object (aka Value Object)

24. Session Facade – Problem • Complex presentation logic • Presentation-tier component requires access to multiple business objects • Combines information obtained through all of them

25. Session Facade – Problem (2) • Tight coupling of presentation and business-logic tier • Presentation tier must implement complex business logic • Tangling! • Not reusable across different clients! • Presentation tier becomes directly dependent on implementation of business tier • High network load • Too many method invocations between client and server

26. Session Facade – Solution • Use intermediate business-logic component • Called session façade (cf. Java EE ‘Session bean’) • Provides one simplified interface to client • Manages business logic and interaction of different business objects (workflow) • Remember system components in Cheesman/Daniels approach of Wk 2?

27. Session Facade – Solution (2) Session facade encapsulates purchasing logic for the middle tier, providing a single point of communication to the presentation tier Presentation Tier Business Logic Tier

28. Session Facade – Advantages • Separation of presentation and business-logic concerns • Centralization of interactions (responsibility) • Better manageability; greater ability to cope with changes • Reduction of network usage • Reduced number of components directly accessed over the network

29. Some Examples • Presentation tier styles: • View helper • Front controller • Business delegate • Business logic tier styles: • Session façade • Data transfer object (aka Value Object)

30. Data Transfer Object – Problem • Payment page • Presentation tier uses fine-grained interface to interact with business tier <<ASP>> BillingDetailsPage <<COM+>> BillingSystem <<interface>> IBilling +setName (name : String) : void +setCardNumber (number : String) : void +checkAndCharge() : boolean IBilling

31. Data Transfer ObjectProblem (2) • Clients need to make multiple calls to get job done • Increases network load • Key problem is latency • Sending large amount of data once is better than sending lots of small packets

32. Data Transfer Object – Solution • Use Data Transfer Objects • Inter-tier interfaces become coarser grained • All information transferred in one go • Presentation tier can still interact with DTO in a small-grained manner • But locally! Also known as Value Object pattern (Java EE)

33. Data Transfer ObjectSolution (2) IBilling Data Transfer Object Interface was simplified <<ASP>> BillingDetailsPage <<COM+>> BillingSystem <<interface>> IBilling +checkAndCharge(cardDetails : CardDetail) : boolean

34. The biggest picture: enterprise integration Part II

35. The Biggest Picture • Abstraction helps deal with bigger systems • We continuously increased abstraction: • Source code of programs • Software design (e.g., with UML) • Software architecture (most of this module) • Enterprise Integration is most abstract architecture

36. Enterprise Integration Architectures • Enterprise applications do not exist in isolation • Connected to other applications and services • Data feeds • Common reference data • Elaborate integration networks • Enterprise Integration Architecture (EIA) shows this structure • Entire software portfolio of an enterprise (“software landscape”) • Collection of applications • Heterogeneous platforms • Islands of sometimes duplicated data • Services interconnected by messages, objects, file transfers, batch feeds, and human interactions

37. Describing EIAs • Partially with UML2 • Appropriately stereotyped components corresponding to entire applications • Connectors representing interrelationships between applications • But not completely • Not always component-oriented (hierarchical) • Cross-cutting concerns • Human interaction • Process-based workflows instead of structural connection • Biztalk, Oracle workflow, TIBCO – workflow based technologies to aid integration • E.g., web services and workflow engines

38. Holiday Reservation Workflow Car Rental Service Request Car Quotes Book Car Hotel Booking Service Request Hotel Quotes Choose Package Book Hotel Request Plane Quotes Holiday Package Calculator Book Plane Plane Booking Service

39. Architectural ideas today: Clouds, SOA, Microservices, Containers… Part III

40. Overview • Cloud • Service-oriented Architecture (SOA) • Microservices • Containers

41. Cloud • So far • Application servers provide transparency for software components • What if we could also provide transparency of hardware? • Resources as a commodity • No need to know what HW your SW runs on • No need to know where that HW is • Let someone else manage the HW and share it with other users  Economies of scale!

42. Cloud (2) • Types of Cloud services • Infrastructure-as-a-Service (IaaS) • Platform-as-a-Service (PaaS) • Software-as-a-Service (SaaS)

43. Infrastructure-as-a-Service (IaaS) • Transparent infrastructure (i.e., HW) • Physical machines (PMs) or virtual machines (VMs) • “Buy” additional resources as and when needed • Automated commissioning through an API or web front end • “Metered” consumption: • Pay what you use • Examples: AWS, Azure

44. Platform-as-a-Service (PaaS) • IaaS plus a set of standardised services • Data management, logging, email API, payment services, … • Build software more efficiently by building on existing services • Truly component-based thinking • Reuse at a large scale • Examples: Heroku, Google App Engine, …

45. Software-as-a-Service (SaaS) • “Rent” your software system • Typically accessed through a web front end or app • Data managed transparently on cloud servers • Implementation shared across different users • Highly efficient delivery model • Provider keeps control of software and operations • Efficient updates rolled out to all clients (or only a selection of clients) • Examples: Salesforce, Microsoft Office 365, Google Drive, …

46. Overview • Cloud • Service-oriented Architecture (SOA) • Microservices • Containers

47. Service-oriented Architecture • System is structured as set of communicating services • Services are self-contained functional units • Communicate using standard protocols and data formats (eg., XML, JSON) • Loosely-coupled, not aware of internals of other services. Technology and location independent • Service discovery mechanisms are required, eg., via registries of services/service brokers • Services can be composed, orchestrated, etc • Shifts complexity from application into network

48. SOA example Holiday Booking Service Car Rental Service Hotel Booking Service Plane Booking Service Holiday Package Calculator

49. Microservices • Architectural style • SOA with fine-grained services • Use services for componentisation of applications • Each running in its own process • Potentially developed by separate teams • Communication via web-based protocols http://martinfowler.com/articles/microservices.html

50. Microservices: Advantages • Real-world componentisation! • Independent modification • Incremental updates of application functionality • Clear boundaries of team responsibility • Organisational impact • Continuous deployment in an agile development process • Microservices enforce cross-functional teams rather than functional silos • Remember domain analysis and business type models? http://www.melconway.com/Home/Committees_Paper.html