Messaging Patterns in Service-Oriented Architecture

Introduction: Process Configuration and Flexibility Trends

The need for process flexibility is not a new trend. The trend has been evident for the last two decades. The Internet, Web, and mobile computing came along and enabled a global productivity boom, resulting in technology innovations that are constantly laying the foundation for renovating industrial-age processes.
These solutions are built primarily on proprietary or system-based messaging platforms aimed at providing a platform for integration and communication between various business components. The typical method for accessing these systems is through a wide assortment of pre-built adapters that provide a bi-directional connectivity to many types of application processes. Rather than explicitly declaring how systems will interact through low-level protocols and object-oriented architectures, Service-Oriented Architecture (SOA) makes it possible to provide an abstract interface through which processes or services can interact. It can be imagined as an interconnected process-based enterprise that exposes a set of loosely coupled, coarse-grained services.

What Is Service-Oriented Architecture?

SOA is the aggregation of components that satisfy a business need. It comprises components, services, and processes. Components are binaries that have a defined interface (usually only one), and a service is a grouping of components (executable programs) to get the job done. This higher level of application development provides a strategic advantage, facilitating more focus on the business requirement.
SOA isn't a new approach to software design; some of the notions behind SOA have been around for years. Jess Thompson, a research director at Gartner, argues that the underlying concepts date back to the early 1970s, when researchers started drawing boundaries around software and providing access to that software only through well-defined interfaces.
A service is generally implemented as a coarse-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model.
The most important aspect of SOA is that it separates the service's implementation from its interface. Service consumers view a service simply as a communication endpoint supporting a particular request format or contract. How service executes service requested by consumers is irrelevant; the only mandatory requirement is that the service sends the response back to the consumer in the agreed format, specified in contract.

SOA Entities

SOA consists of various entities configured together to support the find, bind, and execute paradigm as shown in Figure 1.

Figure 1. SOA explained

Service Consumer

The service consumer is an application, service, or some other type of software module that requires a service. It is the entity that initiates the locating of the service in the service registry, binding to the service over a transport, and executing the service function. The service consumer executes the service by sending it a request formatted according to the contract.

Service Provider

The service provider is the network-addressable entity that accepts and executes requests from consumers. It can be a mainframe system, a component, or some other type of software system that executes the service request. The service provider publishes its contract in the service registry for access by service consumers.

Service Registry

A service registry is a network-based directory that contains available services. It is an entity that accepts and stores contracts from service providers and provides those contracts to interested service consumers.

Service Contract

A contract is a specification of the way a consumer of a service will interact with the service provider. It specifies the format of the request and response from the service. A service contract may require a set of preconditions and post conditions. The preconditions and post conditions specify the state that the service must be in to execute a particular function. The contract may also specify quality of service (QoS) levels, specifications for the nonfunctional aspects of the service.

Service Lease

The lease (the time for which the state may be maintained), which the service registry grants the service consumer, is necessary for services to maintain state information about the binding between the consumer and provider. It enforces loose coupling between the service consumer and the service provider, by limiting the amount of time consumers and providers may be bound. Without a lease, a consumer could bind to a service forever and never rebind to its contract again.

Discoverability and Dynamic Binding: Messaging in SOA

SOA supports the concept of dynamic service discovery. The service consumer queries the "service registry for a service, and the service registry returns a list of all service providers that support the requested service. The consumer selects the cost-effective service provider from the list, and binds to the provider using a pointer from the service registry entry.
The consumer formats a request message based on the contract specifications, and binds the message to a communications channel that the service supports. The service provider executes the service and returns a message that conforms to the message definition in service contract.
The only dependency between provider and consumer is the contract, which the third-party service registry provides. The dependency is a runtime dependency and not a compile-time dependency. All the information the consumer needs about the service is obtained and used at runtime. The service interfaces are discovered dynamically, and messages are constructed dynamically. The service consumer does not know the format of the request message or response message or the location of the service until the service is actually needed.
The ability to transform messages has the benefit of allowing applications to be much more decoupled from each other. Messaging underpins SOA; we don't have SOA without messaging.

Messaging Patterns Catalogue Within SOA Context

Messaging patterns exist at different levels of abstraction with the SOA. Some patterns are used to represent the message itself, or attributes of a messaging transport system. Others are used to represent creation of message content or change the information content of a message. Patterns are also used to discuss complex mechanisms to direct messages. SOA messaging patterns can be divided into the following categories:

• Message type patterns. Describe different varieties of messages that can be used in SOA.
• Message channel patterns. Describe the fundamental attributes of a messaging transport system.
• Routing patterns. Describe mechanisms to direct messages between Service Provider and Service Consumer.
• Service consumer patterns. Describe the behavior of messaging system clients.
• Contract patterns. Illustrates the behavioral specification to maintain a smooth communication between Service Provider and Consumer.
• Message construction patterns. Describes the creation of message content that travel across the messaging system.
• Transformation patterns. Change the information content of a message within the enterprise level messaging.

These patterns are shown in Figure 2.

Figure 2. Messaging patterns catalogue within SOA context

Message Type Patterns

The message itself is simply some sort of data structure—such as a string, a byte array, a record, or an object. It can be interpreted simply as data, as the description of a command to be invoked on the receiver, or as the description of an event that occurred in the sender. Sender can send a Command Message, specifying a function or method on the receiver that the sender wishes to invoke. It can send a Document Message, enabling the sender to transmit one of its data structures to the receiver. Or it can send an Event Message, notifying the receiver of a change in the sender.
The following message type patterns can commonly be used in SOA.

Command Message

Problem:
How to invoke a procedure in another application?
Solution: Use a command message to reliably invoke a procedure in another application as shown in Figure 3.

Figure 3. Command message

Interactions:
A command message controls another application, or a series of other applications, by sending a specially formatted message to that system. A command message includes intelligent instructions to perform a specific action, either through headers and attributes, or as part of the message payload. The recipient performs the appropriate action when the message is received. Command messages are closely related to the Command pattern [9].
A command message is simply a regular message that happens to contain a command. A Simple Object Access Protocol (SOAP) request is a command message.
Command messages are usually sent on a point-to-point channel so that each command will only be consumed and invoked once.

Document Message

Problem:
How can you transfer data between services?
Solutions:
Use a document message to reliably transfer a data structure between applications. See Figure 4.

Figure 4. Document message

Interactions:
A document message is just a single unit of information, a single object or data structure that may decompose into smaller units. The important part of a document message is its content; the document. This content is retrieved by un-marshalling / or de-serializing data.
Document messages are usually sent using a point-to-point channel. In request-reply scenarios, the reply is usually a document message where the result value is the document.
A document message can be any kind of message in the messaging system. A Simple Object Access Protocol (SOAP) reply message is a document message.

Event Message

Problem:
Several applications would like to use event notification to coordinate their actions, and would like to use messaging to communicate those events. How can messaging be used to transmit events from one service to another?
Solutions:
Use an event message for reliable, asynchronous event notification between applications. See Figure 5.

Figure 5. Event message

Interactions:
An event message extends the Observer model to a set of distributed applications. Event messages can be sent from one service to another to provide notification of lifecycle events within a service-oriented enterprise, or to announce the status of particular activities. Applications for this pattern include enterprise monitoring and centralized logging.
An important characteristic of event messages is that they do not require a reply.
An event message can be any kind of message in the messaging system. An event can be an object or data such as an XML document.
"If a message says that the Stock price for certain symbol has changed, that's an event. If the message provided information about the symbol, including its new price, that's a document."

Request-Reply Message

Problem:
Messages travel into a message channel in one direction, from the sender to the receiver. This asynchronous transmission makes the delivery more reliable and decouples the sender from the receiver. The problem is that communication between components often needs to be two-way. When one component notifies another of a change, it may want to receive an acknowledgement.
How can messaging be two-way?
Solutions:
Send a pair of request-reply messages, each on its own channel. See Figure 6.

Figure 6. Request reply message

Interactions:
Request-Reply has two participants:

• Requester (Service Consumer). Sends a request message and waits for a reply message.
• Replier (Service Provider). Receives the request message and responds with a reply message.

The request channel can be a point-to-point channel or a publish-subscribe channel. The difference is whether the request should be broadcast to all interested parties or should only be processed by a single consumer. The reply channel, on the other hand, is almost always point-to-point, because it usually makes no sense to broadcast replies.
The request is like a method call. As such, the reply is one of three possibilities:

• Void
• Result value
• Exception

