Optimizing Code Organization: Layers, Tiers, and Services

1. Clemens Vastersclemensv@newtelligence.com Layers, Tiers, Services, and Aspects

2. Topics in this Talk • Layers • Organizing code • Tiers • Distributing Layers • Services • Autonomous Tiers • Aspects • Crosscutting Layers for common infrastructure • 45 Slides, 45 Minutes, Buckle Up!

3. Before we begin… • Service: You’ve heard the word too often • Windows Services • Enterprise Services • Web Services • System Services • Microsoft has, by their own count, 17 different uses for the term „service“ in Windows alone. • No wonder everything’s a service….

4. Orientation… • Cutting through code: “n-tier model” • Layers: organization and architecture idea • Tiers: distribution and deployment idea • Crosscutting through code: “AOP” • Horizontal cut: the default • Vertical cut: services in the COM+/EJB way • Cutting through space & time: “Web Services” • Services on a service bus • Applications invoke services and are services

5. Layers & Services Organizing code.

6. Layers: Considerations • There’s stuff that triggers your code: • Many types of triggers • Web Services, RPC, OS-Timers, OS-Locks, Keyboard • Many different incoming channels • Differ by technology, invocation style, etc. • Shall scale on time axis • Expect frequent changes, expect more channels • There’s stuff that your code does • There’s stuff that your code triggers • Distinct output channels for your code‘s results • In the end, you need to call some API

