This blog is to provide an insight on development of Portal applications by achieving high cohesion between the portal and the service layer by secluding and automating the JAXB framework. We know that portal applications are composed of bundles of portlets and hence the compositions and the complexities of each portlet are of utmost importance. The approaches to be elucidated here will considerably reduce the complexity, composure thereby increasing cohesion of the portlets with the service layer₁.
Our aim is to achieve the following by bringing in loose coupling and high cohesion.
Conventional solutions on consuming the services with schemas/JAXB acting as contract are done at every portlet (i.e. generation of the JAXB classes are done at every portlet project), thereby loading it relatively heavy and resulting in low cohesion between the two layers. Any change in the upstream service layer affects the portal layer. With the advent of Continuous Integration and advanced build automation tools, a proactive design by evidently isolating the layers would bring in significant gain.
The illustrated solution assumes REST/ SOAP communication between the portal and the back-end/business layer and uses Maven build tool (can be achieved by other ways as well). In the following illustration, we use the REST services.
The above conventional approach becomes very expensive in terms of maintenance because, any change in the meta-data definition impacts the portal code. To prevent and minimize this huge impact, the JAXB Libraries generated from the schemas are isolated from the portal layer. If the change is backward compatible vis-à-vis the portlet, there is no impact on the portal layer, since updating and regenerating JAXB classes are secluded from it. This would restrict the impact only on portlets which are affected by the change.
The implementation of above design can be well achieved in WebSphere Portal by using the Shared Libraries of WebSphere Application Server (approach A), Maven and JAXB framework. The same solution is illustrated below,
Illustration –
Configuration –
The configuration files required at each of the layers are as follows,
1) Automated JAXB Libraries
A mavenized project with the following configuration files to completely automate the process.
a. The POM file of the mavenized JAXB Libraries.
The POM file of the project should include the “maven-jaxb2-plugin” which is used to generate the JAXB classes (usually generated manually by IDEs or other tools). The snippet₂ is given below ,
The above plugin automatically generates the JAXB classes for every schemas placed inside the folder bundling them into a jar. A simple maven’s <outputDirectory> places the built JaxbLibraries jar directly into the directory which will be referred by the Portal Layer through WebSphere Application Server’s Shared Library. However, if the build server is at different location the same can be moved manually or by other automated means.
b. The XJB configuration file of the JAXB framework.
The JAXB classes generated by the maven plugin will not have specific attributes like the XmlRoot element, does not implement the Serializable interface, generates only JAXB defined types. To customize the JAXB classes to our requirements like having an @XmlRootElement which helps in simple marshalling/ unmarshalling, Serializing the objects, create JAXB Adapters used for conversion of data types, etc. JAXB provides the XJB configuration file in which all of the above can be done. A sample entry of the file is as shown.
Few snippets₂ of the xjb file are,
This would allow the developer to configure the generated JAXB classes without using any generation tools but in an automated way. Hence by creating a java maven project with the above maven plugins, we evade the repetitive, manual generation task per schema basis but have an automated generation. There by loosely coupling by isolating the JAXB libraries from the portal layer.
1) Portal Layer
Approach A –
The addition to the POM file of the portlet project is simple and direct. A dependency of the JAXB Library jar with a provided scope is to be added to the POM.
By adding this dependency to the portlet web project, would ensure that the isolated JAXB libraries that encompasses the classes required by the portlet consuming the service are provided by the Maven repository for compilation and by the J2EE container (Shared Library of WAS in this case) during runtime.
Overhead scenarios –
In cases of narrowly designed service where any minor change in the schemas affect the portlet during compilation, this approach becomes an overhead. But since a good service oriented architecture prescribes accommodation of backward compatible design enhancements/ changes (to be adhered), this approach on secluding the JAXB layer from the Portal Layer saves substantial time and effort.
Approach B –
Approach A would require a regression of even unaffected portlets which can be avoided by having the JaxbLibraries bundled along the web archive of the portlet. This would apparently look like the conventional approach but is actually not since it is just the copy of the secluded library virtually bundled with the portlet. Thereby upholding high cohesion between the layers and evading regression of unaffected portlets. The POM would be,
Different versions of the JAXBLibraries might exist in different portlets by this approach. Both the approaches have their own merits and can be chosen during design decisions by weighing the approaches on the requirements.
Note– having schemas of different versions in each portlet will also reduce the need for modifying portlets when there is no impact, but it is a poor approach in terms of development and maintainability which poses serious threats.
