Home > .NET > Inheritance in types returned by a WebService – good or bad idea?

Inheritance in types returned by a WebService – good or bad idea?

Simon Guest posted a list of his Top Ten Tips for WebService Interoperability which is a wonderful resource if you are building a webservice that will be widely used.

Unfortunately the list doesn’tadvise about inheritance in the types that are returned from a webservice. This sounds like a no-no … why would you make something any more complicated than it needs to be, right? However, it can often make a lot of sense in your business data. For example, say you have a large object graph for input to one of WebMethods – another WebMethod returns the same data plus more output information. Wouldn’t it make sense to have a specialized subclass that inherited from the base object and provided the extra output information? We tried this but got burned alive trying to define the schema validation for the output data.

Contrived Example:

[WebMethod]
public int PlaceOrder(OrderRequest order)
{ // return order number
}

[WebMethod]
publicOrder RetrieveOrder(int orderNumber)
{// return order with additional info
}

public class OrderRequest
{
public int Quantity;
}

public class Order : OrderRequest
{
public string CurrentStatus;
}

<xs:complexType name=”OrderRequest“>

<xs:element name=”Quantitytype=”xs:int” />

<xs:complexType name=”Order“>

<xs:extension based=”OrderRequest“>

<xs:element name=”CurrentStatustype=”xs:string” />

I am having a difficult time getting it to work correctly within a .NET environment. Are other people doing things like this? Does it work on other platforms?

Categories: .NET
  1. http://
    October 7, 2004 at 11:20 pm

    One of the design choices we have a few years ago when building our web services was to have common CRUD (Create, Read, Update, Delete) operations defined on an abstract base class and have a bunch of concrete types inheriting from the base. This worked really well for a web hosting API, monitoring API and has been a good pattern for us – keeping the SOAP and API small.

    We have a .NET frontend talking SOAP to a J2EE backend and this worked out-of-the-box for us without any problems.

  2. http://
    October 7, 2004 at 11:23 pm

    I should point out that the web method was passing the abstract base as in:

    [WebMethod]
    public void CreateProduct(HostingProduct Product)
    {
    }

    In this example HostingProduct was the abstract base and we were actually using 5-6 products that inherited from that base. This worked very well between .NET and J2EE.

    We also always used SOAPExceptions whenever things went wrong rather than returning, say an int response code…

  3. http://
    October 12, 2004 at 1:18 pm

    I’m not an expert yet, but the solution how to do it you can find on the webpage of Mössenböck, Beer, Birngruber, Wöß who wrotes an excelent .Net Book. Example PersonService.asmx
    http://www.dotnet.jku.at/buch/samples/index.aspx
    Beispiel: abstrakte Parametertypen und Vererbung
    http://www.dotnet.jku.at/buch/samples/7/encoding/person.aspx

    This book is in german, but mostely seems to be also in the newest book in Engish language ‘.NET Application Development’.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: