Subsystems for those occasions where bundles are just too small... - Tom Watson

COPYRIGHT © 2008-2012 OSGi Alliance. All Rights Reserved, © IBM Corp. 2012

Subsystems:for those occasions where bundles are just too small

Tom Watson

IBM

March 27st 2012

OSGi Alliance Marketing © 2008-2010 . All Rights Reserved Page 1

Page 2 OSGi Alliance Marketing © 2008-2012 . All Rights Reserved,© IBM Corp. 2012

Agenda

MotivationModelTypesMeta-dataPackagingLife-cycle and API


Motivation

Enterprise Java platforms are awash with bundle collectionsApache Aries – ApplicationsApache Geronimo - ApplicationsApache Karaf – FeaturesEclipse Virgo – Plans, PARsIBM WebSphere Application Server – Applications and CompositeOracle GlassFish – ApplicationsParemus Service Fabric – SystemsCrying out for standardizationPortabilityToolsEcosystem


Subsystem Model: Hierarchy

Subsystem Hierarchy Each has 1 or more parents (except root)

subsystem

root



Subsystem Hierarchy Each has 1 or more parents (except root)Each can have many children subsystem

S1 S2

S3

S4

root

S5



Subsystem Hierarchy Each has 1 or more parents (except root)Each can have many childrenEach is contained in a Region

RegionsProvides isolation for a group of one

or more subsystemsDefined by a scoped subsystem

subsystem

region

S1 S2

S3

S4

root

S5


Subsystem Model: Sharing Policies

Scoped subsystems control the sharing policy

root

S1 S2

bundlerequirementcapability

A BY Y



Scoped subsystems control the sharing policy A region provides isolation

root

S1 S2


A BY Y

X



Scoped subsystems control the sharing policyA region provides isolationSelectively export capabilities to the parent

root

S1 S2


A BY Y

exports Y



Scoped subsystems control the sharing policyA region provides isolationSelectively export capabilities to the parentSelectively import capabilities from the parent

root

S1 S2


A BY Y

imports Y exports Y



Scoped subsystems control the sharing policyA region provides isolationSelectively export capabilities to the parent

Selectively import capabilities from the parent

Unscoped subsystemsshare everything with other

subsystems contained in the same region S1 S2

U1

root


A BY Y

imports Y exports Y

CY


Subsystem Types: Features

Collection of Resources (e.g. Bundles)

AB

CD



Collection of Resources (e.g. Bundles)Shared life-cycle

F2F1

AB

CD



Collection of Resources (e.g. Bundles)Shared life-cycleCan have children

F2F1

AB

CD

F3F



Collection of Resources (e.g. Bundles)Shared life-cycleCan have childrenNo scoping, able to share resources

F2F1

ABE

C

ED

sharedresource

F3F



Collection of Resources (e.g. Bundles)Shared life-cycleCan have childrenNo scoping, able to share resourcesMust be contained within a region

F2F1

ABE

C

ED

sharedresource

F3F

S1



Collection of Resources (e.g. Bundles)Shared life-cycleCan have childrenNo scoping, able to share resourcesMust be contained within a

regionExamples: Karaf Features, Virgo unscoped Plans

F2F1

ABE

C

ED

sharedresource

F3F

S1


Subsystem Types: Composite

C2C1

X X

Y Y

Coarse-grained sub-assembly module



C2C1

Root

X X

Y Y

Import XExport Y

Import YExport X


Explicit export and import of capabilities (e.g. packages, services)



C2C1

A

B

C

D

Root

X X

Y Y

Import XExport Y

Import YExport X



Composed of Resources (e.g. Bundles)



C2C1

A

B

C

D

Root

E E

X X

Y Y

Import XExport Y

Import YExport X




Scoped



C2C1

A

B

C

D

Root

E E

X X

Y Y

Import XExport Y

Import YExport X




ScopedExamples: RFC 138 Composite

Bundles*, WebSphere Composite Bundles

*old design prior to resolver hooks


Subsystem Types: Application

A

B

C

E

X X

YY

E

Y

B

Y

Used for composing hosted applications using Resources (e.g. Bundles)



A2A1

A

B

C

E

X X

YY

E

Y

B

Y


Scoped



A2A1

A

B

C

Root

E

X X

C

YY

E

Y

B

Y


