Architect or Cobbler?
Good code starts with good design

Contracts in Indigo

Tuesday, May 10, 2005
Yesterday, I spent some time going around in circles talking about services, today I want to introduce you to Indigo, Microsoft's new programming model for doing service oriented development. It will ship with Longhorn, so the official story is 2006, but in the meantime you can get your hands on Community Technology Preview and (any day now, so I believe Beta Releases (The beta is currently at Release Candidate, although there's an oxymoron - a beta release candidate). So enough background - let's look at some code.

You may have guessed with my focus yesterday, that I believe the best way to code up services is by defining the contract first, and that is the Indigo preferred method as well. Attributes are provided in the System.ServiceModel namespace that allow you to decorate an interface (that's right - the interface, Indigo gives you mechanisms to annotate an implementation class as the contract, but don't do it, not ever, not even as a quick test, just avoid the temptation to do code-first service development).

So here we go, a service for placing orders may be described as follows

using System.ServiceModel;

namespace BasicService
{
[ServiceContract(Name="My First Indigo Service",
Namespace="http://www.qacommunity.com/services",
Session=true,
CallbackContract=typeof(IOrderCallback))]
public interface IOrderContract
{
[OperationContract(IsOneWay = true)]
void PlaceOrder(Order order);
}

[ServiceContract(Name="My First Indigo Callback",
Namespace="http://www.qacommunity.com/services")]
public interface IOrderCallback
{
[OperationContract(IsOneWay = true)]
void PlaceOrderCompleted(OrderStatus orderStatus);
}
}


A couple of things here - the ServiceContract exposes the interface as a Service, and the OperationContract basically lists the operations that will be exposed in the WSDL in the
portType section. Unlike asmx, this service does not necessarily have to be bound to SOAP
over HTTP, and we'll see how we specify the binding some other time. The second thing should blow you away, I am specifying a duplex service, other clients must provide a PlaceOrderCompleted service in order to use my service, as a colleague of mine might say -
"this is way cool".

Those of you familiar with the asmx implementation will know that Order instances will be serialized into XML by the XMLSerializer, here is one of Indigos neat features (and one that will be available in the .NET 2.0 framework, yippee), the ability to create a versioned data contract (much more on this on another occasion) and serialize this to XML using an XMLFormatter, so the data contract for the Order class might be specified as follows:

using System.Runtime.Serialization;

namespace BasicService
{

[DataContract(Name="OrderType")]
public class Order
{
[DataMember]
public string Description;

[DataMember(Name="Quantity")]
private int quantity;

[DataMember(Name="Price")]
double price;

public int Quantity
{
get
{
return quantity;
}
set
{
quantity = value;
}
}

public double Price
{
get
{
return price;
}
set
{
price = value;
}
}
}

[DataContract(Name="OrderStatusType")]
public class OrderStatus
{
[DataMember]
private string description;

public string Description
{
get
{
return description;
}
set
{
description = value;
}
}
}
}

Can I hear the big hurrah at the back? At last the ability to serialize private fields.

You'll have to wait till tomorrow to write the service implementation, which in Indigo terminology we call the ServiceType, as it's getting late and the bar is calling.

# posted by James @ 10:22 PM   1 comments

Playing with Indigo

Monday, May 09, 2005
I've just got back from Reading where I'm attending an Indigo Ascend program, and actually getting some hands on with the technology. It was also good to some old familiar faces, and nice to see so many people with a J2EE background there. So far it looks an interesting technology for connecting services together, which brings me nicely to today's topic - just what is a service? We've just started refining our design courses and we're having the same internal debates that many architects are having. Like what exactly distinguishes service orientation from object orientation? Is a service interface just a fancy extended component interface, a la COM+ and EJB?

If you look around for a definition you'll get many different definitions of what a service is, but for me they all share some common features.

A service exposes a contract - preferably as interoperably as possible, but many service contracts are not, due to the fact that many developers create the contract from the implementation of the service. Many people equate services with web services, and in this guise the WSDL fulfils the role of contract.

A service is autonomous. This means that any service is always available (well, within reason) and is developed, deployed and tested in isolation of other components (contrast this with OO, where typically we can achieve something like autonomy, but the tight coupling between cients and servers means that even if we don't develop them together the teams have to be talking to each other all the time, and they will be developed in similar time frames). The real impact here to my mind, is that once you put a service out there, you end up running several versions concurrently, as the business needs change. I know that versioning is an issue with OO systems as well (just ask anyone who's used XML parsers), however you have much more control typically, you can for instance retire clients when new versions are released, you will seldom have this luxury with truly loosely coupled services. Amazon's ECS (e-commerce services) are a classic example of this. It is currently V4.0, but supports V3.0 clients and looks like it will for some time. I don't care how Amazon achieves this trick, but it does mean my ECS 3 client still works.

Services explicitly reveal their endpoints - this is particularly novel. I've been a CORBA and EJB developer for some time (and occasionally dabbled with COM+ as well, just to see how the other half live), and there the mantra has always been location transparency. As someone who has suffered in early EJB implementations with subtle bugs due to app servers trying to optimise some calls out of the RMI stack when beans were co-located, I actually like this. EJB 2.0 acknowledged this problem, and now you have to explicitly indicate local or remote invocation for your EJB. Services, on the other hand are nearly always remote (ignoring for now that rather strange WSE inProc mode), and you need to invoke them using explicit messaging.

All of this leads to some rather glaring differences when designing a service oriented contract to developing a component interface. The first difference is that services simply pass data around (there is no behaviour in the parameter model, as you are typically serializing to an XML message), therefore services are much more likely to have coarse grained methods that take data structures as arguments. Another problem is that unlike OO programming I have no (or limited) control over my clients, for instance I may have a service submitOrder(Order order) that is publicly available. Anyone could now call this service, so most services access will be controlled by policy rather than programatically.

So in a nutshell, service orientation is different to object orientation, and simply refactoring component interfaces as web services, as the ASMX model promotes, is not the way to go. From what I've seen so far, the designers of Indigo have realised this, and over the next few blogs I'm going to be diving into the guts of Indigo to look at how it promotes service oriented development.

# posted by James @ 8:04 PM   0 comments

Getting Started

Monday, May 02, 2005
I'm sitting here with Dave in Beijing discovering the joys of blogging. This blog will discuss some of my thoughts about design and good design practice. I'll try to post (blog, see I'm still getting used to this) regularly, but don't expect me to be as prolific as Dave.

There will be code from time to time, but mostly it willl be musings

# posted by James @ 6:20 AM   0 comments
This page is powered by Blogger. Isn't yours?