What's cool in the new and updated OSGi Specs (2013)

What's cool in the new and updated OSGi specs

What's cool in the new and updated

OSGi Specs
Carsten Ziegeler
David Bosschaert

1 of 50


Speakers
David Bosschaert (david@redhat.com)
JBoss/Fuse at Red Hat
Co-chair OSGi EEG
Open-source and cloud enthusiast
Carsten Ziegeler (cziegeler@apache.org)
RnD Adobe Research Switzerland
OSGi CPEG and EEG Member
ASF member

2 of 50


Agenda
Framework updates
OSGi/CDI integration
Repository update
Declarative Services
Http Service
Cloud
Portable Java Contracts
Semantic Versioning Annotations
Other spec updates

3 of 50


Framework Updates
Service Scopes (RFC 195)

Service Scopes: singleton, bundle, prototyp
Driver: Support for EEG specs (EJB, CDI)
Usage in other spec updates
New PrototypeServiceFactory

4 of 50


PrototypeServiceFactory
public interface PrototypeServiceFactory <S>
extends ServiceFactory <S> {
S getService(Bundle bundle,
B
ServiceRegistration <S> registration);
void ungetService(Bundle bundle,
B
ServiceRegistration <S> registration,
S service);
}

5 of 50


New method in BundleContext:
public interface BundleContext {
<S> ServiceObjects <S> getServiceObjects(ServiceReference <S> ref);
S
}

New Interface ServiceObjects:
public interface ServiceObjects <S> {
S getService();
void ungetService(S service);
}

6 of 50


Data
Transfer
Objects

7 of 50


RFC 185 – Data Transfer Object
Defines a DTO model for OSGi
Serializable/Deserializable objects

Use cases: REST, JMX, Web Console...
To be adopted by other specs

8 of 50


Getting DTOs: adapter pattern
public class BundleDTO extends org.osgi.dto.DTO {
public long id;
public long lastModified;
public int state;
public String symbolicName;
public String version;
}

9 of 50


DTOs for the OSGi framework
FrameworkDTO
BundleDTO

ServiceReferenceDTO
BundleStartLevelDTO, FrameworkStartLevel

CapabilityDTO, RequirementDTO, Resource
BundleWiringsDTO, etc

10 of 50


OSGi/CDI
integration

11 of 50


RFC 193 - CDI Support
Bridging OSGi and standard JavaEE
dependency model
● Publishing CDI beans as OSGi services
● Injecting OSGi services in CDI beans
CDI = Contexts and dependency injection

12 of 50


RFC 193 - Examples
● Publishing CDI bean as OSGi service
@Component
public class MyComponent implements MyInterface { ... }

● Dependency Injection
@Inject
@Service
private MyInterface serviceA;
@Inject
@Service(optional = true )
private MyInterface serviceB;

13 of 50


Repository
1.1

14 of 50


OSGi Repository today

15 of 50


Example Repository namespaces

16 of 50


RFC 187 - Repository 1.1
Existing repository powerful
but: limited to queries in a single namespace
New in RFC 187:
Combine requirements spanning multiple namespaces:
Repository repo = ... // Obtain from Service Registry
Collection <Resource > res = repo.findProviders(
R
repo.getExpressionCombiner().and(
a
repo.newRequirementBuilder("osgi.wiring.package").
addDirective("filter","(osgi.wiring.package=foo.pkg1)").
buildExpression(),
repo.newRequirementBuilder("osgi.identity").
addDirective("filter",
"(license=http://opensource.org/licenses/Apache-2.0)").
buildExpression()));

17 of 50


Declarative
Services

18 of 50


RFC 190 - Declarative Services
Enhancements
Support of service scopes
Diagnostic API
DTOs
But most importantly...

19 of 50


Use annotations for
configuration...
@interface MyConfig {
boolean enabled() default true ;
String [] topic() default {"topicA", "topicB"};
String userName();
int service_ranking() default 15;
}

20 of 50


...and reference them in
lifecycle methods
@Component
public class MyComponent {
String userName;
String [] topics;
@Activate
protected void activate(final MyConfig config) {
f
if ( config.enabled() ) {
this .userName = config.userName();
this .topics = config.topic();
}
}
}

21 of 50


...or even simpler...
@Component
public class MyComponent {
private MyConfig configuration;
@Activate
protected void activate(final MyConfig config) {
f
if ( config.enabled() ) {
this .configuration = config;
}
}
}

22 of 50


Annotation Mapping
Fields registered as component
properties
Name mapping (_ -> .)
Type mapping for configurations

23 of 50


Mapping
@interface MyConfig {
boolean enabled() default true ;
String [] topic() default {"topicA", "topicB"};
String userName();
int service_ranking() default 15;
}

24 of 50


RFC 190 - Declarative Services
Enhancements
Annotation configuration support
Support of service scopes
Diagnostic API
DTOs

25 of 50


HTTP
Service

26 of 50


RFC 189 - Http Service
Update
Update to Servlet API 3+
Whiteboard support for
Servlets, Servlet Filters
Listeners, Resources and HttpContexts
and DTOs

27 of 50


Whiteboard Servlet Registration
@Component(service = javax.servlet.Servlet .class ,
S
c
scope="PROTOTYPE",
property ={
"osgi.http.whiteboard.servlet.pattern=/products/*",
})
public class MyServlet extends HttpServlet {
...
}

28 of 50


Whiteboard Servlet Filter
Registration
@Component(service = javax.servlet.Filter .class ,
F
c
scope="PROTOTYPE",
property ={
"osgi.http.whiteboard.filter.pattern=/products/*",
})
public class MyFilter implements Filter {
...
}

29 of 50


Additional Support
Most listener types are supported
Register with their interface
Error Pages and Resources
Shared HttpContexts
Target Http Service

30 of 50


Cloud

31 of 50


Current PaaS offerings...

32 of 50


OSGi Cloud Ecosystems PaaS

33 of 50


An OSGi cloud ecosystem...
Many frameworks
○ hosting a variety of deployments

Together providing The Application
Not a bunch of replicas
○ rather a collection of different nodes
○ with different roles working together
○ some may be replicas

Load varies over time
... and so does your cloud system
○ topology
○ configuration
○ number of nodes
○ depending on the demand

34 of 50


To realize this you need...
Information!
○ need to know what nodes are available
○ ability to react to changes

Provisioning capability
Remote invocation
○ inside your cloud system
○ to get nodes to communicate
○ either directly...
○ ... or as a means to set up communication channels

35 of 50


RFC 183 - Cloud Ecosystems
FrameworkNodeStatus service:
information about each Cloud node
accessible as a Remote Service
throughout the ecosystem

Information such as:
Hostname/IP address
Location (country etc)
OSGi and Java version running
A REST management URL
Runtime metadata
Available memory / disk space
Load measurement

... you can add custom metadata too ...

36 of 50


FrameworkNodeStatus service properties
37 of 50


RFC 182 - REST API
A cloud-friendly remote management API
works great with FrameworkNodeStatus
Example:
addingService(ServiceReference <FrameworkNodeStatus > ref) {
S
F
// A new Node became available
String url = ref.getProperty("org.osgi.node.rest.url");
RestClient rc = new RestClient (new URI(url));
n

// Provision the new node
rc.installBundle(...);
rc.startBundle(...);
}

38 of 50


Additional ideas in RFC 183
Special Remote Services config type
・ osgi.configtype.ecosystem

・ defines supported Remote Service data types
・ not visible outside of cloud system

Ability to intercept remote service calls
・ can provide different service for each client
・ can do invocation counting (quotas, billing)

Providing remote services meta-data
・ quota exceeded
・ payment needed

・ maintenance scheduled

39 of 50


Current OSGi cloud work
Provides a base line
○ to build fluid cloud systems
○ portability across clouds
Where everything is dynamic
○ nodes can be repurposed
... and you deal with your cloud nodes
through OSGi services

40 of 50


Portable
Java
Contracts

41 of 50


Semantic Versioning...
... is a versioning policy for exported packages.
OSGi versions: <major>.<minor>.<micro>.<qualifier>
Updating package versions:
● fix/patch (no change to API):
update micro
● extend API (affects implementers, not clients):
update minor
● API breakage:
update major
Note: not always used for bundle versions

42 of 50


Semantic Versioning is great, but...
- not all projects use it, e.g. APIs from JSRs
- e.g. Servlet 3 is backward compatible with 2.5
- what's its javax.servlet package version?
2.6 ?
or 3.0 ?

- different projects made different choices

43 of 50


RFC 180: Portable Java Contracts
osgi.contract capability to the rescue
● client bundle requires capability
with 'marketing' or 'spec' version

● and also imports the package without version

osgi.contract provider binds the contract version to package versions
Import -Package : javax.servlet, javax.servlet.http
P
Require -Capability : osgi.contract;
C
filter:="(&(osgi.contract=JavaServlet)(version=3.0))"

Allows writing portable bundles that import non-semant
versioned packages.

44 of 50


Type and
Package
Annotations

45 of 50


RFC 197 – OSGi Type and
Package Annotations
Annotations for documenting semantic
versioning information
Class retention annotations

@Version
@ProviderType
@ConsumerType

46 of 50


Other
Enterprise
Spec
updates
47 of 50


▻ Blueprint 1.1

・ Non-damped service references
・ Grace period enhancements
・ Many small fixes

▻ Remote Service Admin 1.1

・ Remote Service registration modification

▻ Subsystems 1.1

・ Provide Deployment Manifest separately
・ Many small enhancements

48 of 50


When can I get it?
RFCs available to everyone today:
https://github.com/osgi/design
(https://github.com/osgi/design)
◎ Most work aimed at Core/Enterprise R6 (2014)
◎ Some specs in Enterprise R7 (2015)

49 of 50


Questions?

50 of 50

What's cool in the new and updated OSGi Specs (2013)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a What's cool in the new and updated OSGi Specs (2013)

Similar a What's cool in the new and updated OSGi Specs (2013) (20)

Más de David Bosschaert

Más de David Bosschaert (11)

Último

Último (20)

What's cool in the new and updated OSGi Specs (2013)