Data Contract vs Message Contract Guidance

Topics: Service Factory Modeling Edition Forum
Feb 11, 2008 at 8:33 PM
I know this topic has been touched upon before, but the associated threads did not cover my specific question.

First, I understand the general guidance regarding when to use a message contract. That is, use a message contract when you need more control over the message.

My question regards the Service Factory Modeling Edition (SFME). As far as I can tell, the DSL modeler in the SFME does not allow you to associate anything except a message contract (or XSD Message) with an operation. Is this implied guidance or just a limitation of the current version of SFME? In other words, is the SFME recommending that all requests and responses be message contracts? Certainly, if you wanted to use a data contract instead, the SFME wouldn't expect you to manually modify the underlying XML for the contract as this would totally negate the value of having an updatable model.

Hopefully, I'm just missing something - help, please.

Thanks,
Brian
Developer
Feb 12, 2008 at 3:33 PM
Brian,

As you pointed out in your question, the recommendation in WSSF ME is to use MC that wraps DC or primitive types, or in case of schemas, the XsdMC. I also agree that you may not manually update the XML for the reason you mentioned unless you have a particular scenario where you need to get your DCs out of MCs and referenced directly in your operations. In this case, the MC not only serves the purpose of giving you more control over the message but also provides you with an explicit implementation of the Request/Response pattern wrapping your data into MC properties.
Feb 13, 2008 at 2:09 AM


charlyfriend wrote:
Brian,

As you pointed out in your question, the recommendation in WSSF ME is to use MC that wraps DC or primitive types, or in case of schemas, the XsdMC. I also agree that you may not manually update the XML for the reason you mentioned unless you have a particular scenario where you need to get your DCs out of MCs and referenced directly in your operations. In this case, the MC not only serves the purpose of giving you more control over the message but also provides you with an explicit implementation of the Request/Response pattern wrapping your data into MC properties.


Hi,

Thanks for confirming my thinking regarding the modeling edition guidance. I really appreciate the work P&P and all of the contributors put into the guidance and tools. It is great stuff! The only trouble I have sometimes is understanding emerging guidance, but I guess that is the nature of the beast.

Thanks again for the great work.

-Brian
Mar 7, 2008 at 5:40 PM
Charly,

Does the SFME documentation include any discussion on the recommended use of Message Contracts and/or the Request/Response pattern? This topic has come up on my team and I wanted to refer people to the P&P guidance on this, but this thread is the only reference I've found that mentions this being the recommendation. If this doesn't exist in the docs, I think there needs to be some clear and explicit discussion around this topic since books like Programming WCF Services by Juval Lowy basically say you will rarely use Message Contracts. I seem to recall some discussion around this in the first version's docs. Thanks.


Derek
Coordinator
Mar 11, 2008 at 2:17 AM
I know I've answered this before, but because I can't find it, I'm happy to state our rationale again. I've also blogged this post here.

If you ask the WCF product team when you should use a MessageContract versus a DataContract, their guidance usually revolves around the level of control you need over the message - like when you need to use custom SOAP headers*. You can find more detail in this topic of the WCF documentation. Their guidance makes complete sense if you think about the motivation they had when building WCF: to unify all of the Microsoft communication mechanisms into a single approach that is relevant to all scenarios. This is great for someone who has traditionally only done object-oriented or component-oriented development. They can be successful without understanding the nuances of building Web services.

In our experience the biggest hurdle for many developers new to Web services has been the concept of the message - rather than just passing around types like they've always done. You can characterize this distinction as implicit versus explicit message design. We have a topic in the Service Factory documentation that touches on this distinction. I think there is some room for improvement on this topic, but you can find it here nevertheless.

However, the confusion over a message isn't the only reason we elevate the importance of the message and recommend these usage patterns. We intentionally draw a clear distinction between types (both primitve types like string, and complex types like Customer) and messages (like ProcessExpenseReportRequest). From our perspective, DataContracts represent types and types are reusable. Messages are not used as types but rather the payload a method operates on - and it is not reusable. This level of distinction provides architects and lead developers a means of achieving better consistency throughout their organization by being more prescriptive about reusability.

I am aware that Juval's position is that MessageContracts are rarely needed. And, I hold Juval in the highest regard - I've not yet had an opportunity to learn what is motivating him to take this position. Some might argue that MessageContracts are just an additional (unneccessary) level of redirection. I can understand this point of view. We just feel the benefits greatly outweigh this nominal cost, and the feedback we've received from customers has been completely supportive of this approach.

* In my opinion, there is only one reason you would need to create a custom SOAP header that isn't already defined by a standards body like WS-*. (hint: if it's already defined elsewhere, you should use it to ensure interoperability, instead of "rolling your own") And, that reason is if you need to pass around localization information (like "en-us"). I don't think this is covered by any WS-* or other spec.
Mar 11, 2008 at 2:09 PM
Donsmith, I pretty much understand your rationales behind the recommandation using MC. But I still believe in many cases, users prefer DataContract. So why don't SFME just add this kind ability to the model designer so that users have options to choose to fit their specific cases? Is it too hard to implementate or you just leave that out to enforce MC usage? In current version of SFME, is there any workaround that we can use to use DC instead of MC?

Thanks,

-Anthony
Coordinator
Mar 11, 2008 at 10:09 PM
panthony, I would have to dig into the code to determine how difficult it would be to also allow DCs to be sent/received from the operations, but if I had to guess ... yes, it would be pretty involved (non-trivial). Enabling this capability (and testing it) just wasn't justified at the time since we felt this was the right approach and customers were agreeing.

With that said, I can still understand that some people may just have a preference. We haven't worked out what it would take to make this change so I really shouldn't speculate. But I can tell you that if anyone does work it out, I'm more than happy to help promote their work on this site.