The request should contain a return address to tell the replier where to send the reply. The reply should contain a correlation identifier that specifies which request this reply is for.

Messaging Channel Patterns

Channels, also known as queues, are logical pathways to transport messages. A channel behaves like a collection or array of messages, but one that is magically shared across multiple computers and can be used concurrently by multiple applications.
A service provider is a program that sends a message by writing the message to a channel. A consumer receives a message from a channel. There are different kinds of messaging channels available.

Point-to-Point Channel

Problem:
The sender dispatches a message to a messaging system, which is responsible for relaying the message to a particular recipient. The messaging system might proactively deliver the message (by contacting the recipient directly), or hold the message until the recipient connects to retrieve it.
How can you ensure that exactly one consumer will receive the message?
Solution:
Send the message on a point-to-point channel, which ensures that only one receiver will receive a particular message. See Figure 7.

Figure 7. Point-to-point channel

Interactions:
A point-to-point channel ensures that only one consumer consumes any given message. If the channel has multiple receivers, only one of them can successfully consume a particular message. If multiple receivers try to consume a single message, the channel ensures that only one of them succeeds, so the receivers do not have to coordinate with each other. The channel can still have multiple consumers to consume multiple messages concurrently, but only a single receiver consumes any one message.

Publish-Subscribe Channel

Problem:
The service provider broadcasts an event once, to all interested consumers.
Solution:
Send the event on a publish-subscribe channel, which delivers a copy of a particular event to each receiver. See Figure 8.

Figure 8. Publish-subscribe channel

Interactions:
A publish-subscribe channel that is developed based on Observer pattern [9], and describes a single input channel that splits into multiple output channels—one for each subscriber. After publishing an event into the publish-subscribe channel, the same message is delivered to each of the output channels. Each output channel is configured on one-to-one topology to allow only one consumer to consume a message. The event is considered consumed only when all of the consumers have been notified.
A publish-subscribe channel can be a useful for systems management, error debugging and different level of testing.

Datatype Channel

Problem:
The receiver must know what type of messages it is receiving, or it won't know how to process them. For example, a sender might send different objects such as purchase orders, price quotes, and queries, but a receiver will probably take different steps to process each of these, so it has to know which is which.
Solution:
Use a separate datatype channel for each data type, so that all data on a particular channel is of the same type. See Figure 9.

Figure 9. Datatype channel

Interactions:
In any messaging system there are several separate datatype channels for each type of data. All of the messages on a given channel will contain the same type of data. Based on data type, the service provider sends the data to the channel and the consumer receives data from the appropriate datatype channel.

Dead Letter Channel

Problem:
There are a number of reasons for message delivery to fail. Issues might be message channel configuration problem, a problem with consumers, or message expiration.
Solution:
When there is any delivery issue with the message, it can be moved to a different messaging channel called a dead letter channel. See Figure 10.

Figure 10. Dead letter channel

Interactions:
A dead letter channel is a separate channel dedicated for bad messages or invalid messages. From this channel messages can be rerouted to the mainstream channel or even in separate channel for special processing of the message.

Guaranteed Delivery

Problem:
One of the main advantages of asynchronous messaging over RPC is that the participants don't need to be online at the same time. While the network is unavailable, the messaging system has to use a store and forward mechanism to ensure message durability. By default, the messages are stored in memory until they can be successfully forwarded to the next contract point. This mechanism works well when the messaging system is running reliably, but if the messaging system crashes, all of the stored messages are lost. As a preventative measure, applications use persistent media like files and databases to ensure recovery from system crashes.
Solution:
Use a guaranteed delivery mechanism to make messages persistent. See Figure 11.

Figure 11. Guaranteed delivery

Interactions:
With guaranteed delivery, the messaging system uses a built-in data store (local storage disk space in a participant computer) to persist messages in each participant computer on which the messaging system is installed. The message is safely stored until it is successfully delivered. In this way, it ensures guaranteed delivery.
This guaranteed delivery mechanism increases system reliability, but at the expense of performance as it involves considerable numbers of I/O and consumes a large amount of disk space. Therefore if performance or debugging/testing is the priority try to avoid using guaranteed delivery.

Message Bus

