core indigo patterns n.
Skip this Video
Download Presentation
Core Indigo Patterns

Loading in 2 Seconds...

play fullscreen
1 / 17

Core Indigo Patterns - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Core Indigo Patterns' - joie

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
core indigo patterns

Core Indigo Patterns

Ted Neward

  • 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
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
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
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 catalog1
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 catalog2
Core J2EE Patterns Catalog
  • Integration Tier Patterns
    • Data Access Object
    • Service Activator
    • Domain Store
    • Web Service Broker
pattern intercepting filter
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
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
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
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
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
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
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
  • 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
  • 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