Web service and polymorphism

This page present several options to define a web service interface that uses polymorphism on list of objects. It compares various possible web service interface definition.

My preferred pattern is #5. It was used in one of our web service and works nice.

See also http://www.ibm.com/developerworks/webservices/library/ws-tip-xsdchoice.html

Wrapper with two collections

N° 1
Name Wrapper with two collections
Description Declaration of two list to hold each kind of filters
Java definition 
Class FilterClause
{
 @XmlElement(name="termFilter")
 List<TermFilter> termFilers;
 @XmlElement(name="fullTextFilter")
 List<FullTextFilter>   ftFilters;
}
Distinction between null or empty list Yes – if lists are empty, filterClause tag is still there
Expected SOAP request <filterClause>
<termFilter>
<name>edoc:Date</name>
<operator>=</operator><value>2005-10-10</value>
</termFilter>
</filterClause>
Pro
  • Simple
Cons
  • Not extensibility: a new subtype require a new list and to re-generate the stub on the client side
  • To add a new subtype, a new list must be added in the class
  • Not very Object-oriented

Wrapper with polymorphism on tag name

N° 2
Name Wrapper with polymorphism on tag name (xsd :choice)
Description Declaration of one list with xsd:choice to distinguish the type of the elements and change the tag accordingly
Java definition 
public class FilterClause
{ @XmlElements({
@XmlElement(name="termFilter", type=TermFilter.class),
@XmlElement(name="fullTextFilter",type=FullTextFilter.class)
})private Listfilter; }
Distinction between null or empty list Yes – if lists are empty, filterClause tag is still there
Expected SOAP request <filterClause>
<termFilter>
<name>edoc:Date</name>
<operator>=</operator><value>2005-10-10</value>
</termFilter>
</filterClause>
Pro
  • Extensibility to new subtype without the need to re-generate the stub on the client side
  • XML is easily readable
Cons
  • To add a new subtype  a new @XmlElement entry must be added manually

Wrapper with polymorphism with xsi:type

N° 3
Name Wrapper with polymorphism with xsi:type
Description Usage of a wrapper with the declaration of one list using base type – polymorphism is detected automatically by JAXB & .NET
Java definition 
public class FilterClause
{@XmlElement(name="filter")private Listfilters;}
Distinction between null or empty list Yes – if lists are empty, filterClause tag is still there
Expected SOAP request <filterClause>
<filter xmlns:q1=”http://www.imtf.com/hypersuite/hydra&#8221; xsi:type=”q1:termFilter”>
<name>edoc:Date</name>
<operator>=</operator>
<value>2005-10-10</value>
</filter>
</filterClause>
Pro
  • Extensibility to new subtype without the need to re-generate the stub on the client side
  • XML is easily readable because of the wrapper tag
Cons
  • To add a new subtype  a new @XmlElement entry must be added manually
  • Wrapper tag is useless except for readability

Polymorphic list on tag name

N° 4
Name Polymorphic list on tag name (xsd :choice)
Description Same as 2 without wrapper
Java definition Can not be defined in Java, because @XmlElement can not be applied on the parameter of a method signature
Distinction between null or empty list No – if list is empty or null not tags are written
Expected SOAP request <termFilter>
<name>edoc:Date</name>
<operator>=</operator><value>2005-10-10</value>
</termFilter>
Pro See comment in Java definition
Cons See comment in Java definition

Polymorphic list with xsi:type

N° 5
Name Polymorphic list with xsi:type
Description Same as 3 without wrapper
Java definition 
 @XmlSeeAlso({FullTextFilter.class,TermFilter.class})
public class XXXX
{
@WebParam(name="filter")
List<Filter> filters;
Distinction between null or empty list No – if list is empty or null not tags are written
Expected SOAP request <filter xmlns:q1=”http://www.imtf.com/hypersuite/hydra&#8221; xsi:type=”q1:termFilter”>
<name>edoc:Date</name>
<operator>=</operator>
<value>2005-10-10</value>
</filter>
Pro
  • Extensibility to new subtype without the need to re-generate the stub on the client side
  • All subtypes can be defined in a secondary XSD that is imported in the WSDL
Cons
  • To add a new subtype  a new @XmlSeeAlso entry must be added manually

Leave a comment