Problem:
An enterprise consists of various independent applications communicating with each other in a unified manner.We need an integration /service architecture that enables those applications to coordinate in a loosely coupled fashioned.
Solution:
Structure the connecting middleware between these applications as a message bus that enables them to work together using messaging as shown in Figure 12.

Figure 12. Message bus

Interactions:
A message bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different heterogeneous systems to communicate through a shared set of interfaces.
A message bus can be considered as a universal connector between the various enterprise systems, and as a universal interface for client applications that wish to communicate with each other. A message bus requires that all of the applications should use the same canonical data model. Applications adding messages to the bus may need to depend on message routers to route the messages to the appropriate final destinations.

Message Routing Patterns

Almost all messaging system uses built in router as well as customized routing. Message Routers are very important building blocks for any good integration architecture. As opposed to the different message routing design patterns, this pattern describes a hub-and-spoke architectural style with few specially embedded routing logic.

In Search of the Right Router

An important decision for an architect is to choose the appropriate routing mechanism. Patterns that will help you make the right decision are:

• Pipes and filter
• Content-based router
• Content aggregator

Pipes and Filter

Problem:
How can you divide a larger processing task into a sequence of smaller, independent processing steps?
Solution:
Use the pipes and filters pattern to divide a larger processing task into a sequence of smaller, independent processing steps (filters) that are connected by channels (pipes). See Figure 13.

Figure 13. Pipes and filter

Interactions:
Each filter exposes a very simple interface: it receives messages on the inbound pipe, processes the message, performs business transformations, and publishes the results to the outbound pipe. The pipe connects one filter to the next, sending output messages from one filter to the next. It's very similar to execution of a method call through passing parameters and getting a return value. It follows 'chain of responsibility' [11] pattern. Because all components use the same external interface they can be composed into different solutions by connecting the components to different pipes. The connection between filter and pipe is sometimes called port. In the basic form, each filter component has one input port and one output port.
The pipes and filters pattern uses abstract pipes to decouple components from each other. The pipe allows one component to send a message into the pipe so that it can be consumed later by another process that is unknown to the component. One of the potential downsides of pipes and filters architecture is the larger number of required channels that consume memory and CPU cycles. Also, publishing a message to a channel involves a certain amount of overhead because the data has to be translated from the application-internal format into the messaging infrastructure's own format.
Using pipes and filters also improves module-wise unit testing ability. It can help to prepare a testing framework. It is more efficient to test and debug each core function in isolation because we can tailor the test mechanism to the specific function.

Content-Based Router

Problem:
The routing can be based on a number of criteria such as existence of fields, specific field values, and so on.
Solution:
Use a content-based router to route each message to correct consumer based on message content. See Figure 14.

Figure 14. Content-based router

Interactions:
The content-based router examines the message content and routes the message onto a different channel based on message data content. When implementing a content-based router, special caution should be taken to make easily maintainable routing logic. In more sophisticated integration scenarios, the content-based router can be implemented as a configurable rules engine that computes the destination channel based on a set of configurable rules.

Content Aggregator

Problem:
The messaging system exchanges messages between a variety of sources. The messages have similar content but different formats, which can complicate the processing of combined messages. It would be better processing decision if we assigned different components with different responsibilities [11]. For example, if we want to select all of the transactions of a particular customer from different business zones for a particular quarter. This method is called event linking and sequencing.
Solution:
Use a stateful content aggregator, to collect and store individual messages and combine those related messages to publish a single aggregated message. See Figure 15.

Figure 15. Content aggregator

Interactions:
A content aggregator is a special filter that receives a stream of messages and correlates related messages. When a complete set of messages has been received, the aggregator collects information from each correlated message and publishes a single, aggregated message to the output channel for further processing. Therefore, aggregator has to be stateful, because it needs to save the message state with processing state until the complete formation of the aggregation.
When designing an aggregator, we need to specify the following items:

• Correlation ID. An identifier that indicates messages internal relationship
• End condition. The condition that determines when to stop processing
• Aggregation algorithm. The algorithm used to combine the received messages into a single output message

Every time the content aggregator receives a new message, it checks whether the message is a part of already existing aggregate or a new aggregate. After adding the message, the content aggregator evaluates the process end condition for the aggregate. If the condition evaluates to true, a new aggregated message is formed from the aggregate and published to the output channel. If the process end condition evaluates to false, no message is published and the content aggregator continues processing.

Service Consumer Patterns

