Transplanting the J2EE application to the WebSphere application server (Part 1) Introduction about the J2EE application to the WebSphere application server, although IBM provides a lot of information and articles to illustrate how to transfer applications running on WebLogic to WebSphere On, everyone may still have doubts: Is it different from WebLogic to WebSphere and transplant from Tomcat, JBoss, and RESIN? In fact, a J2EE application can use the same way to WebSphere regardless of whether it is running, this is also the benefit of the J2EE specification to us. However, transplant is often not smooth, and the difficulty of transplant depends not only on the J2EE application to follow the J2EE specification, but also depends on the portability of the non-J2EE component it uses. For standard J2EE applications, we can complete the transplant task through a fixed step, and for other parts, we can only seek the best solution through patient debugging and exploration to seek the best solution. In this article, we will detail the methods and common problems of transplantation. In the subsequent articles, we will specifically describe the special issues and solutions we have encountered during the transplantation of each platform. This article assumes that you are familiar with the J2EE specification and develop the J2EE application deployed on the WebSphere application server using WebSphere Studio Application Developer. After reading this article, it is recommended that everyone will start from the test, complete the sample programs in the reference document, thus having a more specific understanding of the transplant task. Method 1. Learn WebSphere Studio Application Developer, see Reference Document 1. Second, select the most representative subsystem 1 from the application, this subsystem should fully cover the technical difficulties of the system, see common problems 2, summarize the configuration required by the summary system and the dependent class library three, analysis The architecture of this subsystem clarifies the dependencies 1 between each module, including the dependencies between the service modules, and the dependencies between the web modules and the EJB modules and the like. 2. If there are too many cross-references in the application, you can consider adjusting the architecture and file organizational structure of the system to a certain extent to avoid cross calls between modules. 3. Be sure to avoid multiple copies of the same Java class or class library in multiple modules running in the same Java virtual machine. 4. Packing this peeling out and re-adjusted sub-system package, and verifying its availability on the original J2EE server 1. You can run this subsystem 2 separately on the original J2EE server, configure the system and the required class library For WebSphere re-planning, in order to be able to effectively complete this step, we must first familiarize with WebSphere's basic concepts, including the architecture of WebSphere ClassLoader, see Reference Document 2. 3. The sub-system passed by the test is packaged into an EAR file. In the WebSphere Studio Application Developer, fix all build errors based on the error prompt provided by the task view. WebSphere Studio Application Developer provides a very good error diagnostic mechanism that allows developers to easily locate and fix errors in the application, and based on errors, developers can easily find the corresponding chapter in the J2EE specification, View Details 5. Understand the architecture of WebSphere ClassLoader, re-plan the shared class library 1, avoid copying 2 2 in multiple modules 2, try to provide a portable J2EE application packaging plan, in deployment to different J2EE server does not need to do any changes 3, recommended solutions
For the JAR file shared in the web module to move the JAR file to the webproject / webapplication / web-INF / LIB folder, the JAR file is automatically loaded and active at runtime for all EJB modules and web modules. JAR files in CCP A) Import JAR files into the root directory of the EAR project; b) Add the dependency on the JAR file by modifying the manifest file in the EJB project and web project. Note: It is not recommended to add the JAR file through the ClassPath of the J2EE application server, which reduces the portability of the application. To avoid different versions of the JAR file, if you contain multiple versions in the original system, you only keep one of them. Sixth, debug subsystem 1, first using the general test client (UTC) of WebSphere Studio Application Developer to debug 2, client application and server application docking, debug client program seven, export subsystem For the EAR file, publish to the WebSphere application server, test eight, estimate the workload of the transfer subsidiary, division of labor completion of nine, integrated test Common issues, for the J2EE standard, there is almost no J2EE application, After any changes, you can run on the WebSphere application server, one of which is that most applications do not fully follow the J2EE specification, and many J2EE application servers are partially relaxed to the application limitations. 1. When to use PortableRemoteObject to perform object styling Based on IIOP protocol, we need to use PortableRemoteObject to convert the returned Stub object, and the T3 protocol used based on WebLogic is optional. If Stub corresponds to a remote interface, this method is necessary If the STUB corresponds to a local interface, this method is optional if this method is used if it is not needed (e.g., accessing the EJB accesses the local interface), the system can run normally, but not recommended; if it is required In the case of this method, if this method is not used, such as an EJB access to the remote interface, then the system will throw ClassCastexception 2, EJB reference
According to the EJB 2.0 specification, use the local JNDI context (Java: Comp / ENV) to find EJB is necessary. However, many J2EE servers are relaxed to this, while using the global JNDI context, it can also run normally. However, WebSphere strictly follows this constraint. In the deployment descriptor, you need to add an EJB to reference each EJB Home requires a global JNDI name, and the binding information will be stored in the IBM-EJB-JAR-BND.XMI file in WebSphere, each EJB reference (EJB) -ref must be bound to a global JNDI name; in WebLogic, the global JNDI name is not always necessary. When using EJB-LINK, the global JNDI name is optional If you use EJB remote interface, according to specification It needs to be accessed through local JNDI names and EJB references. If you use the global JNDI name access, you can also run normally in WebSphere, but this operation is illegal, and it may result in future incompatible problems 3, for the EJB reference for local interfaces
In WebSphere, if you do not use a local JNDI name to find local EJB, you will be wrong without using portableremoteObject to make the type conversion. You must use the local JNDI name. You must use the EJB reference 4, the built error
First fix an error message for deployment descriptors. Depending on the task view prompt, you can easily locate and repair errors (mainly including the version information of the deployment descriptor, JNDI name, various references, etc.) and then locate and repair compilation errors based on the task view (such as the loss of Java Class, etc. 5. The RemoteException bean method is not allowed to throw the RemoteException MDB in the method of the RemoteException bean method is not allowed to throw the application exception, because there is no call relationship between the application and the MDB, J2EE1.3 Features 1. CMP2.0 Connection Factory Deployment in WebSphere If we create a data source called JDBC / Sample to provide database connections, CMP will use CMP Connection Factory and databases named EIS / JDBC / SAMPLE_CMP Binding. 2. MDB / JMS deployment MDB / JMS deployment will be different on different platforms, but we don't need to care about this difference, just need to care about their configuration on WebSphere, please refer to the reference document 3 174 and 176 pages. 3. Using the EJB of the local interface using the local interface in WebSphere, you need to configure local reference in the deployment descriptor and use the prefix "Java: Comp / Env /" in the client code to perform JNDI queries. 4. J2EE based on form-based authentication
WebLogic uses the WebLogic.Servlet.Security.ServletAuthentication class to implement a form-based authentication; WebSphere uses the J_Security_Check servlet in the J2EE specification for form-based authentication. Third, the client's transplantation problem is a variety of various, which can be a servlet, jsp, java application, a delphi client, etc., and the way the client program and server-side program communicating is also a variety of ways, can pass HTTP, RMI / IIOP, SOAP, Web Services, etc. We need to pay attention to the following points in the transplantation process: 1, Java Application client
If the Java Application client uses the HTTP request to access the WebSphere application server, you can use the JDK provided by different vendors. Some points have brought some convenience, but since the T3 protocol is a private protocol, the portability of the application is reduced. The IIOP protocol has brought better portability for the application. Only the IIOP protocol can be used in WebSphere to use the JNDI access, so it is necessary to change the reference to the T3 protocol to IIOP. 3, initial context factory and supplier can be stored in the configuration file, or the Java -D parameter is configured, the following example shows how to set up the initial context factory and supplier in the code
WebLogicProperties h = new property ();
H.PUT (Context.Initial_Context_Factory, "WebLogic.jndi.wlinitialContextFactory";
H.PUT (Context.Provider_URL, "T3: // LocalHost: 7001");
InitialContext CTX = New InitialContext (h);
WebSphere Properties h = new Properties (); h.put (Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory"); h.put (Context.PROVIDER_URL, "iiop: // localhost: 2809 /"); InitialContext ctx = new InitialContext (h); 4, the transaction management (java.user.Transaction) WebLogic (UserTransaction) getInitialContext () lookup ( "javax.transaction.UserTransaction");.. WebSphere (UserTransaction) getInitialContext () lookup ( "JTA / UserTransaction") 5, EJB Interfaces and Stubs required by the client program
Recommended Method A) Add these files to the client's JAR file, or b) packages these files into the new JAR file, then add this JAR file to ClassPath Dynamic Download Interfaces and Stubsrmi protocols to provide dynamic download The features of Interfaces and Stubs, but there are many restrictions, so it is not recommended to use four, data mapping 1. Use third-party data binding techniques (such as toplink, hibernate, castor, kodo, etc.) to increase portability to some extent 2, CMP and CMR
When the name of the EJB is identical to the name of the table and the name of the EJB member variable is consistent with the column name of the table, the top down-down map is selected in WebSphere Studio Application Developer; when EJB's name and table The name inconsistency or the name of the EJB member variable is inconsistent with the column name of the table, and the MEET-IN-MIDDLE will have a MEET-IN-MIDDLE. Each application will have its own unique place. In the transplantation process, more or less other issues exceeding the "common problem" range, I believe it can be solved by patient debugging. In the later articles, we will introduce our specific issues and solutions encountered in the project.
