Core Indigo Patterns

Ted Neward

http://www.tedneward.com

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 http://www.neward.net Blog at http://blogs.tedneward.com