Migration J2EE Applications from OC4J to Weblogic Part -1

In this post, I will try to explain the various issues/solutions which we have faced while migrating the applications to Weblogic (Oracle 11g) from OC4J.

The following post will detail out the various issues/solutions  during our applications upgrade of weblogic.

Switching to Xerces Parser

In case the applications are using the Spring or webservices or JAXB or Hibernate libraries, the Xerces parse should be configured instead of weblogic default parser. Please follow the below steps to achieve this.

• Place the following jars under the /library folder; xercesImpl-2.9.1.jar, xalan-2.7.1.jar, and serializer-2.7.1.jar
• Once we have placed the file, we need to make sure that weblogic uses these while starting up. For that we need to change the follwing file./user_projects/domains//bin/setDomainEnv.cmd. Open this file identify all the places where we find the following code; set JAVA_OPTIONS ; this has to be updated with the follwing lines. - Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser

• In OC4J for EAR remove the orion-application.xml and add the weblogic-application.xml to /META-INF folder with the follwing content.

<?xml version="1.0"?>  
      <weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"  
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
           <xml>  
                <parser-factory>  
                     <saxparser-factory> org.apache.xerces.jaxp.SAXParserFactoryImpl  
                     </saxparser-factory>  
                     <document-builder-factory>  
                          org.apache.xerces.jaxp.DocumentBuilderFactoryImpl  
                     </document-builder-factory>  
                     <transformer-factory>  
                          org.apache.xalan.processor.TransformerFactoryImpl  
                     </transformer-factory>  
                </parser-factory>  
           </xml>  
           <application-param>  
                <param-name>webapp.encoding.default</param-name>  
                <param-value>UTF-8</param-value>  
           </application-param>  
           <prefer-application-packages>  
                <package-name>org.apache.xerces.*</package-name>  
                <package-name>org.apache.commons.*</package-name>  
                <package-name>org.apache.log4j.*</package-name>  
           </prefer-application-packages>  
      </weblogic-application>  

• The following libraries were removed from the maven build. i.e; we removed the following jar files from pom.xml and no errors were observed during testing and deployment.
• javax.xml.soap:saaj-api
• xerces:xercesImpl
• xml-apis:xml-apis
• These were the oracle specific libraries which was removed.
• oracle.xml:xmlparserv2
• oracle.j2ee.ws:orasaaj
• oracle.j2ee.ws:soap
• oracle.j2ee.ws:wsa
• oracle.j2ee.ws:wsclient
• oracle.j2ee.ws:xsdlib
• oracle.j2ee.ws:relaxngDatatype

Application Libraries Loading Order

We need to load the application libraries first rather than the web-logic libraries for some of the libraries. Hibernate depends on different version of ANTLR jar than the default one weblogic libraries, to reolve this conflict and add weblogic.xml under the web application WEB-INF folder with the following details.

 <?xml version="1.0" encoding="UTF-8"?>  

 <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"  

      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  

      xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">  

      <container-descriptor>  

           <prefer-web-inf-classes>true</prefer-web-inf-classes>  

      </container-descriptor>  

 </weblogic-web-app>  

This helps in configuring weblogic to load the right ANTLR library version from the application libraries rather than the server libraries.

External Configuration Files Loading

Most of the applications will have application configuration files. And most of our applications there is a different folder other than the one inside the EAR applications. Earlier we used this path in the orion.xml, but in weblogic we need to use a different mechanism namely using the Generic File loading which is available in weblogic. 

We need to add a plan.xml as part of the deployment plan and then add the config-root element to it.

 <?xml version="1.0" encoding="UTF-8"?>  

 <deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">  

   <config-root>D:\Users\testApp</config-root>  

 </deployment-plan>  

After this we need to go the console application of weblogic. Under the Console/Deployment add the path for the new plan.xml. 
Place all the configuration files under the directory 
%config-root%\AppFileOverrides folder, this is a reserved weblogic folder name which is used to load configuration files

     

Guidelines for Preparing Solution Architecture Principles

Gyaan ( The General Wisdom) 

For any organization which deals with the software architecture there need to have a software architecture standards which will be used for taking architectural decisions.

So how do we go about creating a software architecture standards that can be circulated across an organization. 

