There are two ways to deploy the adapter. You can either embed it as part of the deployed application, or you can deploy it as a stand-alone RAR file. The requirements of your environment affect the type of deployment option you choose.
An embedded adapter is bundled within an enterprise archive (EAR) file and is available only to the application with which it is packaged and deployed.
A stand-alone adapter is represented by a stand-alone resource adapter archive (RAR) file, and when deployed, it is available to all deployed applications in the server instance.
While creating the project for your application using IBM® Integration Designer, you can choose how to package the adapter [either bundled with the (EAR) file or as a stand-alone (RAR) file]. Your choice affects how the adapter is used in the run time environment and how the properties for the adapter are displayed on the administrative console.
Choosing either to embed an adapter with your application or to deploy the adapter as a stand-alone module depends on how you want to administer the adapter. If you want a single copy of the adapter and do not care about disruption to multiple applications when you upgrade the adapter, then you would be more likely to deploy the adapter as a stand-alone module.
If you plan to run multiple versions, and if you care more about potential disruption when you upgrade the adapter, you would be more likely to embed the adapter with the application. Embedding the adapter with the application allows you to associate an adapter version with an application version and administer it as a single module.
A class loader affects the packaging of applications and the behavior of packaged applications deployed on run time environments. Class loader isolation means that the adapter cannot load classes from another application or module. Class loader isolation prevents two similarly named classes in different applications from interfering with each other.
Because stand-alone adapters have no class loader isolation, only one version of any defined Java™ artifact is run and the version and sequence of that artifact is undetermined. For example, when you use a stand-alone adapter there is only one resource adapter version, one adapter foundation class (AFC) version, or one third-party JAR version. All adapters deployed as stand-alone adapters share a single AFC version, and all instances of a defined adapter share the code version. All adapter instances using a given third-party library must share that library.
For instance, if you have an adapter that is working with server version X, and you update the version of the client application to version Y, your original application might stop working.
If more than one copy of any JAR file is in the class path in a stand-alone adapter, the one that is used is random; therefore, they all must be the latest version.
When you install multiple adapters with different versions of CWYBS_AdapterFoundation.jar, and if a lower version of the CWYBS_AdapterFoundation.jar is loaded during run time, the adapter returns the ResourceAdapterInternalException error message, due to a version conflict. For example, when you install Oracle E-Business Suite adapter version 7.0.0.3 and WebSphere® Adapter for JDBC version 7.5.0.3, the following error message is displayed "The version of CWYBS_AdapterFoundation.jar is not compatible with IBM WebSphere Adapter for JDBC" as IBM WebSphere Adapter for JDBC loads file:/C:/IBM/WebSphere/ProcServer7/profiles/ProcSrv01/installedConnectors/CWYOE_OracleEBS.rar/CWYBS_AdapterFoundation.jar with version 7.0.0.3. However, the base level of this jar required is version 7.5.0.3. To overcome this conflict, you must migrate all adapters to the same version level.
There are occasions when you work with embedded adapters that do not need a client-server communication, stand-alone adapters that need a server connection, or a hybrid mix of adapter connections.
The following scenarios cover the different behaviors of AFC version conflict detection, when you are deploying two or more adapters and at least one of the adapter version is 7.5 or higher.
Deploying a stand-alone Adapter
At step 5, the deployment fails. At step 6, you get an internal error message due to the AFC version conflict.
Deploying a combination of stand-alone and embedded Adapters
For further assistance, visit http://www.ibm.com/support/docview.wss?uid=swg27006249.