7. Presentation Data Layers! LooserCoupling XML HTML GUI EDI COM PublicInterface Presentation public class MyBusinessComponent { InternalImplemen-tation Services &ResourceAccess Data TighterCoupling SQL MQ WS XSD RPC

8. Layers: Rationale • Why have layers? • Resilience against changes in other layers • Different character depending on purpose • Public Interfaces • Lots of changes, very frequently • Each change has low impact, but work adds up • Internal Implementation • Shouldn‘t be affected by changes at the module edge • Service & Resource Access • Fewer changes, rather infrequently • Massive impact, often wholesale rewrites

9. Looking for “Business Logic”? • “Today I’ll sit down and write Business Logic“ ? • Business Logic is a confusing buzzword • Suggests that it‘s an independent entity • Planning, Impl., Ownership is usually by module. • Public interface, internals, resource access all in one hand or owned by one small team • Business logic is just the code that … • … will remain valid for any presentation • … will remain valid for any data store

10. Challenging the Classic Model Presentation • Classic: Slices one module into three (or n) layers • Promotes layer resilience • Creates dependent units, tightly coupled • Data layer, presentation are dumb • All data kept in one (big) data model and DBMS Business Logic Data

11. Services: More Autonomy for Layers Presentation Services BusinessServices DataServices

12. Drill-Down: Resource Access • Dumb Resource Access • Pass-through gateway from logic to resources • Queues, Data Stores, Services, Hardware • In other words: What we find in most n-Tier apps • Smart Resource Access • Dealing with data and resources in optimized ways • Respect character, location, concurrency • Very Smart Resource Access • Having others deal with data in clever ways • Be a carefree customer of who knows better

13. Data Character: A Simple Example Updating Northwind … Territories Region PK TerritoryID PK RegionID TerritoryDescription RegionDescription Employees FK1 RegionID EmployeeTerritories PK EmployeeID PK,FK1 EmployeeID Suppliers PK,FK2 TerritoryID I1 LastName PK SupplierID FirstName Title I1 CompanyName TitleOfCourtesy Orders ContactName BirthDate ContactTitle Customers PK OrderID HireDate Products Address Address PK CustomerID City PK ProductID FK1,I1,I2 CustomerID City Region Order Details FK2,I4,I3 EmployeeID Region I2 CompanyName I2 PostalCode I3 ProductName I5 OrderDate I2 PostalCode PK,FK1,I2,I1 OrderID ContactName Country RequiredDate FK2,I5,I4 SupplierID Country PK,FK2,I4,I3 ProductID ContactTitle Phone I6 ShippedDate FK1,I2,I1 CategoryID HomePhone Address Fax FK3,I7 ShipVia QuantityPerUnit Extension UnitPrice I1 City HomePage Freight UnitPrice Photo Quantity I4 Region ShipName UnitsInStock Notes Discount I3 PostalCode ShipAddress UnitsOnOrder FK1 ReportsTo Country ShipCity ReorderLevel PhotoPath Phone Discontinued ShipRegion Fax Categories I8 ShipPostalCode ShipCountry PK CategoryID Shippers I1 CategoryName Description PK ShipperID Picture CompanyName Static Near Static Dynamic Hot Phone almost never hardly ever time to time pretty often

14. Data Character Dictates Strategy • Static data • Make r/o copy close to processing, cache in memory, join in memory, never worry about ACID • Near static data • Make r/o copy close to processing, cache in memory, join in memory, never worry about ACID, replicate • Dynamic data • Make r/w copy at processing, cache carefully, use optimistic locking strategies for updates • Hot data • Insert is better than update. No touch without ACID. Transactions are your friend.

15. Data Services (1 of 4) M1 • R/O is Scalability Heaven • Can Be Replicated • Can Be Indexed • Can Run On-Machine • Can Be Updated • Timeliness reqs. vary M2 M3

16. Data Services (2 of 4) • Scaling with R/O Data is “Embarrassingly Easy” • Special Problems With R/W Data Include • Distributed Cache Coherency/Locks • Co-Location Assumptions • Data-Access Session Length • Load Balancing at Hot Spots

17. Data Services (3 of 4) • One Record, One Machine • Record Actions Here • Where is Record? • Find, then Use • R/O Replication • Load Balancing R/O Balanceand recU Access recV recW recX Uses Actions

18. Data Services (4 of 4) R/O • R/W • Write few records • Write “own” data • R/O • Read many records • Timeliness Balanceand recU Access recV recW recX Uses Actions

19. R/W How does Hotmail scale (1 of 3)? • Not like that …. PresentationService MailboxStore Huge DB

20. R/W R/W R/W R/W How does Hotmail scale (2 of 3)? • Mailboxes spread across independent machines R/O Locator Service PresentationService MailboxServices

21. R/W R/W R/W R/W How does Hotmail scale (3 of 3)? • Loadbalance Mailboxes R/O Locator Service BucketManager PresentationService MailboxServices

22. How does Amazon Scale (1 of 4) • Separate Read-Only and Read-Write Data R/O Validation &Catalog Inventory R/W Orders R/W

23. How does Amazon Scale (2 of 4) • Separation into two systems by queue R/O Web Access Validation &Catalog Fulfillment Inventory R/W Orders R/W

24. How does Amazon Scale (3 of 4) • Compensation, No Guarantees R/O Web Access Validation &Catalog Fulfillment Inventory R/W Email Orders R/W

25. How does Amazon Scale (4 of 4) • Session-balancing: Each Subsystem Scales…. R/O Web Access Validation &Catalog Fulfillment Inventory R/W Email Orders R/W

26. Consequences • Delegation of data caching/retrieval/storage to more autonomous services enables ... • Pipelining and networked data flow • Better isolation of concerns • Subsystems are independent of foreign storage concerns and strategies. • Dealing with data in an appropriate manner • Caching, replication, locking are handled as approprioate for a subsystem • Use of asynchronous processing when appropriate • Choice of data flow strategy made by subsystem • Scalability

27. Unexpected, Dramatic Consequences • Services are incompatible with "domain objects" • OOP is for local, in-service implementation. • "Person" or "Account" is a data structure, not an object • Governed by strong data type rules • Rules are always expressed as part of a data contract (e.g. schema), and never dependent on implementation • Structures flow through services that implement handler logic as appropriate for their assigned task • "Contextual correctness" only exists locally and in the scope of the implementation of certain business rules. • Separation of Code and Data is a Good Thing™

28. Tiers Distributing layers and dealing with boundaries.

29. Tiers: Basic Thoughts • Layers are about organizing code and data • Tiers are about distributing code and data

30. Shape: Fat vs. Thin • “Thin” Tiers • Typically implement only parts of layers • Web Browser provides client portion of an interactive Web user-interface layer • Windows Forms may provide client portion of a GUI/Web services user-interface layer • “Fat” Tiers • Implement full or even multiple layers • “Classic” Client/Server typically implements desktop application with tier boundary through data layer – connecting to remote RDBMS

31. Locality: Far vs. Near vs. Local • Local Tiers • Separated by logical or actual (process) boundary on local machine. • Logical means: InProc/OutProc via config / no recompile • Mandates dynamic loading, factories and activators • Local Tiers never become “Near” or “Far” • Near Tiers • Separated by actual process boundary across machines, inside trust domain and “local network” • Never become “Far” • Far Tiers • Separated by trust, ownership and (possibly) oceans • May be “connected” or “disconnected”

32. Boundaries • You need to design cut points • Design choices are – above everything else – influenced by tier shape and locality • Local: “OO”-style; Classes and Objects • Group Ownership, Reuse by Inheritance, Request/Response, No/Low Latency, Reliable Delivery during Process Lifetime, Inside Fully Trusted Environment • Near: RPC-style; Components and Interfaces • Organization Ownership, Reuse by Aggregation, Request/Response or One Way, Low Latency, "Good Enough" Reliable Delivery, Inside Trust Domain • Far: Message-style; Services and Endpoints • Distributed Ownership, Use but no Reuse, One Way, High Latency, Poor Reliability, Little/No Trust

33. Ways of crossing boundaries One-Way Dialog Request/Response

34. Ways of crossing boundaries • One Way: • Events, Notifications, Batch Jobs • No reply expected or no way to handle appropriately • “Peace of mind” through reliable messaging • Request/Response • Web-style interaction, RPC • Very rapid response expected • Client can’t proceed in any way without reply • One Way is much more often appropriate as current practice suggests • How do you handle an arbitrary foreign exception? • Better to rely on contracts, reliable delivery and guarantees

35. Contracts: Promises and Trust • Contracts between tiers … • Are promises and guarantees to deliver stuff (and how) • Are promises and guarantees to accept stuff (and how) • Contract parts in Web Services • XSD: Data types • WSDL/XSD: Messages • WSDL/BPEL4WS: Message exchange patterns • WS-Policy: Quality of service rules and req’s • Promises that can be given with proper contracts: • "It'll get there" • "I will deal with it appropriately"

36. The Endgame: Service Orientation • Services build on strong contracts • Metadata contracts • Addressing contracts • Quality of service contracts • Security contracts • Message exchange contracts • Message contracts (or explicit absence <any/>) • Code, platform, location become irrelevant • Well understood and agreed behavior • Well understood, strong data types • Message flow instead of object calls • Independence of programming model, runtime choice

37. Aspects Cutting through layers at boundaries and other places.

38. Crosscutting layers Security Transactions Monitoring

39. Aspect Oriented Programming (AOP) • Aspects: The Promise • Isolation of primary and secondary concerns • “Vertical Cut” through Layers • Layers that address “secondary concerns” • Are orthogonal to your code • Crosscut all the layers we discussed up to now.

40. Aspect Motivation • Perceived need for isolation by “concern priority” • It’s not too hard to define layers. • … for the “primary concern” • (which coincidentally happens to be the reason why you write that software in the first place) • Defining infrastructure layers is hard. • Reason: Infrastructure code required everywhere • Authentication, Authorization, Privacy, Logging, Validation, Monitoring, Configuration, Billing, Customization, Accessibility … • “Secondary concerns” often neglected in design • And … really … they’re not your job, usually?

41. domain axis infrastructure axis Aspects: The Idea Monitoring Security Customer DataPresentation Orders DataPresentation Shipping DataPresentation Validation Accessibility Eventing Customer DataLogic Orders DataLogic Shipping DataLogic Configuration Customer DataData Access Orders DataData Access Shipping DataData Access Transactions Mapping Infrastructure functionality cross-cuts domain functionality

42. Cutting Across: Aspect Weaving • Aspects are "woven" into call chain • No explicit calls by you – that's the point • Driven by metadata • May be config, attributes or "other classes" • Techniques: • Compile-time weaving (compiler, post-compiler) • AspectJ, xC# • Call-time weaving (interception) • ASMX, Enterprise Services, EJB

43. Aspect Weaving [Transaction]public class MyClass{[SecureMethod] // or otherwise def'd public int CallMe(string Arg1, string Arg2) { // … }} MyClass myobj = new MyClass();ret = myObj.CallMe(a1, a2); Enlist in transaction weaving MyClass myobj = new MyClass();CallClassAspectsBeforeCall(myobj,a1,a2);CallMethodAspectsBeforeCall(myobj,a1,a2);ret = myObj.CallMe(a1, a2);CallMethodAspectsAfterCall(myobj,ret);CallClassAspectsAfterCall(myobj,ret); Leave transaction by metadataevaluation

44. Aspects: Reality Check • Principle works in closed, consistent infrastructure • Interception-driven COM+ and EJB are proof • Fails horribly as an open extensibility model • Limited set of realistic use-cases • Gatekeepers (Validation, Security) • Logging (Diagnostics, Statistics) • Orthogonal, independent aspects are rare • AOP as a general-purpose programming paradigm is a very cool and yet severely misled approach

45. Where Aspects Fail • Aspect order is significant, side-effects unpredictable • Side-Effect dependencies •  A(Begin Transaction)  A(Log to DB)  •  A(Log to DB)  A(Begin Transaction)  • Outcome contingent processing •  A(Postcondition Check)  A(Billing)  •  A(Billing)  A(Postcondition Check)  • Vulnerability •  A(Auth/Auth)  A(Begin Transaction)  •  A(Begin Transaction)  A(Auth/Auth)  • AOP can isolate primary from secondary concerns, but is incapable of isolating between secondary concerns. • AOP just moves complexity around

46. Summary • Lots of thinking around services • Takeaways • Isolating into autonomous services is more beneficial than using layers only for resilience against changes • It's useful to look at Tiers and Layers as separate ideas • Separation of data and code is great • Aspects are cool but of limited applicability