Considerations when refactoring

The enterprise service discovery wizard and the assembly editor that simplify the development of applications through generating artifacts, also create references to the generated artifacts. When you refactor the artifacts, either through the refactoring user interface or manually moving, renaming and deleting objects yourself, these references sometimes will require revisions, which are listed in this section.

We will restrict ourselves to only the refactoring functions in WebSphere® Integration Developer. These refactoring functions are available in the Business Integration view or in an artifact editor such as the business object editor or interface editor. The refactoring functions are described in detail in the Refactoring section.
Refactoring considerations can be examined from these views: In these sections, the refactoring steps are shown by selecting items from the Business Integration navigation, though the same items could have also been selected from the assembly editor.
Note: In the following sections where the updates are performed by the refactoring operation, the results can be viewed in the refactoring wizard's Details view on the Preview page.

Using refactoring on an EIS import or export

Description: Renaming an interface operation with the following steps:
  1. In the interface editor, right-click the operation that you want to change.
  2. From the context menu, select Refactor > Rename Operation.
Problem: The method attribute in the method binding will not match the operation name on the interface.

Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page.

Description: Renaming a module that contains an import or export with an EIS binding by following these steps:
  1. In the Business Integration view, right-click the module that you want to rename.
  2. From the context menu, select Refactor > Rename.
Problem: One of the properties exposed in an EIS import or export binding is the resource adapter Javabean name. In the case of JCA 1.5 resource adapters deployed with the module (that is, you checked Deploy connector with module on the Generate Artifacts page of the enterprise service discovery wizard), the resource adapter Javabean name will contain the concatenated name of the module (Application EAR) and the resource adapter name as specified in the ra.xml deployment descriptor. This specific name is required to perform the correct deployment of the resource adapter instance to the server. A resource adapter instance may provide bi-directional connectivity to multiple EIS instances. A ManagedConnectionFactory JavaBean can be used to provide outbound connectivity to a single EIS instance. An ActivationSpec JavaBean can be used to provide inbound connectivity from an EIS instance. When the module is renamed, the currently deployed server resources such as the ManagedConnectionFactory JavaBean or the ActivationSpec JavaBean that has been created using the old module name become invalid.

Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. Undeploy the current instance of the resource adapter and redeploy.

Using refactoring on a JMS import or export

Description: Renaming an interface operation with the following steps:
  1. In the interface editor, right-click the operation that you want to change.
  2. From the context menu, select Refactor > Rename Operation.
Problem: The operation name on the binding will not match the operation name on the interface.

Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page.

Description: An export with a JMS binding has been dragged and dropped to another module to create a matching import. Now refactoring has occurred by moving the JMS export to another folder within the module by following these steps:
  1. In the Business Integration view, right-click the export that you want to move.
  2. From the context menu, select Refactor > Move.
  3. In the Move Artifact wizard, choose a new location for the export. Click the plus sign to expand the menu to see levels below modules and libraries.
Problem: When an export is moved to another folder within the module, the destinations' JNDI lookup name value in the JMS import becomes invalid.
Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS import's destination JNDI lookup name value to contain the token with the new export name location. For example, these destination elements in an import have been changed as follows:
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithExport/NewExportLocation/ExportName_RECEIVE_D"
	type="javax.jms.Queue" usage="send" />
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithExport/NewExportLocation/ExportName_SEND_D"
	type="javax.jms.Queue" usage="receive" />
Description: An export with a JMS binding has been dragged and dropped to another module to create a matching import. Now refactoring has occurred by renaming the JMS export by following these steps:
  1. In the Business Integration view, right-click the export that you want to rename.
  2. From the context menu, select Refactor > Rename.
Problem: When an export is renamed, the destinations' JNDI lookup name value in the JMS import becomes invalid.
Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS import's destination JNDI lookup name value to contain the token with the new export name location. For example, these destination elements in an import have been changed as follows:
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithExport/NewExportName_RECEIVE_D"
	type="javax.jms.Queue" usage="send" />
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithExport/NewExportName_SEND_D" type="javax.jms.Queue"
	usage="receive" />
Description: An export with a JMS binding has been dragged and dropped to another module to create a matching import. Now refactoring has occurred by renaming the module containing the JMS export by following these steps:
  1. In the Business Integration view, right-click the module that you want to rename.
  2. From the context menu, select Refactor > Rename.
Problem: When the module is renamed, the destinations' JNDI lookup name value in the JMS import becomes invalid.
Correction: The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS import's destination JNDI lookup name value to contain the token with the new export name location. For example, these destination elements in an import have been changed as follows:
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="NewModuleWithExport/ExportName_RECEIVE_D"
	type="javax.jms.Queue" usage="send" />
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="NewModuleWithExport/ExportName_SEND_D" type="javax.jms.Queue"
	usage="receive" />

