As Peter wrote in his answer to my last post in this category, there might be some questions in regards to what a "contract" is. I will devote my post to explain this, partly because I've got loads to do at the time being, as well as me being completely worn out.

But what is a contract?

In a SOA perspective you deal with a multitude of services that interact with eachother. Normally, as you might know from your occational open-source project, you would write a service endpoint in WSDL to describe your service. This is more or less a painfull job, and I don't blame you for hating it -- I hate it too.

As I have mentioned earlier, Microsoft has been decent enough to supply us developers with the WCF framework. This framework has a different approach to the WSDL part. Instead of writing the service straight forward and then adding the WSDL, you create an interface with some inline attributes to the interface and to the method declarations. These are [ServiceContract] and [OperationContract] respectively. These attributes has no immediate value for the developer (apart from to some degree show service method invokation flow). When you then host your service, you build a class that implements your servicecontract interface, and implements the methods that are prefixed with the OperationContract attribute. When you then run the service and point a browser to it's endpoint, the WSDL will be generated dynamically, and you don't have to write that. However, this is just a side-effect (i.e. feature) of the WCF.

ServiceContracts has one advantage that you and I cannot disagree on: When you have a service contract that any client relies on, you can update your code-behind (in respect to the service endpoint) without touching the servicecontract, and your v1.0 clients will still be compatible to the v1.2 service. This allows for seamless integration of emergency patches and backwards compability. Backwards compability requires another level of contracting, and I'll get to that now.

Just as you can specify a servicecontract to formalize what methods can be called, you would still want to formalize your data exchange. This is done with data contracts. You might be accustomed to creating export classes that are exposed through the service, and this where the data contracting comes into view.

When you create an export object, you can first define it's members and properties in an interface. This interface will of course be prefixed by the [DataContract] attribute, and it's properties (or public members if you will) will be prefixed with [DataMember]. When implementing this in the export object class, you are in short terms telling the client which data to keep and not to keep. Diving deeper into that matter might require it's own post, so I will urge you to perform a google search about it instead. Either way, you can also give these attributes some properties which defines if they are backwards compatible or not. This actually makes it possible to have a true and seamless backwards compability design in mind when building SOA networks. Messagecontracts is another kind of datacontract, but I'd prefer to leave that to another time being.

But I'm going to leave it with this. I did try Ruby on Rails the other day, and so far I have to admit it was a big yawn.

Today, I ended up having a discussion with a friend of mine (Peter Morris) about opensource, Microsoft, and other subjects that are prone to flaming. This discussion, or argument if you will, inspired me to start writing about, and commenting his blogs in the category Diametrical Opinions. This particular category's purpose is to illustrate technological differences and usabilities, as well as proving that the world of computer science is everything but black and white.

 Today I will start off with explaining why Microsoft and .NET 3.x is everything but a bad choice when developing software.

To begin with, I'd like to pull out a couple of poltergeist abominations technologies from Microsoft's dust-filled locker:

• COM
• COM+
• DCOM
• MDAC
• OLE DB
• MFC

I guess quite a few of you faithfull readers cringe when I mention these, and I do not blame you. Allthough their intended purpose was good, the implementations of these abominations technologies was cumbersome and completely unscalable. Luckilly, for our mental health's sake, these abominations technologies are derelicts from the past, and should be treated that way (i.e. not used).

Microsoft launched their .NET framework around the year 2000, trying to create a new platform for developers to use, and I fo believe it was to be rid of the above mentioned abominations technologies. The .NET framework has undergone two major releases since then, and the largest and most comprehensive came in 2005 when the .NET Framework 2.0 was released. The .NET Framework has since 2005 undergone one major release (NETFX3) and one majon revision (.NET Framework 3.5). I will deep-dive into that in a moment.

With .NET 3.x, developers were given 4 new building blocks for their software development environments; Workflow Foundation, Windows Communication Foundation, and Windows Presentation Foundation. Windows Cardspaces, unfortunately, is not yet deployed on a full scale, and that is the reason why I haven't mentioned that so far.

Workflow Foundation is a platform for maintaining workflows. I know this might be a very shallow description of the matter, but I need to explain a few concepts first. First of all, I'd like to ask you a rethorical question. Spend some time pondering on it before you continue reading. The question is: What is a workflow? Let's say that you are shopping CDs on Amazon.com. When you start shopping, you basket is initialized and is empty to begin with. Once you find some commodity you want to purchase, you add it to the basket. If you want to purchase more, you repeat the last step untill you want to check out the order. Once the order is checked out, you expect to have the order in your mailbox in a couple of days. What we now have described is a workflow.

A workflow can sit persistent in memory, or it can be unloaded into a database untill it receives stimulus from a process, whereupon it is reloaded from database into memory again. This mechanism is provided to prevent workflow hosts to choke on memory usage while waiting for stimulus from outside events. To do this manually, you would have to design a complete database structure for it, as well as creating approx. 20,000 lines of code just to implement the persistence service. In other words, the workflow foundation reduces your implementation workload by far. I will deep dive further into this matter in a later post.

Windows Communication Foundation (WCF) is an api for creating services. In contradiction to common guidelines by opensource fanatics and gnu zealots, WCF operates by defining a service contract which it exposes to a client. Furthermore, any messages going to and from the service, are defined as datacontracts or messagecontracts, depending on what your immediate need for advanced data structure transfer may be. Even better, WCF is SOAP 1.2 compliant, and is perfectly able to communicate cross platform as long as the endpoint respects SOAP 1.2. WCF also removes the all-too-known limitation of web services by introducing tcp services (non-http network), named pipe services (internal memory), and MSMQ (Microsoft Message Queues) amongst others. This gives WCF an edge compared to other competing technologies, but we are not done yet. As you may know, services and SOA is vulnerable to the biggest pitfall of service communications: the request-response model and blocking calls. Up untill today, the workaround for this issue has been to call a service asynchronously, which in turn is just to make the blocking request-response call in a separate thread, and subscribe to an event that fires once the call is completed. I have to admit that this solves the thread block issue, but, to be honest, that workaround is meerly giving the blocking call to another thread that is not the main thread. You may call it treating symptoms. WCF deals with this problem in another fashion, which is to create duplex services with one-way operation contracts, and creating a callback contract with one-way operations to be implemented at the client that the service in turn calls. This allows for full asynchronosity.

Windows Presentation Foundation is another subject, but I will leave that for later. I guess Peter is already cooking up a reply to this. To next time, I want to challenge you, faithfull reader, to present me with some counter arguments and tell me why I am wrong. I hope you will enjoy this battle of academics and software ideology. There will be more to come.