Download pdf - Subsystems: For those occasions where bundles are just too small... - Graham Charters

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

Subsystems: for those occassions where bundles are just too small

Graham Charters

IBM

21st September 2011

OSGi Alliance Marketing © 2008-2010 .

All Rights Reserved

Page 1

Page 2 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved,

© IBM Corp. 2011

21.09.2011

Disclaimer

• Subsystems is an in-progress RFC. What follows is a

snapshot in time of the expert group thinking and is

subject to change.


© IBM Corp. 2011

21.09.2011

Agenda

• Motivation

• Model

• Development Meta-data

• Deployment Meta-data

• Packaging

• Life-cycle

• API


© IBM Corp. 2011

21.09.2011

Motivation

• Enterprise Java platforms are awash with bundle

collections

• Apache Aries – Applications

• Apache Geronimo - Applications

• Apache Karaf – Features

• Eclipse Virgo – Plans, PARs

• IBM WebSphere Application Server – Applications

and Composite

• Oracle GlassFish – Applications

• Paremus Service Fabric – Systems

• Crying out for standardization

• Portability

• Tools

• Ecosystem


© IBM Corp. 2011

21.09.2011

Subsystems Model: Hierarchy

• Most common model is

hierarchy and so

Subsystems are no

different • Each has 1 parent

• Each can have many children

• Children of the same parent

are siblings

• Visually represented by

containment

subsystem

subsystem

subsystem

subsystem

subsystem

subsystem subsystem


© IBM Corp. 2011

21.09.2011

Subsystem Model: Sharing Policies

• Subsystems may provide and consume capabilities

• E.g. packages, services, etc…

• Different subsystem types have different default sharing

policies

• E.g. share everything, share nothing, provide nothing

• Subsystem types that provide isolation may also have

affinity – i.e. prefer the capabilities of their contents


© IBM Corp. 2011

21.09.2011

Feature Subsystems

• Collection of Resources

(e.g. Bundles)

• Shared life-cycle

• Can be nested

• No isolation or affinity

• Repository-based

provisioning

• Examples: Karaf

Features, Virgo unscoped

Plans

feature

bundle

bundle

bundle

bundle

bundle

bundle

feature


© IBM Corp. 2011

21.09.2011

Composite Subsystems

• Coarse-grained sub-

assembly module

• Isolated

• Explicit share in/out

• Affinity


provisioning

• Examples: RFC 138

Composite Bundles*,

WebSphere Composite

Bundles

*old design prior to resolver hooks

composite

bundle

bundle

bundle

bundle

bundle

bundle


© IBM Corp. 2011

21.09.2011

Application Subsystems

• Model for hosted

applications

• Isolated

• No sharing out, implicit

sharing in

• Affinity


provisioning

• Examples: Aries

Application, Virgo Scoped

Plans, Virgo PARs

application

bundle bundle

bundle

bundle

bundle


© IBM Corp. 2011

21.09.2011

Example Combination

• Subsystem Types can be

mixed ‘n’ matched

• Example shows: • Features used to assemble a

Composite

• Composite providing a ‘platform’ to

Applications

framework

composite

application

feature feature

feature

application


© IBM Corp. 2011

21.09.2011

Developer Headers

• Manifest format with relaxed rules

• Common concepts use same headers

• Some headers unique to Subsystem type

• Headers cover:

• Identity

• Content

• Isolation policy

• Human readable information


© IBM Corp. 2011

21.09.2011

Identity Headers

• Identified by symbolic

name and version

• All subsystem types

live in the same

namespace so type

not part of the identity

Manifest-Version: 1.0

Subsystem-ManifestVersion: 1.0

Subsystem-SymbolicName:

my.first.subsystem

Subsystem-Version: 1.0.0


© IBM Corp. 2011

21.09.2011

Type Header

• Type governs the sharing policy

• Standard Types:

• osgi.application (the default)

• osgi.composite

• osgi.feature

• All subsystem types live in

same resource type

(osgi.subsystem), so their

subsystem type is not part of

their identity

• One directive used in

provisioning (see later)




my.first.subsystem


Subsystem-Type:

osgi.application;

provision-policy:=acceptTransitive


© IBM Corp. 2011

21.09.2011

Content

• Identifies the resources

contained in the Subsystem

• Resources identified by name,

version (range) and type

• Composites only allow fixed

versions

• Standard types

• osgi.bundle (default)

• osgi.subsystem

• osgi.configuration*

• Can be optional

*if we get there…




my.first.Subsystem


Subsystem-Type:

osgi.application;


Subsystem-Content:

an.osgi.bundle1;version="[1.0, 1.1)",

an.osgi.subsystem;

type:=osgi.subsystem;

version="[1.2, 1.3)",

an.osgi.config;

type:=osgi.configuration;

version="[1.0, 1.1)";

resolution:=optional


© IBM Corp. 2011

21.09.2011

Informational

• Headers for humans

• Localized just like bundles



Subsystem-Name: First Subsystem

Subsystem-Description:

This is my first ever Subsystem and

it's sooo cool.


my.first.subsystem


Subsystem-Type:

osgi.application;


Subsystem-Content:

an.osgi.bundle;version="[1.0, 1.1)",

an.osgi.subsystem;

type:=osgi.subsystem;

version="[1.2, 1.3)",

an.osgi.config;


version="[1.0, 1.1)"


© IBM Corp. 2011

21.09.2011

Explicit Sharing

• Composite subsystems

share nothing unless

explicitly stated

• Re-use existing bundle

headers where applicable

• Not applicable for implicitly

isolated subsystems (i.e.

Features and

Applications)



Subsystem-Name: A Composite Subsystem

Subsystem-Description:

This is a Composite Subsystem


my.first.composite


Subsystem-Type: osgi.composite

Subsystem-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.Interface

Export-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)"


© IBM Corp. 2011

21.09.2011

Locking down deployment

• Subsystem manifest allows version variability

• Enables flexibility during development

• Bounds operational upgrade

• Desirable to lock down versions during QA

• Carry same deployment from testing to production

• Deployment Manifest

• Locks down contents to specific versions

• Identifies supporting transitive dependencies

• Describes package/service import/export details


© IBM Corp. 2011

21.09.2011

Deployment Manifest

DESCRIPT’N SUBSYSTEM.MF DEPLOYMENT.MF

Boilerplate Manifest-Version: 1.0

Deployment-ManifestVersion: 1.0



Identity +

Subsypte Subsystem-SymbolicName:

my.first.subsystem


Subsystem-Type: osgi.application


my.first.subsystem


Content Subsystem-Content:

an.osgi.bundle;version="[1.0, 1.1)",

an.osgi.subsystem;type:=osgi.subsystem;

version="[1.2, 1.3)",

an.osgi.config;type:=osgi.configuration;

version="[1.0, 1.1)";

resolution:=optional

Deployed-Content:

an.osgi.bundle;type:=osgi.bundle;

deployed-version=1.0.0,



an.osgi.config;type:=osgi.configuration;

deployed-version=1.0.5

Transitive

Dependencies <Only part of the deployment> Provision-Resource:

an.osgi.bundle2;type:=osgi.bundle;




Sharing Policy <Implicit for Application Subsystems> Deployed-ServiceImport:

(objectClass=an.osgi.Service)

Import-Package:

a.pkg;version="1.0.0",

a.pkg2;version="1.4"


© IBM Corp. 2011

21.09.2011

application

Service pkg pkg2

Example Manifest-Version: 1.0



my.first.subsystem


Deployed-Content:

an.osgi.bundle;type:=osgi.bundle;




an.osgi.config;



Provision-Resource:





Deployed-ServiceImport:

(objectClass=an.osgi.Service)

Import-Package:

a.pkg;version="1.0.0",

a.pkg2;version="1.4"

bundle2 bundle3

config subsystem

bundle


© IBM Corp. 2011

21.09.2011

Transitive

Dependencies • Provision-Resource identifies

resources to be provisioned in

support of a Subsystem

• A Subsystem can choose to accept

transitive dependencies from itself

and its children

Subsystem-Type: osgi.composite;


• The Root Subsystem always

accepts transitive dependencies

• Sharing policies need to be correct

to ensure children can see their

transitive dependencies

config

bundle

bundle2 bundle3

Service pkg pkg2

Subsystem-Type: osgi.composite;


Subsystem-Type:

osgi.composite

Subsystem-Type:

osgi.application

Transitive Dependencies


© IBM Corp. 2011

21.09.2011

Portability

• Subsystem Manifests are

portable to a point

• Target Environment +

Transitive Dependencies must

support the required resource

implementation types (e.g.

Blueprint, WAB, DS, etc)

• Deployment manifests may

be portable

• Different Target Environments

likely to require different


Subsystem Definition

Target Environment



© IBM Corp. 2011

21.09.2011

Packaging

• Packaged in a Subsystem

Archive

• A zip file with .ssa

extension:

• Subsystem Manifest

(optional)

• Deployment Manifest

(optional)

• Resources

(optional)

my.first.subsystem.ssa

OSGI-INF/SUBSYSTEM.MF

OSGI-INF/DEPLOYMENT.MF

an.osgi.bundle-1.0.0.jar

an.osgi.bundle2-1.0.0.jar


© IBM Corp. 2011

21.09.2011

Life-cycle

• Life-cycle similar to that of

bundles

• Adds ‘transitional states’

to reflect periods where

contents are in process of

changing state

• E.g. INSTALLING,

RESOLVING, …

RESOLVED

UNINSTALLIN

G

STARTING

ACTIVE

STOPPING

un

insta

ll

stop

reso

lve

un

insta

ll

INSTALLING

RESOLVING

UNINSTALLED

INSTALLED UPDATING

update

insta

ll


© IBM Corp. 2011

21.09.2011

Shared resource life-cycle

• Resources may be shared

between Subsystems

• Intersecting Features

• Common transitive

dependencies

• Shared resource states

determined by states of

Subsystems that depend on

them

• State precedence used to

determine shared resource state

• Highest state wins

• All uninstalled == garbage

collection

ACTIVE

RESOLVED

INSTALLED

UNSTALLED


© IBM Corp. 2011

21.09.2011

Example

Composite

transitive bundle

Application

bundle

RESOLVED

RESOLVED

RESOLVED

ACTIVE

Application Subsystem

installed and resolved


© IBM Corp. 2011

21.09.2011

Example

Composite

Application

bundle

transitive bundle transitive bundle

Application

bundle

RESOLVED

ACTIVE ACTIVE

ACTIVE RESOLVED

ACTIVE

ACTIVE

Second Application

Subsystem installed and

started


© IBM Corp. 2011

21.09.2011

Example

Composite

Application

bundle

transitive bundle transitive bundle

Application

bundle

RESOLVED

UNINSTALLED RESOLVED

UNINSTALLED RESOLVED

UNINSTALLED

ACTIVE

Second Application

Subsystem uninstalled


© IBM Corp. 2011

21.09.2011

Example

Composite

Application

bundle

transitive bundle

Application

bundle

UNINSTALLED

UNINSTALLED

UNINSTALLED UNINSTALLED

UNINSTALLED

ACTIVE

First Application Subsystem

uninstalled

transitive bundle UNINSTALLED


© IBM Corp. 2011

21.09.2011

Subsystem Service

• Each subsystem

logically has it’s own

Subsystem service • An environment can choose to

hide for certain subsystems

• Life-cycle management • Install, start, stop, uninstall,

cancel

• Navigation • getParent, getChildren,

getConstituents

• Introspection • getHeaders, getState,

getSymbolicName, getVersion,

getLocation

framework

composite

application

feature feature

feature


© IBM Corp. 2011

21.09.2011

Summary

• Subsystems are the standard way to manage groups of

resources

• Version ranges allow flexibility in resource selection

• Subsystem types define sharing semantics

• Deployment definition

• locks down versions and sharing

• Identifies transitive dependencies

• API enables management of Subsystem life-cycle


© IBM Corp. 2011

21.09.2011

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