Java Reference
In-Depth Information
Shared
bundle
Framework
Isolated area
(Application 2)
Isolated area
(Application 1)
2)
B2
A2
A1
B1
Figure 4.5
Isolation allows both Application 1 and Application 2 to share code with a single instance
of a shared bundle without exposing their internal bundles.
means that shared code can contribute packages to multiple applications, but your pay-
ment processing system can only be seen by your online store web application (see fig-
ure 4.5). This is identical to the application semantics for subsystems.
But Aries
EBA
s don't have the notion of features or composites. They also don't
have any option to accept dependencies; all dependencies listed in the
Application-
Content:
header are included in the application, whether they were packaged in the
application archive or not. All dependencies not included in the core content are con-
sidered to be
shared
and scoped
outside
the application, in the shared outer framework.
Bundles can be isolated from one another in several ways, with various advan-
tages and drawbacks. From an application perspective, the mechanism by which iso-
lation is achieved is relatively unimportant; the key detail is that services and
packages exposed by isolated bundles can only be used by other isolated bundles in
the same application.
You'll see an example of using an Aries application in section 4.5, but first we'll
consider some of the other technologies that were also developed before
OSG
i
subsystems.
4.4
Alternative approaches
The main focus of this chapter is the use of the
EBA
as a packaging model for enter-
prise
OSG
i, and the
EBA
will remain the application artifact for the rest of this topic.
Clearly you're keen to start packaging up your example application as soon as possi-
ble, but it wouldn't be fair to continue without at least briefly discussing some of the
alternative application packaging approaches that have been offered for
OSG
i.
