Diameter Sh User-Data XML
As noted on the wiki page, an area of functionality as yet unspecified is how to put an API on the User-Data AVP (which contains an XML document).
My thoughts on this are that the RA Type should provide something similar to the API for creating and accessing AVPs, the RA implementation can then read and write the XML any way it chooses.
I also considered the possibility of mandating the use of an XML binding framework as part of the RA Type, but this approach has the following arguments against it:
- An important part of the RA implementation will be handed off to a third-party product beyond the control of the RA implementer and potentially difficult to optimise.
- Classes generated by a binding framework may be more complex and verbose than necessary. For example, there may be cases where simple documents (e.g., a basic CSLocationInformation document) could be created with a single method.
- The RA Type is tied to the binding framework and shares any restrictions it may have (eg, requiring a particular Java version).
I do however think it makes sense to use a schema compiler to create the Java bean-style interfaces for the API. I looked at both Apache XMLBeans and Sun's JAXB 2.0, and the JAXB schema compiler generated classes that look well suited to our purpose. JAXB 2.0 requires the use of Java 5, and I don't think an RA type should require a particular Java version. But since we don't want implementation classes in the RA type anyway, my idea for solving this is that we extract interfaces from the compiled classes (which eliminates the annotations) and also remove the use of generics.
- An RA implementation can still use JAXB to marshal and unmarshal the XML document if it chooses, or implement its own binding.
- The API can potentially be enhanced for to improve the creation of specific Sh-User-Data documents.
- Remains compatible with Java 1.4.
There are a couple of drawbacks to this approach which I can hopefully address preemptively. Obviously this approach will require more work, both in defining the RA Type API and implementing the RA. But I have made the argument previously for simplifying service development by off-loading work to the RA, and the same argument applies here. The second drawback is that updating the API (and implementation) will have to be done manually if the schema changes. My response to this is that if the schema changes, then a new RA type version will be required (which is a significant step) and there will no doubt be other changes to the Diameter side of the Sh protocol as well.
All comments welcome.