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.

Yesterday, about lunch time (2:00 PM), James -- my colleague and good friend -- called me up and wanted me to come have a drink with him. We started off with the intention of just having a few dew-fresh pints and call it a night, but you know, plans like that will always fail. We ended up drinking non-stop until the football match between germany and spain was concluded, whereupon we decided to go clubbing!

To put that story short, me and James ended up with two british girls at an afterparty. Emma and... shit, I can't remember her name. It was something starting with M. Mercedes? I'm digressing. Emma and... Mercedes and me and James decided to rent a hotel room just for the sake of the breakfast, and this is where the hillarious part comes into the equation. James decides to check out, and I had to go the pharmacy to get some astma-medicine. When I'm back at the hotel room, James had conveniently checked himself out from the hotel, leaving me and the girls up in the room, all alone. So, as I was trying to gather my wits for a moment, one thought appeared in my head: I am alone in a hotel room with two goddamn nice girls. I promptly left. My big question to you, poor reader, is simply: what the heck is wrong with me!? Now, just to make matters even more unbelieveably silly, I managed to return my keycard to the receptionist and tell her that the room was empty. Poor girls. If I meet them again, I'm in for a slap, I presume.

And to you concerned lads and lasses out there; yes, James had the decency to pay the hotell bill before leaving.

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.

You know, when you're starting to build something, you allways end up at the crossroad where you need to decide on a simple, yet threatening matter: start from scratch, or spend time trying to use someone elses work. If you choose the latter option, you will most likely end up with starting from scratch anyhow. This is where I found myself at this late friday night (or saturday morning if you will).

As you may have suspected allready, provided that you don't know me allready, I am a software developer. This means that I am prone to being blamed each time your computer fails, since you probably use something I have made. I hope the series of posts I'm writing might enlighten you on the perhaps worst matter at hand for us developers; foolproofing. But I digress.

At the moment I am writing a web-based application to calculate consume trends (hence the domain consumetrends.net), and as mentioned above, I ended up at that particular crossroad. Needless to say, I chose to reinvent the weel. So far I've come up with some small definitions on what the smallest building blocks should be. First out is the database. Should I use asp datasources, or should I go for an object-oriented data access layer approach? Both approaches carries their own pros and cons, and I have so far decided to go for an object-oriented approach. I will revisit that particular matter in a later blogpost. The database, however, still needs to be defined. Should I foolproof it with built-in constraints, should I go for cascading updates and deletes, should I build my own triggers? Should I rather be more concerned about the object-oriented data access layer's specifics and make it less of a hassle to build it, but then at the expense of database normalization? I guess all options are good in their own scenarios respectively, but which one should I go for? That's the million dollar question.

So far I have decided that I would be able to maintain the best quality of my code while at the same time reducing the ammount of work to a feasible minimum by designing the database within normalization laws, and then use a code generator tool to build the data access layer.

In my next post, I will be discussing the problems with showing data intuitively in a user interface.