Core Indigo Patterns

1. Core Indigo Patterns Ted Neward http://www.tedneward.com

2. Objectives • Indigo represents a shift of thinking in building distributed systems; such shifts are always hard to adjust to • So let’s take prior art (Core J2EE Patterns) and see how well we can map what we already know to what’s new

3. Refresh: “Indigo” • Now known as “Windows Communication Foundation” • Service-oriented communication library/toolkit • Shipping with Windows Vista (code-name “Longhorn”) • Focus on the A/B/C’s of Indigo: Address, Binding, Contract • Emphasis is on “reducing coupling”, not “distributed objects”

4. Refresh: Core J2EE Patterns • By Alur, Crupi and Malks; considered a seminal J2EE work • Patterns in three categories: • Presentation Tier • Business Tier • Integration Tier • Although Indigo will apply mostly to “Business” and “Integration” patterns, we’ll look at some from all three

5. Core J2EE Patterns Catalog • Presentation Tier Patterns • Intercepting Filter • Front Controller • Context Object • Application Controller • View Helper • Composite View • Service to Worker • Dispatcher View

6. Core J2EE Patterns Catalog • Business Tier Patterns • Business Delegate • Service Locator • Session Façade • Application Service • Business Object • Composite Entity • Transfer Object • Transfer Object Assembler • Value List Handler

7. Core J2EE Patterns Catalog • Integration Tier Patterns • Data Access Object • Service Activator • Domain Store • Web Service Broker

8. Pattern: Intercepting Filter • Problem: • You want to intercept and manipulate a request and a response before and after the request is processed • Forces: • You want centralized, common processing across requests • You want pre- and postprocessing components loosely coupled with core request-handling services to facilitate unobtrusive addition and removal • You want pre- and postprocessing components independent of each other and self-contained to facilitate reuse

9. Pattern: Context Object • Problem: • You want to avoid using protocol-specific system information outside of its relevant context • Forces: • You have components and services that need access to system information • You want to decouple application components and services from the protocol specifics of system information • You want to expose only the relevant APIs within a context

10. Pattern: Business Delegate • Problem: • You want to hide clients from the complexity of remote communication with business service components • Forces: • You want to access the business-tier components from your presentation-tier components and clients, such as devices, web services, and rich clients • You want to minimize coupling between clients and the business services, thus hiding the underlying implementation details of the service, such as lookup and access • You want to avoid unnecessary invocation of remote services • You want to translate network exceptions into application or user exceptions • You want to hide the details of service creation, reconfiguration, and invocation retries from the clients

11. Pattern: Business Object • Problem: • You have a conceptual domain model with business logic and relationships • Forces: • You have a conceptual model containing structured, interrelated composite objects • You have a conceptual model with sophisticated business logic, validation and business rules • You want to separate the business state and related behavior from the rest of the application, improving cohesion and reusability • You want to centralize business logic and state in an application • You want to increase reusability of business logic and avoid duplication of code

12. Pattern: Session Façade • Problem: • You want to expose business components and services to remote clients • Forces: • You want to avoid giving clients direct access to business-tier components, or prevent tight-coupling with the clients • You want to provide a remote access layer to your Business Objects and other business-tier components • You want to aggregate and expose your Application Services and other services to remote clients • You want to centralize and aggregate all business logic that needs to be exposed to remote clients • You want to hide the complex interactions and interdependencies between business components and services to improve manageability, centralize logic, increase flexibility, and improve ability to cope with changes

13. Pattern: Transfer Object • Problem: • You want to transfer multiple data elements over a tier • Forces: • You want clients to access components in other tiers to retrieve and update data • You want to reduce remote requests across a network • You want to avoid network performance degradation caused by chattier applications that have high network traffic

14. Pattern: Data Access Object • Problem: • You want to encapsulate data access and manipulation in a separate layer • Forces: • You want to implement data access mechanisms to access and manipulate data in a persistent storage • You want to decouple the persistent storage implementation from the rest of your application • You want to provide a uniform data access API for a persistent mechanism to various types of data sources, such as RDBMS, LDAP, OODB, XML repositories, flat files, and so on • You want to organize data access logic and encapsulate proprietary features to facilitate maintainability and portability

15. Summary • Not all prior art is equally applicable • J2EE did things in a different manner than Indigo does • Less focus on “distributed objects”, more on “decoupled services” • But prior art is a good way to investigate new art • Core J2EE Patterns gives us a framework to investigate Indigo • Other patterns works (PEAA, POSA 1 & 2) give us similar structure

16. Questions ?

17. Credentials • Who is this guy? • Independent consultant • Author • C# in a Nutshell (O’Reilly, with Drayton, Albahari, 2001) • Server-Based Java Programming (Manning, 2000) • SSCLI Essentials (O’Reilly, with Stutz, Shilling, 2003) • Effective Enterprise Java (Addison-Wesley, 3Q 2003) • Papers at http://www.neward.net • Blog at http://blogs.tedneward.com