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
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.
Search WWH ::