1. Identify the purpose of this document why this document is required.
2. Have a good understanding  of the existing technologies used across the organization. 
3. Identify technical constraints which are there in the organizations and the principles should be in line with those constraints.
4. Follow a structure for penning down the principles. For instance a principle should contain a the following The intent of the principle, Rationale of the Principle and the Implications of the principle.

This kind of a structure information can be circulated to the teams so that they can use this document to take critical decisions in the project. 

Application to Real life Situations.

Enough of prophesying, lets get cracking and apply this to develop some principles for real life problems which we come across in our work.

Lets assume we are being entrusted  with making a solution  architecture principle so that it can be used as a guideline for teams.  

As a first step we need to understand the technology landscape of our organization, when i say technology landscape let me restrict myself to software technologies.

Software Landscape Assessment.

Current technology Landscape includes solutions  of three platforms 

• Microsoft technologies (the old VB6 and ASP). This is largely my legacay suite of applications.
• JAVA/J2EE technologies which is used for building my custom applications.
• Any CRM/ERP related products which are used for out of the box solutions for finance, HR related domains.

Once i study the technology landscape, we need to have a closer look at the application landscape.

Lets assume we identified that most of the applications built are on top of all these technologies. And the applications are tightly integrated since the business process are tightly integrated.

Constraints Identifications

We figure out that we don't have a proper integration middle-ware. 

Since we have used COTS(Commercial Off the Shelf ) products, some of them don't support open  standards.

Legacy applications are used for some of the critical business process so we will not be able to replace those with new systems since we have some external stakeholders and management intervention.

Lack of central reference data has caused data duplication which is scattered across the applications.

Principles samples

This sections list out some sample principles in accordance with the constraints which we have mentioned and based on the application landscape.

Statement

Legacy systems/services will be replaced but only when there is a valid business case for doing so

Rationale

• Legacy systems are not inherently bad and a whole-sale approach    to replace them with the latest technology be avoided.
• Replacement of existing legacy systems will only be done if there is a valid value proposition to do so and if the risks have been properly evaluated.

Implications.

• Legacy system will continue to exist in the organization and  it should be noted that this position will not change over time.
• Only the specifics of which system are legacy will change.   i.e. the systems introduced today will be deemed legacy at some point of time in future.
• The functionality will be scattered between the new systems and the old systems.
• Integration between the legacy system and the new systems  has its own cost and maintenance cycle.

Statement

Solution architecture should be designed to use asynchronous mode of integration to deal with system integration except where real time response is required or the systems to be integrated  have the same availability.

Rationale

Asynchronous communication offers more flexibility than synchronous communication in terms of 

• Decoupling.
• Availability.
• Throttling.
• Fault-Tolerance

Implication

• Asynchronous messaging requires a distinctly different design. It is implemented  with a very basic set of message oriented middle-ware commands
• Lack of ESB (Enterprise Service Bus) implies either to depend on point to point integration  or building some in-house custom mediation module on top of existing third party frameworks for messaging requirements.
• Asynchronous solution requires services/components to be stateless

Statement

Solutions should be architect-ed considering interoperability within a heterogeneous environment.

Rationale

• Interoperability is the capability of software located on different hardware, potentially from different vendors, to share data.
• Interoperability,  allows applications or services the ability to use or access other applications or services regardless of the technology  or the platform they are deployed upon.

Implication

• Interoperability standards and industry standards will be followed unless there is a compelling business  reason or a technical limitation to implement a non-standard solution.

Statement

The architecture should  have clear functional layer  to access the data residing in other applications. The data would be referenced if the data source resides in the same database.  If the data is located in different data source then a copy would be made.

Rationale

• The heterogeneous technology landscape makes the data access difficult and error prone.
• The layering would ensure the complexity will be encapsulated and shield the dependant layers.

Implication

• This will avoid duplicates and lesser reliance on the data synchronization  with in the same data source.
• The heterogeneous environment and lack of common reference data  will lead to have multiple copies of data maintained across different environments.

Conclusion

The enterprise undergo rapid changes in business cycles and business models. To meet this challenges it has been widely acknowledged that defining an IT architecture is the most important phase in planning any major development of re-engineering effort.

Solution Architecture  is a foundation component of any architecture program and defining proper standards can be a major driver for flexibility and innovation