WAS v8.5 > Deploy applications > Deploy SCA composites > Deploy OSGi applications that use SCAMultiple SCA implementation packaging considerations
WAS v8.5 supports several implementation technologies that can provide the business logic for SCA service components. Because a primary architectural objective of SCA is to enable you to combine existing services together, it is easy to assume that a single composite with multiple components might have different implementation technologies. However, there are restrictions that limit packaging of multiple SCA implementations.
Business-level application deployment constraints
Before deploying an SCA application, particularly one that uses an OSGi application, consider the following constraints:
- Collocation
SCA composites can be comprised of a variety of implementation frameworks. Packaging formats for these frameworks include, for example, EAR files for Java EE applications or enterprise bundle archive (EBA) files for OSGi applications. An SCA business-level application must contain both the framework packaging format and the SCA composite that uses it.
In a Network Deployment environment, when deploying an implementation.osgiapp in an SCA composition unit, the EBA composition unit used for the implementation must be in the same business-level application and targeted to the same server or cluster as the SCA composition unit.
- Artifacts or shared libraries
Business-level applications support shared libraries. It typically is good practice to package interface artifacts (Java interface classes or WSDL/XSD artifacts) in a shared library. Services in applications configured in a business-level application can reference the shared library.
However, OSGi applications do not support shared configuration libraries. You must package Java interface and WSDL/XSD artifacts in both the SCA contribution JAR file and the EBA asset that is configured in the business-level application.
- Only one deployment
Only one instance of a given OSGi application, packaged as an EBA file, can be deployed in a Network Deployment cell. An EBA file can contain only one OSGi application. An EBA asset can contain only one EBA file. An EBA asset can be added to only one business-level application, which is scoped at cell-level. Therefore, we can specify only once that a given OSGi application be an SCA implementation.
To get around this constraint, we can connect to a deployed OSGi application from other applications in the cell, but we cannot include the business logic in another composite.
Class loading
A purpose of the OSGi application framework is to build a class loader structure that is wholly defined by the OSGi service registry and OSGi application design, and avoid class loader problems that affect Java EE servers.
If the applications use different implementation technologies, differences in class loader structures might cause the SCA run time to copy objects from one environment to another. OSGi applications are remote-only interfaces that do not permit pass-by-reference behavior.
Your SCA application must use correct semantics for local and remote interfaces.
Related concepts:
SCA application package deployment
Related
Use OSGi applications as SCA component implementations