Datasheet

The other internal systems can still communicate and exchange information with these services without
any changes. Externally, Joe Reader and the National Book Seller have no idea that changes were made
at the publisher’s end — it is all transparent to them. In fact, they might even see a better responding sys-
tem when placing orders. The key here is that with SOA, major changes can take place behind the scenes
completely transparent to the end user and without any interruption of the system.
Software as a service is not a new concept, and in fact if you have been using web services you can start
to see where this is going. One could argue that web services was the first step on the road to SOA. Is
that statement true? Yes and no. No, in that you can have an SOA solution without using ASP.NET web
services. Yes, in that it is a great beginning to something much larger.
It is possible to have a web service that follows no SOA principles and a web service that exhibits won-
derful SOA traits. For example, a good web service is almost self-describing, providing useful informa-
tion. I want to hit a web service that gives me stock quotes, or lets me buy or sell stocks, or tells me how
my portfolio is doing. In the case of the book publisher, I want a web service that tells me information
about my order. These are web services that exhibit SOA traits.
In contrast, a web service that provides reads as well as writes data to my database shows no SOA. Now,
don’t get me wrong. Those types of web services have their place and provide great benefits (I have
written a few myself). But they don’t fit in the SOA realm and don’t conform to the SOA principles.
So what are these principles?
Service-Oriented Architecture Principles
Streams of information have been flowing from Microsoft in the forms of articles and white papers
regarding its commitment to SOA, and in all of this information one of the big areas constantly stressed
are the principles behind service orientation:
❑ Explicit boundaries
❑ Autonomous services
❑ Policy-based compatibility
❑ Shared schemas and contracts
Explicit Boundaries
As you will learn in the next section, SOA is all about messaging — sending messages from point A to
point B. These messages must be able to cross explicit and formal boundaries regardless of what is
behind those boundaries. This allows developers to keep the flexibility of how services are implemented
and deployed. Explicit boundaries mean that a service can be deployed anywhere and be easily and
freely accessed by other services, regardless of the environment or development language of the other
service.
The thing to keep in mind is that there is a cost associated with crossing boundaries. These costs come in
a number of forms, such as communication, performance, and processing overhead costs. Services
should be called quickly and efficiently.
7
Chapter 1: Windows Communication Foundation Overview
05_089842 ch01.qxp 3/5/07 7:02 PM Page 7