Core Indigo Patterns Ted Neward

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

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”

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

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

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

Core J2EE Patterns Catalog Integration Tier Patterns  Data Access Object  Service Activator  Domain Store  Web Service Broker

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

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

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

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

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

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

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

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

Questions ?

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  Blog at