locked
WCF service / method design RRS feed

  • Question

  • User-745244032 posted

    Hi all,

    Opinions, reasoning and pros/cons wanted:

    services can be built (a) however you want (b) based on existing restrictions and (c) REST or RPC styles... and probably more...

    But I'm wondering specifically about these two things that appear to be at odds with each other and I'm wondering what is the "current guidance" about this.

    A)

    megaResponseWithEverythingAndTheKitchenSink = Service1.DoSomeWorkGetStuffBack(inputDataWithVariousContextInfo);

    vs

    B)

    userInfo = Service1.GetUserInfo(UserId, OptionA);
    orderInfo = Service1.GetOrderInfo(orderId, userId, OptionB, OptionC, FilterX);
    productInfo = Service1.GetProductInfo(howManyToList);

    I've read that "wire costs" are relatively high, so should be minimized as in "A", but SoC lends itself to "B"

    With "A" however versioning is a little easier as long as the input/output objects are only ever "added to" - is this a big deal...? esp if you control both sides of the wire?

    With "B" how do you manage the parameter bloat? do you get to a "magic number" and swap to a "request object", or do you start EVERYTHING with a BaseRequest of some kind...?... OR do you "halt" when you get to a certain parameter count an reassess the method as "doing too much"...

    Not sure if there IS any guidance at this level, but if y'all can supply something by way of an answer I'd appreciate it.

    Really the questions probably boil down to:

    • Many specialized methods that do something specific vs fewer broader methods that do more (and are there any rules/guides around how to quantify/measure when more and specific overstep their bounds) -  eg: (regardless of the fact that this is using params rather than "requests" do you keep growing a "UserUpdate" or do you make more specific functions with meaningful names even though perhaps they do the same thing but with different numbers of params (perhaps not updating or using defaults)
    void UserUpdate(userid, name, likes, dislikes, holidaylist)//"holidaylist" new in v2.0
    
    vs
    
    void UserUpdate(userid, name, likes, dislikes)
    void UserUpdateWithHolidays(userid, name, likes, dislikes, holidaylist)
    
    • How to manage growth and change of such things (contracts/implementations) as development progresses/service evolves.
    • is "wire" performance an up-front consideration, or is this an "optimisation" to be done when it becomes a performance issue?

     

     

    Friday, July 24, 2015 2:39 AM

Answers

  • User475983607 posted

    Your question is a bit broad so I'll try to answer the best I can.

    WCF uses two communication styles; Document and RPC.  Document style is the default where the message body is defined by the data contact and can hold just about anything. In RPC style the message is fixed with an variable array of parameters.  The message itself defines the method and argument to invoke on the middle layer.

    RPC allows for OOP programming but the binding between the client is service is very tight.  The client has to have intimate knowledge of the inner workings of the middle tier. Document style, on the the other hand,  uses a contract to define the types.  The client only needs to look at the WSDL to figure out how to communicate with the service.

    Many specialized methods that do something specific vs fewer broader methods that do more (and are there any rules/guides around how to quantify/measure when more and specific overstep their bounds) -  eg: (regardless of the fact that this is using params rather than "requests" do you keep growing a "UserUpdate" or do you make more specific functions with meaningful names even though perhaps they do the same thing but with different numbers of params (perhaps not updating or using defaults)

    I believe you are asking about a facade pattern here.  I would certainly use a facade over separate and discrete methods.  Most of the time you end up with a facade without trying anyway.

    https://en.wikipedia.org/wiki/Facade_pattern

    How to manage growth and change of such things (contracts/implementations) as development progresses/service evolves.

    Versioning can be a bit of a hassle with a document style communication whereas RPC just need to sneak in a new type.  Although with RPC the back-end needs to have the wherewithal to handle the new type.  With document style the problem is in-your-face.

    is "wire" performance an up-front consideration, or is this an "optimisation" to be done when it becomes a performance issue?

    I think what you're asking if it is ok to return a large set of data and let the web server (service) whittle down the data?   I say NO.  I firmly believe that SQL server should handle set data as that's what SQL server is good it.  Web server should handle webbie stuff because that's what IIS is good it.

    Regardless, you should always be conservative with bandwidth regardless of the style or pattern in use.  

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, July 24, 2015 1:45 PM
  • User475983607 posted

    The only thing you mis-interpreted was that last bit - I wasn't asking about "SQL vs Code filtering or getting data" I was asking more about code design and how much/when to consolidate vs separate things or if this is something to do when performance is suffering only... maybe "# of requests overhead vs bundling and lack of separation"... ?

    Data that does not change often should be cached.  This rule applies to all web development not just WCF.

    if you do it "client side" then you have a lot of error handling to manage during each request and instantiating of channels...

    if you bundle requests then you need to invest/maintain code to bundle it all up on each request...

    is there any guidance on this or is it try one and modify if you hit problems...?

    I'm not sure what you mean by bundling requests. What problem does bundling requests solve?  Do you have any documentation that explains bundling requests in WCF?

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 30, 2015 4:30 PM
  • User-745244032 posted

    Nope "bundling" is my made up term - basically combining more than one request in order to save the overhead of n+ requests...

    Problem (possibly also imagined by me) is solving multiple requests overheads "new Proxy() -> make request, new proxy()

    But sounds like Caching is where I should be looking.

    - NOT combining requests or any of that stuff... (ASIDE: I've often avoided caching because of trouble I always get into with stale data/invalidating it rationally... but I'll revisit it all since it seems like I should be looking there to reduce bandwidth, not merging loosely related data into "combo requests" another made up term from me... sorry! :)

    and sounds like the answer is

    (a) its an optimization thing so worry about it when its more of an issue - get the logic right first then find the bottlenecks

    (b) choosing between "Doc mode" and "RPC mode" requires more info, but there are pros/cons to both...?

    I'll need to investigate that Façade thing more, I can see its benefits, but also drawbacks... and I don't get it enough to understand the "depth of those differences"...

    are there any rules of thumb with this stuff?

    EG: always start with RPC if project is small and change to docs as things grow, or always start with docs for anything non trivial as most systems grow beyond RPC... except for lookups... or NEVER combine the two or anything like that?

    Also I think VERSIONING (for me at least) is waaay more important than its given credit for, even in systems where you "own both sides" as if you have a service that is shared by many clients (or not) its not always practical to deploy the client updates in a meaningful timeframe, so if you can deploy non breaking changes ot a service "at any time" then this is a desirable thing... no?

    Thanks HEAPS for your info, best I've insight I've gotten into this stuff, you've REALLY helped me understand it all better!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 30, 2015 8:14 PM

All replies

  • User475983607 posted

    Your question is a bit broad so I'll try to answer the best I can.

    WCF uses two communication styles; Document and RPC.  Document style is the default where the message body is defined by the data contact and can hold just about anything. In RPC style the message is fixed with an variable array of parameters.  The message itself defines the method and argument to invoke on the middle layer.

    RPC allows for OOP programming but the binding between the client is service is very tight.  The client has to have intimate knowledge of the inner workings of the middle tier. Document style, on the the other hand,  uses a contract to define the types.  The client only needs to look at the WSDL to figure out how to communicate with the service.

    Many specialized methods that do something specific vs fewer broader methods that do more (and are there any rules/guides around how to quantify/measure when more and specific overstep their bounds) -  eg: (regardless of the fact that this is using params rather than "requests" do you keep growing a "UserUpdate" or do you make more specific functions with meaningful names even though perhaps they do the same thing but with different numbers of params (perhaps not updating or using defaults)

    I believe you are asking about a facade pattern here.  I would certainly use a facade over separate and discrete methods.  Most of the time you end up with a facade without trying anyway.

    https://en.wikipedia.org/wiki/Facade_pattern

    How to manage growth and change of such things (contracts/implementations) as development progresses/service evolves.

    Versioning can be a bit of a hassle with a document style communication whereas RPC just need to sneak in a new type.  Although with RPC the back-end needs to have the wherewithal to handle the new type.  With document style the problem is in-your-face.

    is "wire" performance an up-front consideration, or is this an "optimisation" to be done when it becomes a performance issue?

    I think what you're asking if it is ok to return a large set of data and let the web server (service) whittle down the data?   I say NO.  I firmly believe that SQL server should handle set data as that's what SQL server is good it.  Web server should handle webbie stuff because that's what IIS is good it.

    Regardless, you should always be conservative with bandwidth regardless of the style or pattern in use.  

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, July 24, 2015 1:45 PM
  • User-745244032 posted

    Yeah sorry about the broadness of the question buy you pretty much nailed exactly what I was getting at.

    So well done you! :)

    ASIDE: In your second bit "Versioning" did you mean that document just needs a new type...? and RPC the problem is in your face? I got a bit confused by this bit...?!

    The only thing you mis-interpreted was that last bit - I wasn't asking about "SQL vs Code filtering or getting data" I was asking more about code design and how much/when to consolidate vs separate things or if this is something to do when performance is suffering only... maybe "# of requests overhead vs bundling and lack of separation"... ?

    So to kind of give a real world (or as close to as I can think of right now) example:

    var countrylist = svc.GetCountries();var currencylist = svc.GetCurrencies();

    or should you do this:

    var response = svc.GetLookups();
    var countrylist = response.Countries;
    var currencylist = response.Currencies;

    obviously this is very simple and the impact would be minor, but as a system grows it could become a lot of requests...

    I guess I'm kind of wondering where is the best placed to do the splitting/joining...

    ie:

    if you do it "client side" then you have a lot of error handling to manage during each request and instantiating of channels...

    if you bundle requests then you need to invest/maintain code to bundle it all up on each request...

    is there any guidance on this or is it try one and modify if you hit problems...?

    Wednesday, July 29, 2015 7:12 AM
  • User475983607 posted

    The only thing you mis-interpreted was that last bit - I wasn't asking about "SQL vs Code filtering or getting data" I was asking more about code design and how much/when to consolidate vs separate things or if this is something to do when performance is suffering only... maybe "# of requests overhead vs bundling and lack of separation"... ?

    Data that does not change often should be cached.  This rule applies to all web development not just WCF.

    if you do it "client side" then you have a lot of error handling to manage during each request and instantiating of channels...

    if you bundle requests then you need to invest/maintain code to bundle it all up on each request...

    is there any guidance on this or is it try one and modify if you hit problems...?

    I'm not sure what you mean by bundling requests. What problem does bundling requests solve?  Do you have any documentation that explains bundling requests in WCF?

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 30, 2015 4:30 PM
  • User-745244032 posted

    Nope "bundling" is my made up term - basically combining more than one request in order to save the overhead of n+ requests...

    Problem (possibly also imagined by me) is solving multiple requests overheads "new Proxy() -> make request, new proxy()

    But sounds like Caching is where I should be looking.

    - NOT combining requests or any of that stuff... (ASIDE: I've often avoided caching because of trouble I always get into with stale data/invalidating it rationally... but I'll revisit it all since it seems like I should be looking there to reduce bandwidth, not merging loosely related data into "combo requests" another made up term from me... sorry! :)

    and sounds like the answer is

    (a) its an optimization thing so worry about it when its more of an issue - get the logic right first then find the bottlenecks

    (b) choosing between "Doc mode" and "RPC mode" requires more info, but there are pros/cons to both...?

    I'll need to investigate that Façade thing more, I can see its benefits, but also drawbacks... and I don't get it enough to understand the "depth of those differences"...

    are there any rules of thumb with this stuff?

    EG: always start with RPC if project is small and change to docs as things grow, or always start with docs for anything non trivial as most systems grow beyond RPC... except for lookups... or NEVER combine the two or anything like that?

    Also I think VERSIONING (for me at least) is waaay more important than its given credit for, even in systems where you "own both sides" as if you have a service that is shared by many clients (or not) its not always practical to deploy the client updates in a meaningful timeframe, so if you can deploy non breaking changes ot a service "at any time" then this is a desirable thing... no?

    Thanks HEAPS for your info, best I've insight I've gotten into this stuff, you've REALLY helped me understand it all better!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 30, 2015 8:14 PM