none
Design decision: several webservices, almost identical interface RRS feed

  • Question

  • Hi all,

    some companies agreed on a standard for SOAP-webservices they offer. It has endpoints and datastructures to query if an item is in stock or to actually order it (after checking its avability).

    Imagine company A implementing every detail of the standard. Company B accepts precisely the same datastructure, but only allows "regular shipment" and not "express" like offered by the standard. And company C is like A, but extended a new attribute "tracking", which you can use to get push-updates about your order.

    My job is to write a client, able to check all inventories and place an order at all companies.

    So the standard is nice but not 100% identical. I could use WCF, have xsd generate code for each company in the namespaces A/B/C and implement the standard three times. Lots of work. Ugly. Maintenance nightmare. :-(

    I'd rather try to do a clean "standards implementation" and have specific code for A (doing nothing), B (giving an error when someone chooses express) or C (enabling tracking).

    But if I use three namespaces, I won't be use the code generated in namespace A to call C. Converting everything vom namespace A to namespace C (sort of a deep copy of the XML) sounds quite awkward. Trying to assemble all xsds into a single document (and not using "tracking" for A/B, though it is defined) sounds rather good, until company D comes up with a different "tracking" extension.....

    So, I really don't know how to design a solution that can be expected to a) work and b) last. ;-)

    How would the experts try to tackle this problem? I'm really curious to get some suggestions.

    Yours,

    Patrick.

    Monday, August 24, 2015 8:07 PM

Answers

  • Hmm, the standard I'm talking about consists of about 20 xsd and my usual approach would be to have lots of code generated using xsd.exe. But it would almost, but not quite, generate identical code for a/b/c, so I'm searching for a way to combine it. One option might be to use all those xsd and create a major-xsd, containing the standard and all extensions the companies implementing the standard have designed so far. I'm worried that might turn out to be a maintenance nightmare.

    But I might have misunderstood what you are hinting at with "some kind data driven approach". The article you link to is an easy read, but there is some gap between my problem and the article....

    You might have to have a service layer used by the client to consume all the WCF services, and the service layer segregates the services by their interfaces. In that way, you can have code in the service layer for each WCF service to use the individual services, but have a common coding platform -- the service layer. Forget about the data driven approach it would never work for you.
    Wednesday, August 26, 2015 1:35 PM

All replies

  • So the standard is nice but not 100% identical. I could use WCF, have xsd generate code for each company in the namespaces A/B/C and implement the standard three times. Lots of work. Ugly. Maintenance nightmare.

    What do you mean by using XSD? If XML is involved some kind of way, then why can't XML drive you client program based on some kind data driven approach.

    http://prateekvjoshi.com/2013/11/30/programming-paradigms-object-oriented-vs-data-oriented/

    Tuesday, August 25, 2015 2:04 AM
  • Hmm, the standard I'm talking about consists of about 20 xsd and my usual approach would be to have lots of code generated using xsd.exe. But it would almost, but not quite, generate identical code for a/b/c, so I'm searching for a way to combine it. One option might be to use all those xsd and create a major-xsd, containing the standard and all extensions the companies implementing the standard have designed so far. I'm worried that might turn out to be a maintenance nightmare.

    But I might have misunderstood what you are hinting at with "some kind data driven approach". The article you link to is an easy read, but there is some gap between my problem and the article....

    Tuesday, August 25, 2015 8:53 PM
  • Hmm, the standard I'm talking about consists of about 20 xsd and my usual approach would be to have lots of code generated using xsd.exe. But it would almost, but not quite, generate identical code for a/b/c, so I'm searching for a way to combine it. One option might be to use all those xsd and create a major-xsd, containing the standard and all extensions the companies implementing the standard have designed so far. I'm worried that might turn out to be a maintenance nightmare.

    But I might have misunderstood what you are hinting at with "some kind data driven approach". The article you link to is an easy read, but there is some gap between my problem and the article....

    You might have to have a service layer used by the client to consume all the WCF services, and the service layer segregates the services by their interfaces. In that way, you can have code in the service layer for each WCF service to use the individual services, but have a common coding platform -- the service layer. Forget about the data driven approach it would never work for you.
    Wednesday, August 26, 2015 1:35 PM