There are several possible types of Service Consumer. In this pattern catalogue we will present a set of consumer patterns.

Transactional Client

Problem:
Transactions are important part of any messaging system and are sufficient for any participant to send or receive a single message. However, a few specific scenarios might need a broader transactional approach, which in turn may need special transactional coordination. These cases include (but are not limited to):

• Send-receive message pairs. Receive one message and send another.
• Batch message. Send or receive a group of related messages in a batch mode.
• Message/database coordination. Send or receive a message combined with database update. For example, when an application receives and processes a message for ordering a product, the application will also need to update the product inventory database.

Scenarios like these require a different specification of transactional boundaries with much more complexities involving more than just a single message and may involve other transactional stores besides the messaging system.
How can you solve this kind of transactional problems?
Solution:
Use a transactional client—make the client's session with the messaging system transactional and ensure that the client can specify complex transaction boundaries. See Figure 16.

Figure 16. Transactional client sequence diagram

Interactions:
Both participants can be transactional. From a sender's point of view, the message isn't considered added to the channel until the sender commits the transaction. On the other hand message isn't removed from the channel until the receiver commits the transaction.
With a transactional receiver, messages can be received without actual removal of the message from the channel. The advantage of this approach is that if the application crashed at this point, the message would still be on the queue after message recovery has been performed; the message would not be lost. After the message processing is finished, and on successful transaction commit, the message is removed from the channel.

Polling Consumer

Problem:
In any messaging system, the consumer needs an indication that application is ready so that it can consume the message. The best approach for the consumer is to repeatedly check the channel for message availability. If any message is available, the consumer consumes it. This checking is a continuous process known as polling.
Solution:
The application should use a polling consumer, one that explicitly makes a call when it wants to receive a message. See Figure 17.

Figure 17. Polling consumer

Interactions:
A polling consumer is a message receiver. A polling consumer restricts the number of concurrent messages to be consumed by limiting the number of polling threads. In this way, it prevents the application from being blocked by having to process too many requests, and keeps any extra messages queued up until the receiver can process them.

Event-Driven Consumer

Problem:
The problem with polling consumers is that it's a continuous process involves dedicated threads and consumes process time while polling for messages.
Solution:
Instead of making the consumer poll for the message, a better idea might be to use event driven message notifications to indicate message availability. See Figure 18 and Figure 19. The application should use an event-driven consumer. Event-driven consumers automatically consume messages as they become available.

Figure 18. Event-driven consumer

Figure 19. Event-driven consumer sequence diagram

Interactions:
An event-driven consumer is invoked by the messaging system at the time of message arrival on the consumer's channel. The consumer uses application-specific callback mechanism to pass the message to the application.

Durable Subscriber

Problem:
In some cases you might require guaranteed message delivery where a message consumer is not connected to publish-subscribe channel or has crashed before receiving a message. In this case the messaging system needs to ensure guaranteed message delivery when the consumer reconnects to the system.
Solution:
Use a durable subscriber. See Figure 20 and 21.

Figure 20. Durable subscriber

Figure 21. Durable subscriber sequence diagram

Interactions:
A durable subscription saves messages for an off-line subscriber and ensures message delivery when the subscriber reconnects. Thus it prevents published messages from getting lost and ensures guaranteed delivery. A durable subscription has no effect on the normal behavior of the online/active subscription mechanism.

Idempotent Receiver

Problem:
For certain scenarios, instead of using Durable Subscription mechanism, some reliable messaging implementations can produce duplicate messages to ensure guaranteed, at-least once Delivery. In these cases, message delivery can generally only be guaranteed by resending the message until an acknowledgment is returned from the recipient. However, if the acknowledgment is lost due to an unreliable connection, the sender may resend a message that the receiver has already received.
We need to ensure that the messaging system is able to safely handle any messages that are received multiple times.
Solution:
Design a receiver to be an idempotent receiver. See Figure 22.

Figure 22. Duplicate message problem

