WSV201: Indigo Overview

WSV201: Indigo Overview

  • Comments 3

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!

Page 1 of 1 (3 items)