Systems which require dynamics and interoperability need a good architecture and clear design principles. OSGi provides this for Java based systems, but for embedded/native systems currently no alternative is available. To fill this gap, Apache Celix is created. Apache Celix is an implementation of the OSGi specification adapted to C, focussed on embedded and distributed platforms. Celix is a new Apache project currently starting up in the Incubator. The goal is, to follow the OSGi specification as much as possible, and grow towards an implementation with most of the OSGi Core and Compendium implemented. To be able to support distributed platforms, the Remote Services from the Enterprise Specification will be implemented. Using Remote Services also makes it possible to create interoperability with Java OSGi. For distributed systems, deployment/distribution is an important aspect. OSGi Apache Ace can be used to maintain and manage deployment to multiple targets. This makes Apache Ace a perfect candidate for deployment of Celix Bundles and Artifacts. This presentation shows how Celix solves the dynamic aspects of OSGi services in C. It will detail differences between the OSGi Specification and the Celix solution.

1. Celix
Universal
OSGi?
Alexander
Broekhuis
alexander.broekhuis@luminis.eu
1

2. Introduc?on
• Alexander
Broekhuis
• At
Luminis
since
2008
• Small
SoEware
House
• Research
and
innova?on
oriented
• Involved
in
Open
Source
(Apache)
• Apache
commiLer
since
2010
2

3. Agenda
• Celix
• Services
in
C
• Dynamic
Assembly
• Remote
Services
• Deployment
• Celix
Status
• Universal
OSGi
• Demo
3
- Introduction, what is OSGi and what has Celix to do with it
- Services in C -> How does Celix solve this
- Dynamic Assembly -> with services, how does Celix wire these together
- Remote Services, why are they important, and how to solve
- Deployment of bundles, how to bundle libraries
- Current status of Celix
- What is Universal OSGi, and what is the relation with Celix
- Demonstration of a simple hello world bundle (and if time permits, an example of service usage)

4. OSGi
is:
• component
based
framework
• allows
dynamic
assembly
of
components
• Java,
so
independent
of
opera?ng
system
OSGi
technology
is
the
dynamic
module
system
for
Java™
OSGi
technology
is
Universal
Middleware.
OSGi
technology
provides
a
service-­‐oriented,
component-­‐based
environment
for
developers
and
offers
standardized
ways
to
manage
the
so@ware
lifecycle.
These
capabiliBes
greatly
increase
the
value
of
a
wide
range
of
computers
and
devices
that
use
the
Java™
plaForm.
4
Assuming OSGi is know by most people, only a short overview.

5. OSGi
"-)*+(( !"#$%&'&($
"-)*+(($.
)*+,* )*+,* )*+,/-0
,$)1(3$. +&/3$
$-. 4-"-)*+(( )*122"-0 )*12
4-"-)*+(($.
!"#$%&'()*+,'-
5
And a simple example of a bundle with a service and the service registry.
The bundle contains a Store service, which is implemented by StoreImpl, and finally there is some code
to interact with the OSGi framework (the Activator).

