Configurable integration for xml and UI

WSDL integration involves tools which read wsdl, convert wsdl to java classes, encapsulates soap constructs within method calls simulating RPC calls. The disadvantage with this approach is that every time the wsdl changes, the entire process has to be repeated resulting in multiple deployments which depending on the org. structure could take time.

Instead of using the existing tools to convert wsdl to java store the different fields on the xml specified by the wsdl in the database a more configurale approach would be to map the xml tags fields used in the system and then read the soap request using xml parsers and based on the mapping assign values to the fields. In that way there would be more control over which fields are to be mapped, which ignored, which to be sent to a downstream but more importantly any change in the wsdl is now a configuration change rather than a code change. The downside to this approach is that you have to parse the soap request yourself, the upside is that you now don't need to deploy the code each time the wsdl changes.

This works well with single fields, but when fields have a structure of their own i.e. a parent field with multiple child fields which in Object Oriented Parlance things become complex. Lets take an example of a wsdl which provides details about a person. The classes to store these details are shown below.

public class Person{

private JobDetails jobDetails;

private FamilyDetails familyDetails;


}

class JobDetails{

private Address jobAddress;

private String companyName;

private BigInteger salary;

}

class FamilyDetails{

private Address familyAddress;

private FamilyMember[] members;

}

class FamilyMember{

private String name;

private int age,

private String gender;

}

Assume for the sake of brevity the appropriate getters and setters are present. If this structure is observed what we have here is a parent child relationship between different parents and children. Lets define a structure for these classes

Category -> All xml portions which are directly linked to the soap body

Section -> Children of the categories(Sections can have multiple sections)

Fields-> The children of the section which have no children

Types -> A type is a object which is repeated among sections too frequently for call it a section. A field belonging to type A should always at all times have the same structure of another field beloning to type A the behaviour might differ but must however still be within the behavioral norms of the type. For example lets take phoenumber as type BIGINTEGER. Now the length based on requirement can be changed but the phone-number cannot suddenly have alphabets in it. Hence all behaviors associated with the data of a type are pre-ordained and cannot be random in nature. 

Applying the above structure to our problem we would come up with a structure as shown below.

• Person -> Category
• JobDetails -> Section belonging to person
• companyName -> name of the company of type String
• salary -> salary paid in the job of type INTEGER
• jobAdress -> address of the company of type Address
• familyAddress -> Field belonging to JobDetails of type Address
• FamilyDetails -> Section belonging to Person
• FamilyMember -> Section belonging to Person
• name -> name of family member belonging to FamilyMember of type STRING
• age -> age of family member belonging to FamilyMember of type INTEGER
• gender -> gender of FamilyMember of type GENDER M/F
• familyAddress -> Field belonging Family Details of type Address

This structure makes the assumption that each soap request will be only for one person. If this assumption is correct then note that any new data which needs to be added can be fitted into this structure without a hassle only if it fits in any of the types defined. The moment we define a new type we allow all elements belonging to the type to be added without any hassle since all elements of the same type would effectively have the same structure and would behave within the boundaries of the type. 

The extent to which this architecture can be used to simplify life is truly displayed when we try to display data on the UI using this architecture as the basis of our display. The biggest pain for most back-end engineers is UI. Writing UI code for a new table/ new field is something which most people groan about. If the above structure is loaded in the UI effectively all that would be need is to loop through the Category to get a list of sections. Loop through each section and render subsections and fields.

Combining the above architecture with a UI framework which supports templating means that like the structure the behavior can be fixed based on the type resulting in the need to just write the code once of each type in its corresponding template and configure for further changes.

Once a certain structure has been decided for a system, or for individual modules of a system. This approach to designing ensures that there is more configuration and less coding resulting in faster hassle free releases.