ScopedNo exporting capabilities,

implicit imports of dependencies



A2A1

A

B

C

Root

E

X X

C

YY

E

Y

B

Y


ScopedNo exporting capabilities,

implicit imports of dependencies

Examples: Aries Application, Virgo Scoped Plans, Virgo PARs


Example Combination

Subsystem Types can be mixed ‘n’ matchedExample shows:Features used to assemble a CompositeComposite providing a ‘platform’ to Applications

C1

Root

F2F1

A

B

C

D

E E

X X

Y Y

A2A1

F FX X

G H


Subsystem Meta-data

Manifest format with relaxed rulesOSGI-INF/SUBSYSTEM.MF

Some headers unique to Subsystem typeCommon concepts use same headersHeaders cover:Identity and typeContentSharing policyHuman readable information


Subsystem Meta-data: Identity Headers

Identified by symbolic name version

Manifest-Version: 1.0Subsystem-ManifestVersion: 1.0Subsystem-SymbolicName: my.first.subsystemSubsystem-Version: 1.0.0


Subsystem Meta-data: Type Header

Type governs the sharing policyStandard Types:osgi.subsystem.applicationosgi.subsystem.compositeosgi.subsystem.featureOne directive specified for controlling where dependencies are installed

Manifest-Version: 1.0Subsystem-ManifestVersion: 1.0Subsystem-SymbolicName: my.first.subsystemSubsystem-Version: 1.0.0Subsystem-Type: osgi.subsystem.application; provision-policy:=acceptDependencies


ContentIdentifies the resources contained in the SubsystemResources identified by name, version (range) and typeComposites only allow fixed versionsStandard typesosgi.bundle (default)osgi.fragmentsubsystem typesCan be optional

Manifest-Version: 1.0Subsystem-ManifestVersion: 1.0Subsystem-SymbolicName: my.first.SubsystemSubsystem-Version: 1.0.0Subsystem-Type: osgi.subsystem.application; provision-policy:=acceptDependenciesSubsystem-Content: an.osgi.bundle1;version="[1.0, 1.1)", an.osgi.subsystem; type=osgi.subsystem.application; version="[1.2, 1.3)"


Explicit Sharing

Composite subsystems share nothing unless explicitly statedRe-use existing bundle headers where applicableNot applicable for implicitly isolated subsystems (i.e. Features and Applications)

Manifest-Version: 1.0Subsystem-ManifestVersion: 1.0Subsystem-Name: A Composite SubsystemSubsystem-Description: This is a Composite SubsystemSubsystem-SymbolicName: my.first.compositeSubsystem-Version: 1.0.0Subsystem-Type: osgi.subsystem.compositeSubsystem-Content: an.osgi.bundle1;version="[1.0, 1.0]", an.osgi.bundle2;version="[1.0, 1.0]"Subsystem-ExportService: exported.service.Interface; filter:="(color=blue)"Subsystem-ImportService: imported.service.InterfaceExport-Package: an.exported.pkg;version="1.0"Import-Package: an.imported.pkg;version="[1.0, 2.0)"Require-Bundle: a.required.bundle; bundle-version="[1.0, 2.0)"


Informational

Headers for humans Manifest-Version: 1.0Subsystem-ManifestVersion: 1.0Subsystem-Name: First SubsystemSubsystem-Description: This is my first ever Subsystem and it's sooo cool.Subsystem-SymbolicName: my.first.subsystemSubsystem-Version: 1.0.0Subsystem-Type: osgi.subsystem.application; provision-policy:=acceptDependenciesSubsystem-Content: an.osgi.bundle;version="[1.0, 1.1)", an.osgi.subsystem; type:=osgi.subsystem.application; version="[1.2, 1.3)"


PortabilitySubsystem Manifests are portable to a pointTarget Environment + Transitive Dependencies must support the required resource implementation types (e.g. Blueprint, WAB, DS, etc)Deployment manifests may be portableDifferent Target Environments likely to require different Transitive Dependencies

Subsystem Definition

Target Environment

Dependencies


Packaging

Packaged in a Subsystem ArchiveA zip file with .esa extension:Subsystem Manifest (optional)Deployment Manifest (optional)Resources (optional)

my.first.subsystem.esa

OSGI-INF/SUBSYSTEM.MF

OSGI-INF/DEPLOYMENT.MF

