Building transactional services with WSSF

When you are familiair with the WebService Software Factory (WSSF) you probably know that this tool uses three kind of models to make developing services much easier:

  • DataContractModel
  • ServiceContractModel
  • HostModel

In this post I would like to focus on the ServiceContractModel. This model generates messagecontracts and a servicecontracts. The servicecontract looks like a normal  interface where signatures of methods are defined. The only difference is that a servicecontract also contains two kind of attributes:

The properties of both attributes can be modified with the designer of WSSF. One drawback of WSSF is that it’s not possbile to add more attributes to the servicecontract. When you want to build a transactional WCF service with WSSF you have to do some coding by yourself. This isn’t a problem, but the combination of writing your own code and generate code with WSSF could become a problem if you not doing it right.

There are a couple of steps you need to take before your service is supporting transactions. For a guide step by step take a look here. In this post I will only talk about how you should decorate your interface and how to do this with WSSF. In your interface you are able to determine which operation could join or start a transaction. Foreach operation who should be available for a transaction you should decorate the operation with a TransactionFlowAttribute.  

Adding this attribute should be done by hand. When you have decorated your interface correctly and followed the steps in the blogpost above, then your ready to go. But what happens when you have checked in your code and your colleague is working on the servicemodel and clicks on the generate button. You don’t get any errors, but you don’t see any transaction enlisted anymore in your Distributed Transaction Coordinator (DTC). One of the steps you need for a transactional service is removed from your code. The servicecontract is regenerated, this means that the old servicecontract with the TransactionFlowAttribute is replace with the new one generated by WSSF.

I could only think of one solution to avoid such an situation. The solution would be adding the TransactionFlowAttribute to the class (the service) who is also implemeting the interface. This isn’t a perfect situation, but it could avoid strange behavior in your transactional service.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: