|
Get Acquainted With SOA and Indigo
Learn about the core principles behind Windows Communication Foundation's service orientation (SO), so you can better understand and create service-oriented applications with Indigo.
by David Pallmann
November 18, 2005
Technology Toolbox: C#, Windows Communication Foundation
This article is excerpted from Chapter 1, "Microsoft Code Name ‘Indigo,' the Microsoft Runtime for Services," of David Pallmann's book, Programming "INDIGO," with permission from Microsoft Press [2005, ISBN: 0735621519, www.microsoft.com/learning/books/]. It has been edited for length and format to fit the magazine. You can read a PDF of the full chapter here.
The drive to connect people, organizations, and devices in new and better ways seems to be never-ending. In the business world, enterprises are demanding seamless communication with their partners and customers without sacrificing essential features such as security, transactions, reliability, and performance. At the consumer level, connectivity is finding its way into everything from wristwatches to automobiles. Distributed systems are becoming the norm. Simply put, the modern application is a connected application.
In response to these trends, connectivity has moved to center stage in software development. Service orientation (SO) is an approach to software design and development that champions this view. In SO design, message-oriented programs called services are the building blocks from which solutions are created.
Windows Communication Foundation (WCF), which was code-named Indigo, is the Microsoft service-oriented communication infrastructure and programming model. You can think of Indigo as the Microsoft runtime for services.
Designing and building good software is somewhat like wearing bifocals. It's important to focus on the big picture first and get that right before examining the finer details of the solution. Architecture is all about figuring out that big picture by separating the important parts of a solution from the less important parts. In service-oriented design, architecture has communication at its heart.
The change in focus makes sense because of the prominent role connectivity is now taking in applications. It's hard to think of an application today that doesn't talk to something else. Everyone and everything needs to be connected, including people and organizations and their devices and data centers. This means communication needs to be a primary design consideration, not an afterthought.
Why do we need a different approach to software development when object-oriented design and programming have served us so well for decades? In one sense, we don't: Service orientation (SO) is a complement to object orientation (OO), not a replacement for it. Object orientation remains important in software development, but objects aren't the best way to tie together the programs in a distributed solution.
The primary distinction between SO and OO is in how you view applications. In a solely object-oriented approach, an application is a tightly coupled collection of programs built from class libraries that have dependencies on each other. An SO application is a different entity entirely, composed of loosely coupled, autonomous service programs (see Figure 1). SO plus OO is a winning combination. You use message-oriented services to build a distributed solution, and you create those services with object orientation.
Service orientation includes four basic tenets: boundaries are explicit; services are autonomous; services share schemas and contracts, not classes and types; and compatibility is policy-based. A true service-oriented solution follows all of these tenets faithfully. Let's see what they're all about.
Boundaries are Explicit
In SO, services interact by sending messages across boundaries. These boundaries are formal and explicit. No assumptions are made about what is behind boundaries, and this preserves flexibility in how services are implemented and deployed. Modeling services in this way allows them to be distributable, meaning they can be deployed anywhere, and composable, meaning they can call each other freely. Managing large, complex projects becomes simpler when formal boundaries are explicit.
Crossing a boundary can be expensive. If services interact across an implementation boundary, a trust domain boundary, or a geographic boundary, there might be a price to pay in terms of processing overhead, performance penalties, or communication costs. For this reason, SO urges discipline in what is exposed to a boundary. It's important to call services only when necessary and to do so as simply and efficiently as possible.
Back to top
|