Description: You have an import with a JMS binding and you deployed it to the server. You want to have an export that will communicate with the import. Note that export has to have the same interface as import. You update the export's destination JNDI names with the JNDI names that the import is using. You retrieve the destination JNDI names from the import's Summary page of the properties view. Then you deploy the export and it will communicate with the import.

Problem: When the import is moved to another folder within the module, the destinations' JNDI lookup name value that might be referenced by the JMS export becomes invalid.

Correction: You undeploy both import and export and then you refactor the import. The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS export's destination JNDI lookup name value to contain the token with the new import name location. For example, these destination elements in an export have been changed as follows:
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithImport/NewImportLocation/ImportName_SEND_D"
	type="javax.jms.Queue" usage="receive" />
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithImport/NewImportLocation/ImportName_RECEIVE_D"
	type="javax.jms.Queue" usage="send" />
Then you redeploy. If you did not deploy originally, then the correction is simple. You refactor the import and the export is updated. Now you are ready to deploy and test.

Description: You have an import with a JMS binding and you deployed it to the server. You want to have an export that will communicate with the import. Note that the export has to have the same interface as the import. You update the export's destination JNDI names with the JNDI names that the import is using. You retrieve the destination JNDI names from the import's Summary page of the properties view. Then you deploy the export and it will communicate with the import.

Problem: When the import name is changed, the destinations' JNDI lookup name value that might be referenced by the JMS export becomes invalid.

Correction: You undeploy both import and export and then you refactor the import. The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS export's destination JNDI lookup name value to contain the token with the new import name. For example, these destination elements in an export have been changed as follows:
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithImport/NewImportName_SEND_D" type="javax.jms.Queue"
	usage="receive" />
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="ModuleWithImport/NewImportName_RECEIVE_D"
	type="javax.jms.Queue" usage="send" />
Then you redeploy. If you did not deploy originally, then the correction is simple. You refactor the import and the export is updated. Now you are ready to deploy and test.

Description: You have an import with a JMS binding and you deployed it to the server. You want to have an export that will communicate with the import. Note that export has to have the same interface as import. You update the export's destination JNDI names with the JNDI names that the import is using. You retrieve the destination JNDI names from the import's Summary page of the properties view. Then you deploy the export and it will communicate with the import.

Problem: When the import's module name is changed, the destinations' JNDI lookup name value that might be referenced by the JMS export becomes invalid.

Correction: You undeploy both import and export and then you refactor the import. The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS export's destination JNDI lookup name value to contain the token with the new import's module name. For example, these destination elements in an export have been changed as follows:
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="NewModuleWithImport/ImportName_SEND_D" type="javax.jms.Queue"
	usage="receive" />
<destination implType="com.ibm.ws.sib.api.jms.impl.JmsQueueImpl"
	target="NewModuleWithImport/ImportName_RECEIVE_D"
	type="javax.jms.Queue" usage="send" />
Then you redeploy. If you did not deploy originally, then the correction is simple. You refactor the import and the export is updated. Now you are ready to deploy and test.

Using refactoring on an MQ JMS import or export

Description: Renaming an interface operation with the following steps:
  1. In the interface editor, right-click the operation that you want to change.
  2. From the context menu, select Refactor > Rename Operation.
Problem: The operation name on the binding will not match the operation name on the interface.

Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page.

Description: Refactoring has occurred and moved the MQ JMS export to another folder within the module by following these steps:
  1. In the Business Integration view, right-click the export that you want to move.
  2. From the context menu, select Refactor > Move.
  3. In the Move Artifact wizard, choose a new location for the export. Click the plus sign to expand the menu to see levels below modules and libraries.
Problem: When an export is moved to another folder within the module, the destinations' JNDI lookup name value in the MQ JMS import becomes invalid.
Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the MQ JMS import's destination JNDI lookup name value to contain the token with the new export name location. For example, these destination elements in an import have been changed as follows:
<send
	target="ModuleWithExport/NewExportLocation/ExportName_MQ_RECEIVE_D"
	type="javax.jms.Queue" />
<receive
	target="ModuleWithExport/NewExportLocation/ExportName_MQ_SEND_D"
	type="javax.jms.Queue" />
Description: Refactoring has occurred and an MQ JMS export has been renamed by following these steps:
  1. In the Business Integration view, right-click the export that you want to rename.
  2. From the context menu, select Refactor > Rename.
Problem: When an export is renamed, the destinations' JNDI lookup name value in the MQ JMS import becomes invalid.
Correction: The necessary updates will be performed by the refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the MQ JMS import's destination JNDI lookup name value to contain the token with the new export name. For example, these destination elements in an import have been changed as follows:
<send target="ModuleWithExport/NewExportName_MQ_RECEIVE_D"
	type="javax.jms.Queue" />
