none
Message Contract RRS feed

  • Question

  • HI there

    I was watching a tutorial on WCF to recap some of the basic idea I might have got confused at the first place. I have got the following questions:

    1. Is WCF by default using SOAP to pass messages between tiers?
    2. I understand that Message Contract gives extract controls over the SOAP message. But I only treated it as a wrapper class to my DTOs, which the non database related information could be encapsulated into single request/response object to simplify the method calls. Is this good enough reason of picking Message Contract over typed message? what is the performs hit?
    3. What is the pros and cons of using Message Contract over typed message.

    Thanks alot!

    Wednesday, February 25, 2009 8:22 AM

Answers

  • 1) Yes the default is SOAP messages unless you use the POX/JSon encoders (webHttpBinding uses this for REST based services)
    2 and 3) You need to be careful to distinguish between a MessageContract that defines the SOAP message (body and headers) but which is a stringly typed message - e.g.

    [DataContract]
    class Person
    {
       [DataMember]
       public string Name;
       [DataMember]
       public int Age;
    }

    [MessageContract]
    class PersonMessage
    {
        [MessageHeader]
        public string Originator;.

        [MessageBodyMember]
        public Person person;
    }

    [ServiceContract]
    interface ISendStuff
    {
       [OperationContract]
       void SendStuff( PersonMessage msg);
    }

    and contrast that to a contract that uses the Message type

    [ServiceContract]
    interface ISendStuff
    {
       [OperationContract]
       void SendStuff( Message msg);
    }

    with the latter you don;t have strong typing but instead you work at the XML level (e,g, Message.GetReaderAtBody()). This gives you a huge amount of flexibility in terms of message processing allowing a single operation to process an arbitrary large number of types of messages. However, you have heavier lifting in terms of processing the message as  you get no auto deserialization. Also you will not get strong typing in the auto-generated metadata for the operation
    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Wednesday, February 25, 2009 8:15 PM
    Moderator
  • -> code 2 and 3 do the same trick I understand that code3 could provide more in security extension, other than that is there any other reason I should choose one over the other?

    It depends what your scenario, if you want to have full control over the SOAP message format, aka what should be put inside the SOAP body, and what should be putted inside SOAP header, please go with MessageContract.

    DataContract specifies things which will always put inside the SOAP body unless you use some out of band technique to put it inside the SOAP header.

    Hope this clears things up a little bit.


    Another Paradigm Shift
    http://shevaspace.blogspot.com
    Friday, February 27, 2009 11:26 AM

All replies

    • Proposed as answer by Adil Mughal Friday, February 27, 2009 11:05 AM
    Wednesday, February 25, 2009 3:01 PM
  • 1) Yes the default is SOAP messages unless you use the POX/JSon encoders (webHttpBinding uses this for REST based services)
    2 and 3) You need to be careful to distinguish between a MessageContract that defines the SOAP message (body and headers) but which is a stringly typed message - e.g.

    [DataContract]
    class Person
    {
       [DataMember]
       public string Name;
       [DataMember]
       public int Age;
    }

    [MessageContract]
    class PersonMessage
    {
        [MessageHeader]
        public string Originator;.

        [MessageBodyMember]
        public Person person;
    }

    [ServiceContract]
    interface ISendStuff
    {
       [OperationContract]
       void SendStuff( PersonMessage msg);
    }

    and contrast that to a contract that uses the Message type

    [ServiceContract]
    interface ISendStuff
    {
       [OperationContract]
       void SendStuff( Message msg);
    }

    with the latter you don;t have strong typing but instead you work at the XML level (e,g, Message.GetReaderAtBody()). This gives you a huge amount of flexibility in terms of message processing allowing a single operation to process an arbitrary large number of types of messages. However, you have heavier lifting in terms of processing the message as  you get no auto deserialization. Also you will not get strong typing in the auto-generated metadata for the operation
    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Wednesday, February 25, 2009 8:15 PM
    Moderator
  • thanks Richard!

    My quesiton would be clearer, if I put it as "Parameter-based programming vs message-based programming".

    I was trying refactor the operation contracts.

    From this - only the retrieved object is returned, need to include fault messages, and other notifications
    code 1:
    public DTO Retrieve( string ObjName, Guid id, AccessToken token, string[] childObjs2Loadwith...)

    TO this - Wrapped-Class is declared with [DataContract] attribute, a Parameter-base approach
    code 2 :
    public WrappedReturnObject Retrieve( WrappedObject obj)

    Or this, req-resp classes are declared with [MesageContract] attribute, and implemented them into Request-Repsond pattern, a message-base approach
    code 3 : 
    public RetrieveResponse Retrieve ( RetrieveRequest msg)

    code 2 and 3 do the same trick I understand that code3 could provide more in security extension, other than that is there any other reason I should choose one over the other?

    thanks
    Thursday, February 26, 2009 5:28 AM
  • -> code 2 and 3 do the same trick I understand that code3 could provide more in security extension, other than that is there any other reason I should choose one over the other?

    It depends what your scenario, if you want to have full control over the SOAP message format, aka what should be put inside the SOAP body, and what should be putted inside SOAP header, please go with MessageContract.

    DataContract specifies things which will always put inside the SOAP body unless you use some out of band technique to put it inside the SOAP header.

    Hope this clears things up a little bit.


    Another Paradigm Shift
    http://shevaspace.blogspot.com
    Friday, February 27, 2009 11:26 AM