WSV201: Indigo Overview


No software is an island. Every piece of code, dating right back to K&R’s “Hello,
world!” C program relies on another program (in the K&R case, the standard I/O
library). Over the last thirty years we’ve moved through the genesis of the “object
ecosystem” to the point where we couldn’t imagine doing things any other way. Yet
it’s only recently that objects have become an integrated and deep element of the
operating system platform. Even Windows XP and Windows Server 2003 are primarily procedural
and C-orientated.

Only with Longhorn do we have a mainstream operating system whose primary access mechanism
is object-based. As Avalon is a replacement from the old days of cracking LPARAM messages
and dealing with hWnd handles, so Indigo is a replacement of the old socket-based
APIs and other communication mechanisms.

The same metaphors that are used when developing code in an isolated system are not
necessarily the same metaphors that need to be used when considering a distributed
system. Object orientation has a very high level of reliance on common technologies
– a type system, a language, an operating system. In a distributed environment such
close affinities are rarely possible; the model has gradually been stretched beyond
breaking point.

The experience of SOAP has introduced a new consideration: perhaps there’s a new metaphor
(that of a service) that can be used to connect programs – not just across systems
but even within a local system. The concept of a service-orientated architecture (SOA),
as opposed to an object-orientated architecture, relies on a very strict
boundary between programs.

In the SOA world, we have services, clients and messages. A service is a
program with which you communicate using messages. A client is just another
program that accesse a service. How does it use the service? It sends a message.
In a SOA, the application isn’t the interesting outcome of development; instead, a
system (that may evolve over time and have little in the way of static pieces) is
the outcome.

There are four key premises of a service-orientated architecture:

Tenet 1: Boundaries are Explicit
As a programmer, I need to be clear as to where the boundaries of my application
lie. The idea that you can take an application and easily create these boundaries
may be naïve.

Tenet 2: Services are Autonomous

I need to make sure that my program works even if yours does not. My program has responsibilities
– there is an expectation of reliability, for instance. Most importantly, there is
a 1000x greater requirement to be secure – I can’t be sure who will access my application
and whether they can be trusted or not. While it might be interesting to roll your
own graphical framework, the one thing you should never be re-implementing is the
security architecture.

Tenet 3: Share Schema, Not Class
Integration is based on message formats and exchange patterns, not classes
and objects. In an autonomous system where things are constantly changing, it’s extremely
difficult for two parts of a service to share an object. Instead, we either share
schemas or contracts. Schemas describe structures only (representation); contracts
describes a set of message exchanges between services in terms of behavioural interactions.

Tenet 4: Policy-based Compatibility
Because we have schemas and contracts which may need to evolve, we can’t
assume a centralised common type definition. Much of the original work on XML Schema
made that assumption. The idea that we have a shared schema that can be stored in
a centralised repository is in error. In a service-orientated architecture, we achieve
compatibility by means of a policy. We establish whether programs are compatible not
by means of a shared schema but using a global name.

These principles can be used now – ASP.NET Web Services is the closest solution currently
available for adopting a basic service-orientated architecture.

The easiest way to compare the object- and service-orientated approaches is to compare
.NET Remoting and ASP.NET Web Services. .NET Remoting is perhaps the finest example
of a distributed object-orientated architecture. The problem is that it is too easy
to use some of the object-orientated features in .NET Remoting, and thereby move away
from a SoA. ASP.NET Web Services is not perfect by any means, but it provides a clear
boundary (for example as regards proxies).

Indigo fills many roles for a SoA developer, allowing for the construction and deployment
of services within systems. It does not presume that the entire world has Indigo or
even Windows. Physically, Indigo is a bunch of DLLs that ship with Longhorn. It does
not require Longhorn, but also will run on Windows Server 2003 and Windows XP by the
time it ships. You’ll be able to install it in the same way as the Framework itself
is installed.

The ServiceModel namespace provides basic support for an Indigo service. There is
a connector that allows you to hook up to other services, as well as multiple hosts
for Indigo services. Finally, there are a series of system services that can be used
in the environment (such as transactions).

Here’s a very simple Indigo service:

        using System.ServiceModel;

        [DataContract]
        public class Person
        {
        [DataMember]
        private int age;
   
        [DataMember]
        public string name { get { ... } set { ... } }

        [DataMember]
        public bool isTired;
    }
 
    [Service]
    public class MyService
    {
        [ServiceMethod]
        private void f()
        {
        }
        
        public void g() 
        {
        } 
    }

Note that it doesn’t matter whether an object is accessible from the rest of the CLR:
it’s the decoration that defines whether an object is service-accessible. Note too
that it is an “opt-in” model – everything that is used must be explicitly declared.

Indigo unifies ASP.NET Web Services, .NET Remoting and .NET Enterprise Services. You
don’t have to make a choice on which technology to choose based on which subset of
services are required. This will obviously make the architectural choice far simpler!
The WS-I specifications are built into Indigo. WS-Security and WS-Transaction are
built into Indigo, for instance. Finally, the transition will be simple for the existing
choices. To prepare for Indigo, use ASP.NET Web Services today (optionally with Enterprise
Services).

In summary, we’re perhaps heading towards the end of the arc for object-orientated
technologies, and are at the earliest stages of the arc for service-orientated technologies.
This is a new journey!


Comments (1)

  1. Anonymous says:

    Nice one Tim! Thanks 🙂