The
product 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, enterprise archive (EAR) files for Java Platform, Enterprise Edition (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 Java
archive (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, you can specify
only once that a given OSGi application be an SCA implementation.
To
get around this constraint, you can connect to a deployed OSGi application
from other applications in the cell, but you 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
your 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.