You can use SOA with other technologies, such as Service Broker. SOA defines the following
four core principles:
• Explicit service boundaries
• Autonomous services
• Explicit data contracts
• Interoperability
As you’ll see throughout this book, you can satisfy these principles better and with more reli-
ability with Service Broker. Explicit service boundaries mean that a SOA service must define a
service contract that exposes the operations available to other client applications. This is impor-
tant when a client uses discovery technologies to find an appropriate service on a network.
An autonomous service is one that a client can use to process a complete business
request. Email, for example, is an autonomous service, because a user request can be com-
pleted with one service interaction. If you want to send an email with an attachment, you can
do it in one step instead of two separate steps. The big challenge when you design your serv-
ices is to find the right granularity and make them as autonomous as possible.
In SOA, the contract defines the contents of the messages sent in both directions. In the
context of Service Broker, you can define the structure of the message body. You have no con-
trol over the structure of message headers. XML messages support interoperability, because
any computer system can exchange and process them.
SQL Server 2008 allows you to expose Service Broker services to other clients through
open standards, such as XML web services. This makes it possible for clients on other plat-
forms, such as Java, to interact with your Service Broker services. You can adhere to all four
SOA principles with Service Broker, making it an ideal platform for implementing SOA.
SODA
SQL Server 2005 offered at first a number of new features, including the following:
• Integration into .NET (SQLCLR)
• Query notifications
• Service Broker
• XML support
• Web services support
Many customers often ask why these features are now integrated directly into the data-

deploy your Service Broker application to an additional SQL Server and make some configura-
tion changes. Service Broker will handle the load-balancing mechanism for you in the
background. Chapter 11 talks more about these scenarios.
Despite these advantages of Service Broker, let’s now take a look at one of the most impor-
tant and familiar messaging technologies available today.
MSMQ
MSMQ has been available as part of Windows since the first version of Windows NT. MSMQ
was the first messaging technology from Microsoft used to provide messaging capabilities for
a wide range of business applications. One of the biggest advantages of MSMQ is that it is
licensed and distributed with Windows, so you don’t have any additional licensing costs when
you use it in your own applications. In addition, it’s not bound to any specific database prod-
uct. If you want to use Oracle with MSMQ, you can do it without any problems. However, as
with every product and technology, there are also some drawbacks, including the following:
• Message size is limited to 4MB.
• MSMQ is not installed by default. Furthermore, you need the Windows installation disk
to install MSMQ.
•Y
ou need distributed transactions if you want to run the message processing and
data-processing logic in one Atomic, Consistent, Isolated, and Durable (ACID)
tr
ansaction. This requires installation of the Microsoft Distributed Transaction
C
oordinator (MS DTC).
• Message ordering is not guaranteed.
• Message correlation is not supported out of the box.
CHAPTER 1
■
FUNDAMENTALS OF MESSAGE-BASED PROCESSING14
• You must implement queue readers manually.
• You must conduct synchronization and locking between several queue readers

Windows. This includes the technologies already mentioned, as well as some others, such as
.NET Remoting. With a unique communication API, you can write distributed applications in
a communication-independent way. During deployment, an administrator can configure
which communication technology the application should use. Microsoft’s Service Broker team
might also include a WCF channel to Service Broker in an upcoming version of SQL Server, so
that you can talk with Service Broker applications directly from WCF-based applications.
CHAPTER 1
■
FUNDAMENTALS OF MESSAGE-BASED PROCESSING 15
Summary
In this first chapter, I provided an overview of the fundamentals of message-based program-
ming. I talked about the benefits of using messaging and how to achieve scalability for your
applications. I then discussed several problems that can occur when using messaging tech-
nology, and I showed you how Service Broker solves these problems so that you don’t need to
bother with them and can simply concentrate on the implementation details of your distrib-
uted applications.
I then described possible application architectures based on messaging architectures
such as SOA and SODA. Finally, I briefly described other messaging technologies available on
Windows and presented the pros and cons for each. With this information, you have all the
necessary knowledge for understanding the concepts behind Service Broker. In the next chap-
ter, I’ll introduce Service Broker itself.
CHAPTER 1
■
FUNDAMENTALS OF MESSAGE-BASED PROCESSING16
Introducing Service Broker
T
his chapter will describe the Service Broker architecture, including the following components:
• Conversations: In Service Broker programming, everything revolves around a conversa-
tion. I’ll explain exactly what a conversation is and what features it offers.
• Anatomy of a service: The core concept behind a Service Broker application is a service.

sender of a message can be sure that the receiving side will receive the sent message
safely—even if the receiving side is currently offline.
• Long-lived: Dialogs can live for only a few seconds, but they can also span several years
for long-running business processes.
• Exactly once: Message delivery in Service Broker dialogs is guaranteed to occur exactly
once. If the initiator service must resend a message because the previous message
didn’t arrive at the sending side, then both messages will be received on the other side,
but only one message will be processed. The other duplicated message will be dropped
automatically from the receiving queue.
• In-order delivery: Service Broker ensures that messages are received in the same order
as they are sent from the initiator service. This addresses the message sequencing and
ordering problem discussed in Chapter 1.
• Persistence: A Service Broker dialog survives the restart of the whole database server,
because messages and dialogs are persisted directly in the database. This makes it easy
to perform maintenance on the database, because when you shut down the database
engine, all open dialogs and even unprocessed messages are persisted automatically
and become available as soon as you take the database engine online again.
Figure 2-1 illustrates a Service Broker dialog.
Figure 2-1. A Service Broker dialog
Dialog Lifetime
Applications can exchange messages during the lifetime of a dialog. The lifetime of a dialog
lasts from the time a dialog is created until another Service Broker service ends the dialog.
Each participant is responsible for explicitly ending the conversation when it receives a mes-
Service A
Database A
Service B
Dialog
Database B
CHAPTER 2
■

• Credit-card validation service
• Inventory service
• Accounting service
• Shipping service
Say the order-entry service starts four different dialogs to each of these individual serv-
ices. Service Broker groups these four dialogs together in a conversation group. These four
services may all respond at nearly the same time, so it’s possible that response messages for
the same order may be processed on different threads simultaneously without being aware
of each other. To solve this problem, Service Broker locks conversation groups—not conver-
sations. By default, a conversation group contains a single conversation—the conversation
started by the initiator service with the target service, the order-entry service. Figure 2-2
illustrates this concept.
CHAPTER 2
■
INTRODUCING SERVICE BROKER 19
Figure 2-2. Conversation groups
The tasks of the four background services that are started by the order-entry service are
normally done in the context of separate local SQL Server transactions. The message exchange
between the individual services takes place in the form of reliable messaging through the
Service Broker infrastructure. As soon as the order entry service receives replies from all of the
background services, it can reply with a response message back to the client and the business
process ends. When this event occurs, Service Broker closes the conversation group. Chapter 6
takes a detailed look at conversation groups and shows you how to achieve effective conversa-
tion group locking.
Message Sequencing
In Service Broker, message sequencing and ordering are ensured in the context of the
complete lifetime of a conversation. Sequencing and ordering are maintained through
sequence numbers, which are incremented for each sent message. If you send six messages,
each message gets a sequence number starting with 1. As soon as a message is sent from the
initiator service to the target service, Service Broker assigns the current sequence number