<receive target="ModuleWithExport/NewExportName_MQ_SEND_D"
	type="javax.jms.Queue" />
Description: Refactoring has occurred and renamed a module containing an MQ JMS export by following these steps:
  1. In the Business Integration view, right-click the module that you want to rename.
  2. From the context menu, select Refactor > Rename.
Problem: When the module is renamed, the destinations' JNDI lookup name value in the MQ JMS import becomes invalid.
Correction: The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the MQ JMS import's destination JNDI lookup name value to contain the token with the new export name location. For example, these destination elements in an import have been changed as follows:
<send target="NewModuleWithExport/ExportName_MQ_RECEIVE_D"
	type="javax.jms.Queue" />
<receive target="NewModuleWithExport/ExportName_MQ_SEND_D"
	type="javax.jms.Queue" />

Description: You have an import with an MQ JMS binding and you deployed it to the server. You want to have an export that will communicate with the import. Note that the export has to have the same interface as import. You update the export's destination JNDI names with the JNDI names that the import is using. You retrieve the destination JNDI names from the import's Summary page of the properties view. Then you deploy the export and it will communicate with the import.

Problem: When the import is moved to another folder within the module, the destinations' JNDI lookup name value that might be referenced by the MQ JMS export becomes invalid.

Correction: You undeploy both import and export and then you refactor the import. The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the MQ JMS export's destination JNDI lookup name value to contain the token with the new import name location. For example, these destination elements in an export have been changed as follows:
<receive
	target="ModuleWithImport/NewImportLocation/ImportName_MQ_SEND_D"
	type="javax.jms.Queue" />
<send
	target="ModuleWithImport/NewImportLocation/ImportName_MQ_RECEIVE_D"
	type="javax.jms.Queue" />
Then you redeploy. If you did not deploy originally, then the correction is simple. You refactor the import and the export is updated. Now you are ready to deploy and test.

Description: You have an import with a MQ JMS binding and you deployed it to the server. You want to have an export that will communicate with the import. Note that the export has to have the same interface as the import. You update the export's destination JNDI names with the JNDI names that the import is using. You retrieve the destination JNDI names from the import's Summary page of the properties view. Then you deploy the export and it will communicate with the import.

Problem: When the import name is changed, the destinations' JNDI lookup name value that might be referenced by the MQ JMS export becomes invalid.

Correction: You undeploy both import and export and then you refactor the import. The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the JMS export's destination JNDI lookup name value to contain the token with the new import name. For example, these destination elements in an export have been changed as follows:
<receive target="ModuleWithImport/NewImportName_MQ_SEND_D"
	type="javax.jms.Queue" />
<send target="ModuleWithImport/NewImportName_MQ_RECEIVE_D"
	type="javax.jms.Queue" />
Then you redeploy. If you did not deploy originally, then the correction is simple. You refactor the import and the export is updated. Now you are ready to deploy and test.

Description: You have an import with an MQ JMS binding and you deployed it to the server. You want to have an export that will communicate with the import. Note that the export has to have the same interface as import. You update the export's destination JNDI names with the JNDI names that the import is using. You retrieve the destination JNDI names from the import's Summary page of the properties view. Then you deploy the export and it will communicate with the import.

Problem: When the import's module name is changed, the destinations' JNDI lookup name value that might be referenced by the MQ JMS export becomes invalid.

Correction: You undeploy both import and export and then you refactor the import. The necessary updates will be performed by refactoring operation and the results can be viewed in the refactoring wizard's Details view on the Preview page. The refactoring operation will change the MQ JMS export's destination JNDI lookup name value to contain the token with the new import's module name. For example, these destination elements in an export have been changed as follows:
<receive target="NewModuleWithImport/NewImportName_MQ_SEND_D"
	type="javax.jms.Queue" />
<send target="NewModuleWithImport/NewImportName_MQ_RECEIVE_D"
	type="javax.jms.Queue" />
Then you redeploy. If you did not deploy originally, then the correction is simple. You refactor the import and the export is updated. Now you are ready to deploy and test.

Refactoring artifacts manually without using the refactoring wizard

Refactoring artifacts without using the refactoring wizard affects the following artifacts:

Business objects and XSD files

Interfaces and WSDL files

Imports and exports

Exports

A shortcut often used to create an import with a JMS binding is to drag an export with a JMS binding from one module into the module where you want to create the import. However, if you refactor the interface of the original export, it will not modify the interface of the import accordingly. This section describes the manual steps you would need to perform to correct the interface of the import.

Moving an export with a JMS binding to another module to create an import (drag and drop scenario)

Note: The drag and drop scenario is not supported with an MQ JMS binding.

Modules

Libraries

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.