Return to Home Page
Overview
    History
    Acknowledgements
    Podcasts
    Notification Form
    Feedback Form
    Press Release #1
    Press Release #2
    Press Release #3

Master SOA Design
Pattern Catalog
    Master Pattern List (alphabetical)
    Master Pattern List (by category)
    Master Pattern List with
Page Numbers (PDF)
    Master Pattern List (Text)
    Pattern Notation
    Pattern Profiles
    Symbol Legend
    Pattern Contribution Form

SOA Candidate Patterns
    SOA Patterns Review Committee
    Candidate Patterns Overview
    Candidate Patterns List
    Candidate Pattern Contribution Form
    Candidate Pattern
Feedback Form
    SOA Pattern Template

Design Pattern Basics
    What's a Design Pattern?
    What's a Design Pattern Language?
    What's a Compound Pattern?

Supplemental
    SOA Patterns and Application Technologies
    SOA Design Patterns Historical Influences
    SOA Design Patterns and Design Principles
    SOA Design Patterns and Design Granularity
    Legal

Resources
    Design Patterns Publications
    Reference Posters
    SOAPrinciples.com
    WhatIsSOA.com
    SOA Visio Stencil

About the Book



SOA Design Patterns
by Thomas Erl

For more information visit: www.soapatterns.com

Related Publications


"Introducing SOA Design Patterns", SOA World Magazine (PDF)



"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)



"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)



"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)



"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)



"Service Facade", InformIT (HTML)



"Non-Agnostic Context", InformIT (HTML)



"Domain Inventory", InformIT (HTML)



"Service Normalization", InformIT (HTML)



"Service Decomposition", InformIT (HTML)



"Canonical Schema", InformIT (HTML)



"Policy Centralization", InformIT (HTML)





Blind Message Routing (candidate)


Home > Candidate Patterns List > Blind Message Routing

How can a service consumer access a service that does not want to reveal its physical location?

Problem

Services that need to be made available to external or non-trusted consumers can risk a variety of security breaches because malicious consumers are provided with physical access information.

Solution

The physical location of a service is hidden and a logical address is provided to consumers instead. Intermediary process intercepts messages from consumers and resolves the logical address in the actual physical address.

Application

WS-Addressing EPRs can allow for a message to be sent to a service endpoint for which it does not have a physical address. This pattern relies on the use of intermediary agents to resolve the absence of a real address, and these agents, in turn, rely on EPR values to route the message to its intended destination.

Impacts

Increased infrastructure complexity and administration effort associated with maintaining logical and physical addresses.

Principles

Standardized Service Contract, Service Loose Coupling, Service Abstraction

Architecture

Composition

Status

Under Review

Contributor

Thomas Erl
 

When a service exists in a secured environment but must communicate with an external consumer program located on the other side of a firewall, the service can be designed to not reveal its exact location. For example, a service built as a Web service may simply provide a logical address instead of its actual physical address within its published WSDL definition. WS-Addressing EPR parameters can be used by the service's runtime environment to route messages to the service on behalf of the consumer.



A consumer program can "blindly" send a message to a non-existent address. Once the message passes through the firewall, a runtime agent interprets the EPR to determine the correct address and then routes the message to the Web service accordingly.

The scenario illustrated in the figure assumes that the consumer program would have already been authenticated prior to receiving the necessary permissions to contact the Web service, along with an EPR that does not include the actual, physical address of the target service. Instead, the EPR contains a set of reference parameters that are only meaningful to the service's environment.

The consumer sends this "blind" message to service (1), subsequent to which the message is automatically intercepted by the Web service's runtime environment, usually via an event-driven, intermediary agent. After retrieving and validating the EPR parameters, this agent then routes the message to the destination Web service (2).



Contributor Notes

You may be wondering how this utilization of WS-Addressing EPRs differs from Service Instance Routing, since both rely on the usage of intermediary routing agents. First, Blind Message Routing is not geared toward enabling communication with service instances. Secondly, whereas in Service Instance Routing the EPRs will almost always be auto-generated, this is not necessarily true for Blind Message Routing. The EPR values used later to resolve the address, may have been pre-defined and simply retrieved from a repository by the intermediary at runtime. However, it is worth noting that these two patterns can certainly be combined together, allowing a consumer to "blindly" interact with a stateful service instance.

- Thomas Erl

The Prentice Hall Service-Oriented Computing Series from Thomas Erl
Home    SOA Books    SOA Magazine    What is SOA?    SOA Principles    SOASchool.com    SOA Glossary Copyright © 2007-2010
SOA Systems Inc.