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

Published Thursday, October 07, 2004 6:48 PM

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't advise 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]
public Order 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:sequence>
    <xs:element name="Quantity" type="xs:int" />
  </xs:sequence>
</xs:complexType>

<xs:complexType name="Order">
  <xs:complexContent>
    <xs:extension based="OrderRequest">
      <xs:sequence>
         <xs:element name="CurrentStatus" type="xs:string" />
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

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?

Filed under:

Comments

# David Taylor said on Thursday, October 07, 2004 7: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.

# Davdi Taylor said on Thursday, October 07, 2004 7: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...

# Bruno Dobler said on Tuesday, October 12, 2004 9:18 AM

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'.

# TrackBack said on Saturday, January 08, 2005 11:16 AM

Boyd's Blog &raquo; Class Inheritance with a WebService

# TrackBack said on Monday, January 24, 2005 11:17 PM


Yesterday I was stumped for a while about using classes that inherited
from each other in my web service.
I had something similar to the following:[Serializable]public class ParentClass{ public string Name;}[Serializable]public class ChildClass : P

This Blog

Syndication