an.osgi.bundle-1.0.0.jar

an.osgi.bundle2-1.0.0.jar


Subsystem ServiceLife-cycle managementInstall, start, stop, uninstall

Each subsystem logically has it’s own Subsystem serviceNavigationgetParents, getChildren, getConstituents

IntrospectiongetHeaders, getState, getSymbolicName, getVersion, getLocation

C1

Root

F2F1

A

B

C

D

A2A1

F F

G H

C1, F1, F2(A1, A2)

A1 A2

(ALL)


Subsystem Lifecycle: Installing

Root(Subsystem)

Root Subsystem Service


Subsystem Lifecycle: InstallingRoot Subsystem Service

used to install subsystems

Root(Subsystem)

A1

install()

installing


Subsystem Lifecycle: Installing

A1

Root(Subsystem)

A, B, C, D,E, F, G

install()

installing

Root Subsystem Serviceused to install subsystems

Repository based provisioning




Repository based provisioningContent Resources (specified by

Subsystem-Content header)A1

Root(Subsystem)

A, B, C, D,E, F, G

install()

installing

A

B





Subsystem-Content header)Dependencies

A1

Root(Subsystem)

A, B, C, D,E, F, G

install()

installing

A

B

E

F





Subsystem-Content header)Dependencies

A1

Root(Subsystem)

A, B, C, D,E, F, G

installed

A

B

E

F





Subsystem-Content header)DependenciesShare capabilities

A1

Root(Subsystem)

A, B, C, D,E, F, G

installed

A

B

E

F

A2C

D

G

installed


Subsystem Lifecycle: Starting

A2A1

Root

A

B

C

D

E G

F

start()

Subsystem Serviceused to start subsystems



A2A1

Root

A

B

C

D

E G

F

start()

starting


Effect on referenced resources



A2A1

Root

A

B

C

D

E G

F

start()

starting


Effect on referenced resourcesDependencies are started when one

subsystem that uses them is started



A2A1

Root

A

B

C

D

E G

F

start()

starting




Content resources are started



A2A1

Root

A

B

C

D

E G

F

active

start()






Subsystem Lifecycle: StartingSubsystem Service

used to start subsystems




A2A1

Root

A

B

C

D

E G

F

active active


Subsystem Lifecycle: Stopping

A2A1

Root

A

B

C

D

E G

F

active active

stop()

Subsystem Serviceused to stop a subsystem



A2A1

Root

A

B

C

D

E G

F

stopping started

stop()





A2A1

Root

A

B

C

D

E G

F

stopping started

stop()


Effect on referenced resourcesContent resources are stopped



A2A1

Root

A

B

C

D

E G

F

stopping started

stop()


Effect on referenced resourcesContent resources are stoppedDependencies are stopped when no

subsystems that use them are active



A2A1

Root

A

B

C

D

E G

F

resolved started






A2A1

Root

A

B

C

D

E G

F

resolved started

stop()






A2A1

Root

A

B

C

D

E G

F

resolved resolved





Subsystem Lifecycle: Uninstalling

A2A1

Root

A

B

C

D

E G

F

resolved

uninstall()

resolved

Subsystem Serviceused to uninstall a subsystem



A2A1

Root

A

B

C

D

E G

F

uninstalling resolved

uninstall()





A2A1

Root

A

B

C

D

E G

F


uninstall()


Effect on referenced resourcesContent resources are uninstalled



A2A1

Root

C

D

E G

F


uninstall()


Effect on referenced resourcesContent resources are uninstalledDependencies are uninstalled when

no subsystem is installed that uses them



A2A1

Root

C

D

G

F

uninstalled resolved






A2A1

Root

C

D

G

F

uninstalled resolved

uninstall()






A2A1

Root

uninstalleduninstalled





Summary

Subsystems are the standard way to manage groups of resourcesRepository based provisioning of subsystem content and

dependenciesSubsystem types define sharing semantics API enables management of Subsystem life-cycleStandardized meta-data and packaging (.esa file)


IBM and WebSphere are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.

Trademarks

Subsystems for those occasions where bundles are just too small... - Tom Watson

Technology

osgi alliance marketing

subsystem types

subsystem model

af1f2regionff3 page

page reservedcopyright

bd yyc1c2 page

bundles ac bd page

scoped subsystems3s4s5