WCF Web service method advice

Question

I've been tasked with implementing a web service method that can be used for many different things(read: no requirements exist) and any client's won't have to change the interface Here's what the method is supposed to look like

[DataContract]
    public class Status
    {
        [DataMember(Order = 0)]
        public long Code
        {
            get;
            set;
        }

        [DataMember(Order = 1)]
        public string Message
        {
            get;
            set;
        }
    }

[DataContract]
    public class Data
    {
        [DataMember(Order = 0)]
        public string Name
        {
            get;
            set;
        }

        [DataMember(Order = 1)]
        public string Value
        {
            get;
            set;
        }
    }

public Status InitiateTransaction(long txnTypeId, Data [] txnData);

The idea is that the client would pass different things in the data array based on what type of "transaction" they want to initiate. What would be the benefit of this over just creating a bunch of different specialized methods that do specific things?

Answer 1

If the people suggesting you implement this are subject to shame, tell them that this pattern is a sure sign of laziness. They can't be bothered to figure out what the requirements are for behavior, so they specify a single method; they can't be bothered to figure out the requirements for data, so they decide on name/value pairs.

There is only one circumstance where I have found this sort of thing to be useful. I have seen some value in defining a web service that accepts a piece of XML and returns a piece of XML, hopefully at least constrained by XML Schema. This is of some use when the service is meant to interact with some other service or other piece of code that operates in terms of XML documents. An example would be an EDI scenario, when the document formats are already defined by industry standard or agreement, and the web service is really nothing more than a proxy for the service that will do the real work.

It doesn't look like your example has that excuse.

Answer 2

Well, the benefit is - it's somewhat "generic" - depending on what gets passed in.

But that's its biggest weakness too, at the same time. Since it's so generic and all-purpose, you can't really enforce a lot of constraints and/or validity checks, really.

I've seen this approach in many places - web services, database schemas - and they usually work fine for two or three separate "things" but begin to fall apart the more complex they get.

I would strongly recommend creating specific, well-checked methods for each thing you want to do.

Marc

PS: also - extending an existing service with additional methods while not changing any of the existing interfaces can be done very easily and without any change to the clients, too - so you can always easily extend your service as your requirements grow, without breaking backwards compatibility.

Answer 3

You also have this kind of service as you're hosting the web service on top of something. If you were to host this on a SOAP endpoint your client would deliver you a "code" and a "message" which IIS or whatever you use to host your web service would interpret as a HTTP message and call the correct HTTP handler. The WCF SOAP handler would get the message, which would really just contain another set of code and message with which the SOAP stack would call the correct service method and pass the message to that one... which then again would just open the message, get its code and message and call the right thing.

You need to implement the methods at some point in any case. So the question I'd ask your supervisors is why not to use the generic code/message system that is already provider, standardized and whatnot and why they should waste your time by making you implement your own on TOP of that?

Also as Marc stated adding more methods to the interface doesn't force any changes on the existing clients.