Interactions:
The term idempotent is originated from mathematics to describe the ability of a function that produces the same result if it is applied to itself, i.e. f(x) = f(f(x)). In messaging Environment this concept ensures safely resent of same message irrespective of receipt of same message multiple times.
In order to detect and eliminate duplicate messages based on the message identifier, the message consumer has to maintain a buffer of already received message identifiers. One of the key design issues is to decide message persisting timeout. In the simplest case, the service provider sends one message at a time, awaiting the receiver's acknowledgment after every message. In this scenario, the consumer efficiently uses the message identifier to check that the identifiers are identical. In practice, this style of communication is very inefficient, especially when significant throughput is required. In these situations, the sender might want to send a whole set of messages in a batch mode without awaiting acknowledgment for individual one. This will necessitate keeping a longer history of identifiers for already received messages, and the size of the message subscriber's buffer will grow significantly depending on the number of message the sender can send without an acknowledgment.
An alternative approach to achieving idempotency is to define the semantics of a message such that resending the message does not impact the system. For example, rather than defining a message as variable equation like 'Add 0.3% commission to the Employee code A1000 having a base salary of $10000', we could change the message to 'Set the commission amount $300.00 to the Employee code A1000 having a base salary of $10000'. Both messages achieve the same result—even if the current commission is $300. The second message is idempotent because receiving it twice will not have any effect. So whenever possible, try to send constants as message and avoid variables in messages. In this way we can efficiently achieve idempotency.

Service Factory

Problem:
When designing service consumer for multiple styles of communication, it might seem necessary to define the service for each style, and this concept can be linked to the Factory Design Pattern [9]. In SOA it's a challenge to invoke the right services based on the style of communication.
Solution:
Design a service factory that connects the messages on the channel to the service being accessed. See Figure 23.

Figure 23. Service factory

Interactions:
A service factory may return a simple method call or even a complex remote process invocation. The service factory invokes the service just like any other method invocation and optionally can create a customized reply message.

Message Facade Pattern

Problem:
Depending on business requirements, you might need to encapsulate business logic flow and complexity behind a standard facade.
Solution:
A message facade can be used asynchronously and maintained independently. It acts as an interceptor between service consumer and service provider. See Figure 24.

Figure 24. Message facade

Interactions:
The client creates a command message and sends it to the message facade through messaging channel. The facade receives the message (using a polling consumer or an event-driven consumer) and uses the information it contains to access business tier code to fulfill a use case. Optionally, a return message is sent to the client confirming successful completion of the use case and returning data.

Conclusion

So far we have understood how messaging patterns exist at different levels of abstraction in SOA. In this paper, which is the first of a two-part series on messaging patterns in Service-Oriented Architecture, Message Type patterns were used to describe different varieties of messages in SOA, Message Channel patterns explained messaging transport systems, Routing patterns explained mechanisms to route messages between the Service Provider and Service Consumer, and finally Service Consumer patterns illustrated the behavior of messaging system clients. In the next issue of JOURNAL, the final part of this paper will cover Contract patterns that illustrate the behavioral specifications required to maintain smooth communications between Service Provider and Service Consumer and Message Construction patterns that describe creation of message content that travels across the messaging system.

Copyright Declaration

G Hohpe & B Woolf, Enterprise Integration Patterns, (adapted material from pages 59-83), (c) 2004 Pearson Education, Inc. Reproduced by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley. All rights reserved.

References

1. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe and Bobby Woolf, Addison-Wesley, 2004
2. Service-oriented architecture: A Primer, Michael S Pallos, EAI Journal, December 2001
3. Solving Information Integration Challenges in a Service-Oriented Enterprise, ZapThink Whitepaper, http://www.zapthink.com
4. SOA and EAI, De Gamma Website, http://www.2gamma.com/en/produit/soa/eai.asp
5. Introduction to Service-Oriented Programming, Guy Bieber and Jeff Carpenter, Project Openwings, Motorola ISD, 2002
6. Java Web Services Architecture, James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, Morgan Kaufman Press, 2003
7. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications, Alan Brown, Simon Johnston, and Kevin Kelly, IBM, June 2003
8. The Modular Structure of Complex Systems, Parnas D and Clements P, IEEE Journal, 1984
9. Design Patterns: Elements of Reusable Object-Oriented Software, Gamma E, Helm R, Johnson R, and Vlissides J, Addison-Wesley, 1994
10. Computerworld Year-End Special: 2004 Unplugged, Vol. 10, Issue No. 10, 15 December 2003—6 January 2004
11. Applying UML and Patterns—An introduction to OOA/D and the Unified Process, Craig Larman, 2001