Couple of questions

Topics: Service Factory Modeling Edition Forum
Jun 15, 2009 at 11:36 PM
I've only just started using WSSF, but I'm very impressed. It is a very complicated tool, though, so before I try to persuade all our developers to use it, I'd like to think I've got most of the answers to the questions they're likely to ask. So here's two that occurred to me as I was working on a project today: 1) The sources I've looked at say to paste the url in the Action property into the Reply Action property in the service contract properties window. Is that always the case? Or is there a bit more to it than that? 2) I've also noticed that the books I've seen, say to change the Is Wrapped property to True for request messages. Is it only request messages where this should be done? Why should request messages be wrapped? When you're learning something you just tend to accept instructions like these blindly. It's only when you take a step back that you think, 'ang on! Why am I doing that? Grateful thanks for any explanations. Cheers Peter
Jun 16, 2009 at 2:43 PM

Hi Peter,

Regarding your two questions, you can take a look at these post that might shed some light on;

This post from Don give some insight about Message Contract design considerations that refer to a MC link with some comments about Action and IsWrapped property usage; http://msdn.microsoft.com/en-us/library/ms730255.aspx

 

Jun 16, 2009 at 6:50 PM
hernandelahitte wrote:
>
> From: hernandelahitte
>
> Hi Peter,
>
> Regarding your two questions, you can take a look at these post that
> might shed some light on;
>
> This post from Don <http://blogs.msdn.com/donsmith/default.aspx> give
> some insight about Message Contract design
> <http://blogs.msdn.com/donsmith/archive/2008/03/10/using-messagecontracts-and-datacontracts.aspx> considerations
> that refer to a MC link with some comments about Action and IsWrapped
> property usage; http://msdn.microsoft.com/en-us/library/ms730255.aspx
>

Hmm. Thanks very much for that, but I can't say I'm much the wiser, I'm
afraid. The first link looked like an exhortation to use messages,
which I do anyway unless an operation takes no parameters, in which case
I don't use a request message. I'm guessing we're talking about a SOAP
wrapper here? The whole thing just raises so many more questions than
it answers. Why should we only wrap request messsages? Or should we
really wrap both request and response messages if we want to comply with
standards? Why is the Wrapped property False by default in WSSF? What
are the advantages/disadvantages of wrapping requests/responses?

On the question of the Action property and the Reply Action, I imagine
that the Action property reflects the SOAP action: but what is the Reply
Action, and why are we told (in Mike Liu's book - recommended elsewhere
- anyway) to just copy the one to the other? If this is always the
right thing to do, why is it not done automatically? Or are there
occasions when we would not want to just do a copy and paste?

Sorry if I'm being a pain, but I really would like to understand, so
that I can do the right thing when I need to.

Cheers


Peter
Jun 16, 2009 at 8:56 PM

The IsWrapped property will give you some control over the message on the wire in terms of the XML node representation. While setting as true, will generate a complex type (regarding the WSDL/XSD schema type) and that will give you some differences on how you generate your client proxy and the serialization process as well (you may use the DataContract serializer instead of the XmlSerializer depending on the scenario and SC definition).

There are some threads that may give some examples about this: http://servicefactory.codeplex.com/Thread/View.aspx?ThreadId=31162

The action property will also give you some control over the message in terms if giving a particular "ID-like" to your operation. The same goes to your Response message. Again, setting these values will give more control over the message on the wire and you can also comply with some public defined contract or customs requirements to meet by your contract definition. 

 

 

Jun 16, 2009 at 10:43 PM
hernandelahitte wrote:
>
> From: hernandelahitte
>
> The IsWrapped property will give you some control over the message on
> the wire in terms of the XML node representation. While setting as
> true, will generate a complex type (regarding the WSDL/XSD schema
> type) and that will give you some differences on how you generate your
> client proxy and the serialization process as well (you may use the
> DataContract serializer instead of the XmlSerializer depending on the
> scenario and SC definition).
>
> There are some threads that may give some examples about this:
> http://servicefactory.codeplex.com/Thread/View.aspx?ThreadId=31162
>
> The action property will also give you some control over the message
> in terms if giving a particular "ID-like" to your operation. The same
> goes to your Response message. Again, setting these values will give
> more control over the message on the wire and you can also comply with
> some public defined contract or customs requirements to meet by your
> contract definition.
>
>
>

OK. Thanks a lot.

I'll check out your link. Thanks for your patience.

Cheers


Peter
Sep 2, 2009 at 2:14 PM

I thought I might add a little to this post, as I've recently encountered an issue that I had to burn through an MSDN Help ticket to resolve. If you set any MessageContract.IsWrapped property = true, then you MUST set ALL MessageContract.IsWrapped properties = true that are associated to a specific Operation or you may experience problems when the ClientProxy is generated.

The problem I was getting when the RequestMessage.IsWrapped = true, and the ResponseMessage.IsWrapped = false was that the ClientProxy generated a RequestMessage object with only one Member, which was Nodes (Xml Nodes of course). So when I attempted to create a new RequestMessage and set it's Member properties, they were not available.

The resolution was to set both the RequestMessage.IsWrapped = true and ResponseMessage.IsWrapped = true, and both objects generated properly in the ClientProxy.

Sep 2, 2009 at 3:00 PM

Good catch Sam, this might be a good candidate to be added as a validation rule so you don't need to remember this constrain for future contract settings like this one.