Clemens Vasters clemensv newtelligence com Layers Tiers Services and

Clemens Vasters clemensv@newtelligence. com Layers, Tiers, Services, and Aspects © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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! © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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…. © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Layers & Services Organizing code. © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Layers! Looser Coupling XML HTML GUI EDI Presentation Data Tighter Coupling SQL MQ WS COM Public Interface Internal Implementation Services & Resource Access XSD RPC © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Challenging the Classic Model Presentation Business Logic Data § 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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Services: More Autonomy for Layers Presentation Services Business Services Data Services © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Data Character: A Simple Example Updating Northwind … Territories Region PK FK 1 Employee. Territories PK, FK 1 PK, FK 2 Territory. ID Territory. Description Region. ID PK Region. ID Region. Description Employees PK Employee. ID I 1 Employee. ID Territory. ID Last. Name First. Name Title. Of. Courtesy Birth. Date Hire. Date Address City Region Postal. Code Country Home. Phone Extension Photo Notes Reports. To Photo. Path Orders PK Order Details PK, FK 1, I 2, I 1 PK, FK 2, I 4, I 3 Order. ID Product. ID Unit. Price Quantity Discount FK 1, I 2 FK 2, I 4, I 3 I 5 I 6 FK 3, I 7 I 8 Customers Order. ID Customer. ID Employee. ID Order. Date Required. Date Shipped. Date Ship. Via Freight Ship. Name Ship. Address Ship. City Ship. Region Ship. Postal. Code Ship. Country PK Customer. ID I 2 Company. Name Contact. Title Address City Region Postal. Code Country Phone Fax I 1 I 4 I 3 I 2 FK 1 Suppliers PK Supplier. ID I 1 Company. Name Contact. Title Address City Region Postal. Code Country Phone Fax Home. Page Products PK Product. ID I 3 FK 2, I 5, I 4 FK 1, I 2, I 1 Product. Name Supplier. ID Category. ID Quantity. Per. Unit. Price Units. In. Stock Units. On. Order Reorder. Level Discontinued I 2 Categories PK Shippers PK Category. ID I 1 Category. Name Description Picture Shipper. ID Company. Name Phone Static Near Static Dynamic Hot almost never hardly ever time to time pretty often © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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. © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Data Services (1 of 4) M 1 § R/O is Scalability Heaven § Can Be Replicated § Can Be Indexed § Can Run On-Machine § Can Be Updated M 2 • Timeliness reqs. vary M 3 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Data Services (3 of 4) R/O § One Record, One Machine Balance and Access § Record Actions Here § Where is Record? § Find, then Use § R/O Replication § Load Balancing rec. U rec. V rec. W rec. X Uses Actions © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Data Services (4 of 4) § R/W • Write few records • Write “own” data R/O Balance and Access § R/O • Read many records • Timeliness rec. U rec. V rec. W rec. X Uses Actions © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

How does Hotmail scale (1 of 3)? § Not like that …. R/W Presentation Service Mailbox Store Huge DB © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

How does Hotmail scale (2 of 3)? § Mailboxes spread across independent machines R/O R/W Locator Service R/W Presentation Service Mailbox Services R/W © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

How does Hotmail scale (3 of 3)? § Loadbalance Mailboxes R/O R/W Locator Service R/W Presentation Service Mailbox Services Bucket Manager R/W © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

How does Amazon Scale (1 of 4) § Separate Read-Only and Read-Write Data R/O Validation & Catalog Inventory R/W Orders R/W © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

How does Amazon Scale (3 of 4) § Compensation, No Guarantees R/O Web Access Validation & Catalog Fulfillment Inventory R/W Email Orders R/W © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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™ © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Tiers Distributing layers and dealing with boundaries. © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Tiers: Basic Thoughts § Layers are about organizing code and data § Tiers are about distributing code and data © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Locality: Far vs. Near vs. Local § Local Tiers • Separated by logical or actual (process) boundary on local machine. § Logical means: In. Proc/Out. Proc 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” © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Ways of crossing boundaries One-Way Dialog Request/Response © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Contracts: Promises and Trust § Contracts between tiers … § Contract parts in Web Services § Promises that can be given with proper contracts: • Are promises and guarantees to deliver stuff (and how) • Are promises and guarantees to accept stuff (and how) • XSD: Data types • WSDL/XSD: Messages • WSDL/BPEL 4 WS: Message exchange patterns • WS-Policy: Quality of service rules and req’s • "It'll get there" • "I will deal with it appropriately" © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 ) § 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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Aspects Cutting through layers at boundaries and other places. © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Crosscutting layers Tr a n S i to r i io ns Mon sa c t urity ec ng © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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. © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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? © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Aspects: The Idea Customer Data Presentation Orders Data Presentation Shipping Data Presentation Eventing Customer Data Logic Orders Data Logic Shipping Data Logic Customer Data Access Orders Data Access Shipping Data Access Monitoring Configuration Transactions Mapping domain axis Security Validation Accessibility infrastructure axis Infrastructure functionality cross-cuts domain functionality © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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) § Aspect. J, x. C# • Call-time weaving (interception) § ASMX, Enterprise Services, EJB © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

Aspect Weaving [Transaction] public class My. Class { [Secure. Method] // or otherwise def'd public int Call. Me(string Arg 1, string Arg 2) { // … My. Class myobj = } weaving Enlist in new My. Class(); } ret transaction = my. Obj. Call. Me(a 1, a 2); by metadata evaluation My. Class myobj = new My. Class(); Call. Class. Aspects. Before. Call(myobj, a 1, a 2); Call. Method. Aspects. Before. Call(myobj, a 1, a 2); Leave ret = my. Obj. Call. Me(a 1, a 2); transaction Call. Method. Aspects. After. Call(myobj, ret); Call. Class. Aspects. After. Call(myobj, ret); © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved

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 © 2003 newtelligence Aktiengesellschaft, Gilleshütte 99, D-41352 Korschenbroich, Germany – Unauthorized reproduction or distribution prohibited. All rights reserved