Beginning Web Development, Silverlight, and ASP.NET AJAX

160
CHAPTER 7 ■ .NET 3.0: WINDOWS COMMUNICATION FOUNDATION
WS-Transactions
The WS-Transactions specifications define the mechanism for how applications running
across Web Services domains can interoperate in a transactable manner. It is also
designed to provide a means of composing transactional quality-of-service attributes
into Web Services applications. The transaction standards are built on a number of other
standards, including WS-Coordination for an extensible coordination framework, and
specific types for different types of transactions, such as short-term atomic ones (WS-
AtomicTransaction) and longer-running business transactions (WS-BusinessActivity).
WCF aims to allow these diverse specifications to be programmable using a single attribute-driven
API. Later in this chapter, you’ll build some simple WCF applications that
implement security, reliability, and transactability under the hood so you won’t have to
worry about the complexity of dealing with their messaging structure manually.
WCF and Service Orientation
Software as a Service (SAAS) is a major initiative for the future of the Web. This is an evolution
of Service-Oriented Architecture (SOA), where a paradigm shift in how software is
developed is taking place. Instead of thinking of traditional application development,
developers are encouraged to think about small, nimble, reusable components, and to
build these as services that can be exposed reliably and securely across the network.
These components can then be assembled into distributed applications. Using next-generation
presentation technology, these applications can provide a great user experience.
At the heart of it all is the question of how we reuse the code that we write. We want
long-term returns on our investments in building software assets—but how do we
achieve this
In the 1980s, object orientation was the craze. It was based on the idea of building
reusable abstract definitions of functionality (called classes), which provided the template
for objects, and for more complex inherited objects. So, for example, a class that
defines a type of object called a “car” could be defined, and a more sophisticated object
called a “sports car” could derive from this, inheriting (and thus reusing) the attributes of
the original “car” class. In a world where code was written procedurally, and most reuse
was in cutting and pasting code from one routine to another, this was revolutionary. It
brought about new benefits such as polymorphism, where dynamic binding to methods
and events could happen at runtime, and encapsulation, the facility to hide and expose
certain parts of your code to the outside world. However, the drawback was that once an
application was built, it was built, and it was static. There was no easy way to put new
functionality into an application other than to recode, rebuild, and redeploy it.
Later, the concept of components evolved from object orientation. It was designed to
make the developer think about the external interface of their application and how other
people could use it. Now an application could load and bind to new functionality at