[12:31 am] I knew this session would be good when I ran into Benajamin Mitchell totally by happenstance. We’d been playing email tag all day, and then there we were, sitting in the same row. I’ve had good luck meeting people today.
Don’s talk was good. It was essentially a futher investigation of the same things he touched on at the XML DevCon back in July (I have my notes for that in my archive which I can’t get to right now…). Essentially, the message boils down to this: object-oriented programming was a good metaphor for building systems that reside in memory, but that metaphor breaks down when you think about trying to build distributed systems that are stable over time. During the 90’s, MS and others tried to “stretch” the interface-based object metaphor and make it a legitimate distributed platform, but nobody’s succeeded. The problem is that OO systems assume too much shared infrastructure and don’t provide a way of answering the question “what happens when that infrastructure changes?”
The problem is that distributed systems don’t respect logical boundaries. In the real world, there are boundaries that govern human interaction – a point which DBox drove home by hauling a volunteer up on stage and violating both his personal space as well as his privacy (Don asked him how much money he made last year – in front of 1000+ people). Needless to say, that relationship didn’t last very long. If there are logical boundaries that govern human interaction, why aren’t there similar logical boundaries that govern the interaction of software components?
Indigo is a set of API’s that make it easy to create service-oriented software systems on the .NET platform. These API’s are built around four guiding principles:
- Boundaries are explicit. Developers opt-in to exposing service functionality.
- Services are autonomous. Services must be able to be deployed, versioned, secured, and consumed independently.
- Services share schemas and contracts, not classes and types. Integration is based upon message formats and message exchange patterns, not interface congruence and binary compatibility.
- Policy-based compatibility. Instead of a common centralized type system, services use policy to reference well-known semantic elements via XML elements and URI’s.
Number 3 begs the question “what the difference between a schema and a type?” Schemas speak solely in terms of wire format – they define the legitimate contents of a message. Unlike types, which can include both state and behavior, schemas only deal with state. Also, types are absolute – IMarshal is IMarshal, no matter where you are – where as schemas are relative to the client (each client might enforce similar but different schemas on incoming data according to their own needs.
These four design tenets give rise to four areas of note when it comes to writing code:
- Boundaries are explicitly stated in Indigo. Everything that gets exposed to the outside world is done so via metadata, which is orthogonal to the CLR’s notion of accessability. This maintains a mental separation between the internal and external views of the object, as well as making it easier to special-case the inproc scenarios. Consider the following code, which I hurredly copied from the demo:
using System.ServiceModel;
using System.Runtime.Serialization;
[ DataContract ] //Indicates that this CLR type has a
//corresponding schema representation
//More on this in Doug Purdy’s session…
public class Person
{
[DataMember] //opt in!
private int age;
[DataMember] //opt in!
private string name { get{} set{} }
}
[Service] //explicit opt-in mechanism
public class MyService
{
[ServiceMethod] //note that this is applied to a private method!
//Accessability to services is independent from CLR
//accessibility. This lets to treat the in-proc
//scenario differently
private void f(Person p){}
public void g(){}
}
2) Indigo and unification -- the grand unified XML architecture. In the 1.x framework, there are at least 3 API’s for doing interservice communication (ASMX, .NET remoting, and Enterprise Services). These 3 disparate API’s will be semantically combined in Indigo. One API to rule them all!
3) Indigo and Interoperability. Indigo is built with the full knowledge the not everyone will have Indigo. On the wire, it speaks purely WS-* compliant XML, making it interoperable with other implementations of those specs.
4) Indigo and Continuity. There’s a large amount of non-Indigo code already out there, and Microsoft recognizes this. Although the PDC bits do not include this functionality, there will be ways to interop Indigo with COM+, MSMQ, and Enterprise Services.
Going forward, the best way to future-proof your existing applications is to make sure that they communicate with the outside world via ASMX/WSE. Although these implementations are not perfect, they are least flawed. Inside of that boundary (where you have control of the deployment and evolution of the system), use Remoting or ES as needed. But whenever you’re going to be talking to another entity that’s outside of your direct control, communicating with that entity via the existing Web Services technologies will ease your transition to Indigo.
More on these topics tomorrow after the Indigo drill-downs, which I will be attending with great vigor.
