JBoss fails to support SEI methods that feature interfaces or abstract classes (this requires the use of the xsi:type attribute to indicate an instantiatable derived type).

For example given:

1. the following SEI:
public interface DemoServiceEndpoint extends java.rmi.Remote {
public AbstractDescr processDescr(AbstractDescr p) java.rmi.RemoteException;
}
where the business method is implemented as
public AbstractDescr processDescr(AbstractDescr p) {
AbstractDescr returnValue = null;
returnValue = new Descr();
returnValue.setDescription("Works as a return type!");
return returnValue;
}

2. the following Java classes:
abstract public class AbstractDescr implements Comparable, Serializable {
private String description;
public String getDescription()

{ return description; }

public void setDescription(String value)

{ this.description = value; }

...
}

public class Descr extends AbstractDescr {
...
}

3. The following XML Schema mapping for AbstractDescr and Descr:
<xsd:complexType name="AbstractDescr" abstract="true">
<xsd:all>
<xsd:element name="description" type="xsd:string"/>
</xsd:all>
</xsd:complexType>
<xsd:complexType name="Descr">
<xsd:complexContent>
<xsd:extension base="tns:AbstractDescr"/>
</xsd:complexContent>
</xsd:complexType>

4. The following java-xml-type-mapping entries for AbstractDescr and Descr:
<java-xml-type-mapping>
<java-type>rootpackage.application.business.common.AbstractDescr</java-type>
<root-type-qname xmlns:typeNS="http://common.business.application.rootpackage">typeNS:AbstractDescr</root-type-qname>
<qname-scope>complexType</qname-scope>
<variable-mapping>
<java-variable-name>description</java-variable-name>
<xml-element-name>description</xml-element-name>
</variable-mapping>
</java-xml-type-mapping>
<java-xml-type-mapping>
<java-type>rootpackage.application.business.common.Descr</java-type>
<root-type-qname xmlns:typeNS="http://common.business.application.rootpackage">typeNS:Descr</root-type-qname>
<qname-scope>complexType</qname-scope>
</java-xml-type-mapping>

JBoss generates soap:Body elements whose return value part accessors (in the case of the rpc-literal binding) or return value elements (in the case of the document-literal binding) don't contain the xsi:type attribute, which leads to:
1. The receiver not being able to deserialize the payload generated by JBoss resulting in spurious errors on the reveiver's side;
2. JBoss violating the XML Schema (that requires that for an element whose type definition is abstract, all instances of that element must use xsi:type to indicate a derived type that is not abstract).

Here's a return envelope that JBoss generated for this example:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:processDescrResponse xmlns:ns1="http://logic.business.application.rootpackage">
<processDescrReturn> <!-- this element must contain an xsi:type attribute to enable the receiver to deserialize it... -->
<description>Works as a return type!</description>
</processDescrReturn>
</ns1:processDescrResponse>
</soapenv:Body>
</soapenv:Envelope>

I have a hunch that JBoss fails to generate xsi:type attributes for parameters too if one uses a J2EE client (that looks up a service interface in the JNDI tree) to access the corresponding service endpoint.

If required, I'll attach a sample application for this problem.