6. OSGi
!"#$%&"'(")%*+#,
!+-#"
!"#$%& !"#$%&
!"#$%
&"#$%'()*!!
"-)*+(( !"#$%&'&($ +%,'()*!!
"-)*+(($.
)*+,* )*+,* )*+,/-0 !"#$%&'!
("#$%)*+,&-,.!!
,$)1(3$. +&/3$
/0,%(1!"%*&-,.!!
$-. 4-"-)*+(( )*122"-0 )*12
("$%.*23,&-,.!!
4-"-)*+(($.
!"#$%&'!&#!()
*+,-."#$&+/.!!
!"#$%&'()*+,'-
5
And a simple example of a bundle with a service and the service registry.
The bundle contains a Store service, which is implemented by StoreImpl, and finally there is some code
to interact with the OSGi framework (the Activator).

7. Celix
• OSGi
specifica?on
implemented
in
C
• Adapted
where
needed
• Focussed
on
Embedded
Dynamic
Systems
• Based
on
Apache
Felix
• Remote
Services
• Distributed
Systems
• Interoperability
with
Java
6
Celix is an implementation of the OSGi specification in C.
- Without any relation with Java-OSGi, purely focussed on C
- Fundamental differences between C and Java, so there are differences
-- Most important ones:
--- Services -> Later more on this
--- Imported/Exported services instead of packages
- Focus on embedded systems
-- No relation with Java OSGi, can be used in C only environments
- Based on Apache Felix (hence the name Celix)
-- Ported were possible (resolver for example)
-- But not related too!
- Additionally, remote services are important
-- For use in distributed systems
-- But also provides a means to interact with Java OSGi
-- Later more on this.

8. Services
in
C
• Follows
the
OSGi
Specifica?on
• A
Service
Registry
for
tracking
services
• Bundle
Ac?vators
for
registering
services
• Bundle
Lifecycle
for
tracking
Bundle
state
• Structs
instead
of
Interfaces
• Using
func?on
pointers
to
forward
calls
7
Services in C
- Follow the OSGi spec where possible
-- Service Registry
-- Bundle Activators
-- Bundle lifecycle, state and cache
- C has no compilable/runtime interfaces, so services can’t be exposed using an interface
-- Use a struct with function pointers to solve this, more details on next slide

9. Services
in
C
• Service
• Struct
with
func?on
pointers
• Ac?vator
• start
/
stop
Activator <struct>
• Celix
create
+ start Service
registerService + stop
• bundleContext create
pointer
• registry Celix Component
• etc.. getService depends
8
A service is a struct
- Uses function pointers to point to the actual implementation of a function
- An activator creates and initializes the struct
- The struct is registered at the registry as the service
- A component can retrieve this struct, and use the function pointers to use the actual implementation.
-- The component only requires the Struct to be able to compile/link
-- There is no direct link with the implementing component -> See next slide

10. Dynamic
Assembly
• Dynamic
Loading
• Library
Depends
• Using
dlfcn.h
• dlopen
/
dlclose
<shared object> <shared object>
Celix Initializes Provider Realizes
• dlsym
<struct>
Uses
Provider
Service
Initializes <shared object>
Consumer
Depends
9
To be able to dynamically add/remove components from the system, dynamic loading is used.
- Components require the framework for compilation (bundle activator, registry etc) -> Depicted using
“depends”
- The framework needs to “initialize” a component via its activator, this cannot be a direct relation
since components can be added/removed during the runtime.
Dynamic Loading in C:
- libdl
- dlfcn.h
-- dlopen / dlclose for loading/unloading libraries
-- dlsym for library methods

11. Remote
Services
• Remote
Service
Admin
• Enterprise
Specifica?on
• Interoperability
• Protocol
• Tuscany?
• ZeroMQ?
• Google
Protobufs?
10
Remote services
- Follows the Enterprise Specification
-- Hide remote aspects from the user
- Important for distributed environments
- But also important for interoperability -> More about this at Universal OSGi
The idea is clear, the implementation not
- What protocol should be used?
-- Has to be available in Java and C
-- Has to be able to serialize to something usable at both ends
-- Some examples...

12. Remote
Services
«service»
Server Server Client
imported = "true"
«service»
Server ServerStub ServerProxy Registry
remote = "true"
«track»
Remote Proxy
Publisher Publisher
«service»
«service»
Discovery
Discovery
Service
Service
11
How are remote services used:
- In java, reflection is used to create endpoints (stub and proxy) at runtime. Marking a service as
remote is enough to expose it. Discovery is used to publish remote services on the network.
- In C, there is no such thing as reflection, so it is not possible to simple mark a service as remote.
-- Possible solution is to use a bundle with the service stub for a service, and publish this bundle when
remote access is required/requested.
-- The same applies to the server proxy on the client host.

13. Remote
Services
«service»
Server Server Client
imported = "true"
«service»
Server ServerStub ServerProxy Registry
remote = "true"
«track»
Remote Proxy
Publisher Publisher
«service»
«service»
Stubs Discovery Proxies
Discovery
Service
Service
11
How are remote services used:
- In java, reflection is used to create endpoints (stub and proxy) at runtime. Marking a service as
remote is enough to expose it. Discovery is used to publish remote services on the network.
- In C, there is no such thing as reflection, so it is not possible to simple mark a service as remote.
-- Possible solution is to use a bundle with the service stub for a service, and publish this bundle when
remote access is required/requested.
-- The same applies to the server proxy on the client host.

14. Deployment
• Bundling
• Zip
file
with
Shared
Object
Depends
• (.so,
.dll,
.dylib,
...)
• Manifest <shared object>
Celix Initializes
<shared object>
Provider Realizes
• Import
/
Export
<struct>
Uses
Provider
• Run?me Service
• Extracted
to
cache Initializes <shared object>
Consumer
Depends
12
Deployment:
- Java uses JAR (zip) files, which can contain classes, but also additional resources.
- In C libraries cannot contain additional resources.
-- Solution is to use zip files to store the library and resources
-- Like Java, a Manifest is used to import/export services, but also to identify the library to use
-- At runtime this zip file is extracted to the cache, and the library is loaded/unloaded by the
framework.

15. Pla`orm
Support
• Apache
Portable
Run?me
• Linux,
Unix,
Windows,
etc
• Memory
pool
• File
handling
• Threads
• No
RealTime/Embedded
• Reuse
APR
API
13

16. Building
• CMake
• Cross
pla`orm
/
Mul?
IDE
• Framework
• Standard
library
• Bundle
macros
• Create
bundle
zip
• Add
library
and
resources
14

17. Status
-­‐
Framework
• Dynamic
Loading
of
Libraries
• Service
Registry
for
Querying
and
Registering
• Bundles
with
Manifest
for
Deployment
• Service
Tracker
for
tracking
Services
• Bundle
State
and
Life
Cycle
• Bundle
Cache
for
Storing
State
15
Status of Celix

18. Status
-­‐
Extras
• Shell
Implementa?on
for
Inspec?ng
Bundles
• ps/start/stop
command
• Dependency
Manager
for
Dependencies
• Simple
Implementa?on
• Sta?c
Linked
• Open
Source
at
Apache
• Currently
in
the
Incubator
16
Besides the framework, there are some additional items to make it easier to use/debug the framework.
These are all ported from Java (Felix) to C.
Finally, Celix is open sources at Apache, and currently in the Incubator.
We are always looking for more community members to support/use/implement Celix.

19. Universal
OSGi
• RFP-­‐89
• Proposed
to
the
mailing
list
in
2007
• Since
then
remained
silent
• Ongoing
effort
to
pick
up
again
• Supported
Languages
• C++
/
.NET
language
(C#)
/
ECMAScript
• What
about
C?
• Interest
from
Community?
17
What is Universal OSGi:
- A RFP proposed in 2007
- After that, silence, but now being picked up again.
The RFP mentions:
- C++/C#/ECMAScript
- But not C
Looking for a community.
- Mailing list can be created.
What has this to do with Celix?

20. Universal
OSGi
-­‐
Celix
• Na?ve
port
in
C
• Status
• Based
on
the
R4
Specifica?on
• Deployable
bundles
• Bundle
lifecycle
• Service
registry
• Framework
API
• Remote
Services
• Standards
for
IPC
and
communica?ons
18
Celix is a native port of the OSGi spec in C.
The RFP requires that an OSGi implementation is based on the R4 Spec
Celix implements:
- Deployable bundles
- Bundle lifecycle
- Service registry
- Most of the Framework API
- Remote Services (planned)
-- Remote services are imported to be able to interact with different implementations of OSGi
-- At the time of the RFP there where no remote service, but they do provide a common/well specced
method to solve this.
-- Remote service should use standards for IPC and com to be able to interact with non-osgi systems.
Can Celix be an implementation of the Universal OSGi RFP? I do think so..
Finally, some examples:

21. Links
• Original
Proposal:
• hLp://wiki.apache.org/incubator/CelixProposal
• Incubator
Mailing
List
Archive:
• hLp://incubator.markmail.org/search/?q=Celix
• Incuba?on
Status:
• hLp://incubator.apache.org/projects/celix.html
• Project
Page:
• hLp://incubator.apache.org/celix/
19