none
How to modify response from WCF service RRS feed

  • Question

  • I am facing a huge problem with my WCF service. I am trying to modify response messages (remove some properties from output in some cases or override schema validation so for example users can put null value into integer variables and service will not crash). I know that it is not good practice but it has to work this way.

    Which way should I go?

    1. implement IXmlSerializable interface
    2. use Message Inspectors
    3. or maybe there is another solution?

    In my service I am using a XmlSerializer to serialize/deserialize messages.



    • Edited by crocodayl Wednesday, August 3, 2016 1:47 PM
    Wednesday, August 3, 2016 1:45 PM

Answers

  • I wouldn't bother with an inspector. Create a new service that implements the same interface.  Have it call the old service and get the original data. Depending upon how much data you're talking about you can either deserialize that into objects that can then be forwarded on to clients via XmlSerializer or simply parse the XML and build up the new objects.

    Since the interface itself cannot change that means the data contracts likely cannot change either so you're limited to manipulating data in existing fields. Added fields wouldn't show up in the older clients unless they refreshed their configuration. Removing fields would be a breaking change. Since you can only manipulate existing fields then the data sent back from the old service is already in the format that you'll need to forward on to the clients so deserialize the data, make any changes you want to the data and then forward it on.

    Yes you could do this with a message inspector but it seems overkill for this scenario, in my opinion.

    Wednesday, August 3, 2016 2:33 PM
    Moderator

All replies

  • In theory you can do this via the message inspectors but it really sounds like you're trying to change an older service to a newer interface and that is probably beyond what you're going to be able to do.

    If I might recommend, use a thunk/facade. Create a brand new service that exposes exactly what you want. Have the new service call the old service and then manipulate the data before sending it on to the clients. Clients would need to update the endpoint URL and the interface to take advantage of the new interface.

    Depending upon the level of change you make you might even be able to use the same interface (or at least expose it to "legacy" clients. If you can do that then the clients would only need to change the endpoint URL until they are ready to switch to the new interface.

    Michael Taylor
    http://www.michaeltaylorp3.net

    Wednesday, August 3, 2016 1:54 PM
    Moderator
  • In theory you can do this via the message inspectors but it really sounds like you're trying to change an older service to a newer interface and that is probably beyond what you're going to be able to do.

    This is what I am trying to do.

    I have very old service (java). The new one must be compatible with old (migration must be transparent - users will have to change only endpoint address).

    Java service is really sick (completely lack of xsd validation). I have to do similar things in my wcf service.

    I tried to use IXmlSerializable interface which was good, but after implementing GetSchema() method (returning null) the wsdl of the service have changed (after consuming service in SoapUI)

    from:

         <MyClass>
            <propertyA>?</propertyA>
            <propertyB>?</propertyB>
         </MyClass>

    to

         <MyClass>
            <xs:schema>
               <!--Ignoring type [{http://www.w3.org/2001/XMLSchema}schema]-->
            </xs:schema>
            <!--You may enter ANY elements at this point-->
         </MyClass>

    which is unacceptable and I thnik that the only possible solution would be a Message Inspector.


    • Edited by crocodayl Wednesday, August 3, 2016 2:18 PM
    Wednesday, August 3, 2016 2:14 PM
  • I wouldn't bother with an inspector. Create a new service that implements the same interface.  Have it call the old service and get the original data. Depending upon how much data you're talking about you can either deserialize that into objects that can then be forwarded on to clients via XmlSerializer or simply parse the XML and build up the new objects.

    Since the interface itself cannot change that means the data contracts likely cannot change either so you're limited to manipulating data in existing fields. Added fields wouldn't show up in the older clients unless they refreshed their configuration. Removing fields would be a breaking change. Since you can only manipulate existing fields then the data sent back from the old service is already in the format that you'll need to forward on to the clients so deserialize the data, make any changes you want to the data and then forward it on.

    Yes you could do this with a message inspector but it seems overkill for this scenario, in my opinion.

    Wednesday, August 3, 2016 2:33 PM
    Moderator