CODEWITHSUNDEEP
javaxmlsoapxsd
Jmoney38
Jmoney38

Reputation: 3304

XSD design issues in Java

Currently our software is interacting with a remote web service via XML/SOAP. We're using XSDs to conveniently create the requests to be sent to the remote system. That's fine, and it's working well. XSD is pretty awesome.

However, it does lead to very lengthy code blocks for creating the Document objects. I'm wondering if anyone has suggestions for good design practices to handle these large code blocks for creation of the request and handling of the response Documents.

The point of the XSD Document object is to decouple the XML creation from the client. However, I'm thinking a facade class might be a good idea for each service. I think this would be great for creation, since the facade class could be given the ingredients to build the request document, and send the request, without coupling the client to the XSD classes. I think a problem arises in the response Documents. If there is a multi-level response, you'll end up creating POJO classes just to wrap the XSD classes, which seems like over-kill.

Upvotes: 2

Views: 327

Answers (1)

bdoughan
bdoughan

Reputation: 149007

Note: I'm the EclipseLink JAXB (MOXy) tech lead.

EclipseLink JAXB (MOXy)

MOXy is a JAXB (JSR-222) implementation that has an XPath based mapping extension. This means you can map a more compact object model to your XML. In the example below a simple Address object is mapped to Google's Geocoding V2 format:

import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

import org.eclipse.persistence.oxm.annotations.XmlPath;

@XmlRootElement(name="kml")
@XmlType(propOrder={"country", "state", "city", "street", "postalCode"})
public class Address {

    @XmlPath("Response/Placemark/ns:AddressDetails/ns:Country/ns:AdministrativeArea/ns:SubAdministrativeArea/ns:Locality/ns:Thoroughfare/ns:ThoroughfareName/text()")
    private String street;

    @XmlPath("Response/Placemark/ns:AddressDetails/ns:Country/ns:AdministrativeArea/ns:SubAdministrativeArea/ns:Locality/ns:LocalityName/text()")
    private String city;

    @XmlPath("Response/Placemark/ns:AddressDetails/ns:Country/ns:AdministrativeArea/ns:AdministrativeAreaName/text()")
    private String state;

    @XmlPath("Response/Placemark/ns:AddressDetails/ns:Country/ns:CountryNameCode/text()")
    private String country;

    @XmlPath("Response/Placemark/ns:AddressDetails/ns:Country/ns:AdministrativeArea/ns:SubAdministrativeArea/ns:Locality/ns:PostalCode/ns:PostalCodeNumber/text()")
    private String postalCode;

}

The above class corresponds to the following XML:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.0" xmlns:ns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0">
    <Response>
        <Placemark>
            <ns:AddressDetails>
                <ns:Country>
                    <ns:CountryNameCode>US</ns:CountryNameCode>
                    <ns:AdministrativeArea>
                        <ns:AdministrativeAreaName>CA</ns:AdministrativeAreaName>
                        <ns:SubAdministrativeArea>
                            <ns:Locality>
                                <ns:LocalityName>Mountain View</ns:LocalityName>
                                <ns:Thoroughfare>
                                    <ns:ThoroughfareName>1600 Amphitheatre Pkwy</ns:ThoroughfareName>
                                </ns:Thoroughfare>
                                <ns:PostalCode>
                                    <ns:PostalCodeNumber>94043</ns:PostalCodeNumber>
                                </ns:PostalCode>
                            </ns:Locality>
                        </ns:SubAdministrativeArea>
                    </ns:AdministrativeArea>
                </ns:Country>
            </ns:AddressDetails>
        </Placemark>
    </Response>
</kml>

For More Information

Upvotes: 1

Related Questions