CelixUniversal
OSGi?    Alexander
Broekhuis
   alexander.broekhuis@luminis.eu
Agenda• Celix• Services
in
C• Dynamic
Assembly• Remote
Services• Deployment• Celix
Status• Universal
OSGi• Demo
Celix• OSGi
specificaEon
implemented
in
C • Adapted
where
needed• Focussed
on
Embedded
Dynamic
Systems• Based
on
Apache
Fel...
Services
in
C• Follows
the
OSGi
SpecificaEon • A
Service
Registry
for
tracking
services • Bundle
AcEvators
for
registering
...
Services
in
C• Service • Struct
with
funcEon
pointers• AcEvator • start
/
stop                                            ...
Dynamic
Assembly• Dynamic
Loading • Library                                              Depends • Using
dlfcn.h  • dlopen...
Remote
Services• Remote
Service
Admin • Enterprise
SpecificaEon• Interoperability• Protocol • Tuscany? • ZeroMQ? • Google
P...
Remote
Services                                           «service»     Server                                 Server     ...
Remote
Services                                           «service»     Server                                 Server     ...
Deployment• Bundling • Zip
file
with
Shared
Object                                                     Depends  • (.so,
.dl...
Status
‐
Framework• Dynamic
Loading
of
Libraries• Service
Registry
for
Querying
and
Registering• Bundles
with
Manifest
for...
Status
‐
Extras• Shell
ImplementaEon
for
InspecEng
Bundles • ps/start/stop
command• Dependency
Manager
for
Dependencies • ...
Universal
OSGi• RFP‐89 • Proposed
to
the
mailing
list
in
2007 • Since
then
remained
silent • Ongoing
effort
to
pick
up
agai...
Universal
OSGi
‐
Celix• NaEve
port
in
C• Status • Based
on
the
R4
SpecificaEon  • Deployable
bundles  • Bundle
lifecycle  •...
Links• Original
Proposal: • hdp://wiki.apache.org/incubator/CelixProposal• Incubator
Mailing
List
Archive: • hdp://incubat...
Upcoming SlideShare
Loading in …5
×

Celix, Universal OSGi?

2,050 views

Published on

Apache Celix is an effort, under the Apache Incubator, to implement the OSGi specification in C. There are some distinct changes to be able to map the specification to C.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,050
On SlideShare
0
From Embeds
0
Number of Embeds
147
Actions
Shares
0
Downloads
52
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n \n
  • - Introduction, what is OSGi and what has Celix to do with it\n- Services in C -> How does Celix solve this\n- Dynamic Assembly -> with services, how does Celix wire these together\n- Remote Services, why are they important, and how to solve\n- Deployment of bundles, how to bundle libraries\n- Current status of Celix\n- What is Universal OSGi, and what is the relation with Celix\n- Demonstration of a simple hello world bundle (and if time permits, an example of service usage)\n
  • Assuming OSGi is know by most people, only a short overview.\n\n \n
  • And a simple example of a bundle with a service and the service registry.\nThe bundle contains a Store service, which is implemented by StoreImpl, and finally there is some code to interact with the OSGi framework (the Activator). \n
  • And a simple example of a bundle with a service and the service registry.\nThe bundle contains a Store service, which is implemented by StoreImpl, and finally there is some code to interact with the OSGi framework (the Activator). \n
  • And a simple example of a bundle with a service and the service registry.\nThe bundle contains a Store service, which is implemented by StoreImpl, and finally there is some code to interact with the OSGi framework (the Activator). \n
  • And a simple example of a bundle with a service and the service registry.\nThe bundle contains a Store service, which is implemented by StoreImpl, and finally there is some code to interact with the OSGi framework (the Activator). \n
  • Celix is an implementation of the OSGi specification in C.\n- Without any relation with Java-OSGi, purely focussed on C\n- Fundamental differences between C and Java, so there are differences\n-- Most important ones: \n--- Services -> Later more on this\n--- Imported/Exported services instead of packages\n- Focus on embedded systems\n-- No relation with Java OSGi, can be used in C only environments\n- Based on Apache Felix (hence the name Celix)\n-- Ported were possible (resolver for example)\n-- But not related too!\n- Additionally, remote services are important\n-- For use in distributed systems\n-- But also provides a means to interact with Java OSGi\n-- Later more on this.\n
  • Services in C\n- Follow the OSGi spec where possible\n-- Service Registry\n-- Bundle Activators\n-- Bundle lifecycle, state and cache\n- C has no compilable/runtime interfaces, so services can’t be exposed using an interface\n-- Use a struct with function pointers to solve this, more details on next slide\n
  • A service is a struct\n- Uses function pointers to point to the actual implementation of a function\n- An activator creates and initializes the struct\n- The struct is registered at the registry as the service\n- A component can retrieve this struct, and use the function pointers to use the actual implementation.\n-- The component only requires the Struct to be able to compile/link\n-- There is no direct link with the implementing component -> See next slide\n
  • To be able to dynamically add/remove components from the system, dynamic loading is used.\n- Components require the framework for compilation (bundle activator, registry etc) -> Depicted using “depends”\n- 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. \n\n \n \nDynamic Loading in C:\n- libdl\n- dlfcn.h\n-- dlopen / dlclose for loading/unloading libraries\n-- dlsym for library methods\n\n \n
  • Remote services\n- Follows the Enterprise Specification\n-- Hide remote aspects from the user\n- Important for distributed environments\n- But also important for interoperability -> More about this at Universal OSGi\nThe idea is clear, the implementation not\n- What protocol should be used?\n-- Has to be available in Java and C\n-- Has to be able to serialize to something usable at both ends\n-- Some examples...\n
  • How are remote services used:\n- 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.\n- In C, there is no such thing as reflection, so it is not possible to simple mark a service as remote.\n-- Possible solution is to use a bundle with the service stub for a service, and publish this bundle when remote access is required/requested.\n-- The same applies to the server proxy on the client host.\n
  • Deployment:\n- Java uses JAR (zip) files, which can contain classes, but also additional resources.\n- In C libraries cannot contain additional resources.\n-- Solution is to use zip files to store the library and resources\n-- Like Java, a Manifest is used to import/export services, but also to identify the library to use\n-- At runtime this zip file is extracted to the cache, and the library is loaded/unloaded by the framework.\n
  • Status of Celix\n
  • 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.\nFinally, Celix is open sources at Apache, and currently in the Incubator.\nWe are always looking for more community members to support/use/implement Celix.\n
  • What is Universal OSGi:\n- A RFP proposed in 2007\n- After that, silence, but now being picked up again.\nThe RFP mentions:\n- C++/C#/ECMAScript\n- But not C\nLooking for a community.\n- Mailing list can be created.\n\n \n \nWhat has this to do with Celix?\n
  • Celix is a native port of the OSGi spec in C.\nThe RFP requires that an OSGi implementation is based on the R4 Spec\nCelix implements:\n- Deployable bundles\n- Bundle lifecycle\n- Service registry\n- Most of the Framework API\n- Remote Services (planned)\n-- Remote services are imported to be able to interact with different implementations of OSGi\n-- At the time of the RFP there where no remote service, but they do provide a common/well specced method to solve this.\n-- Remote service should use standards for IPC and com to be able to interact with non-osgi systems.\n\n \n \nCan Celix be an implementation of the Universal OSGi RFP? I do think so..\nFinally, some examples:\n- A hello world example which is only an activator that prints a message when starting/stopping the bundle.\n- (if time permits) An example of the whiteboard pattern with 2 services and a component tracking these services. (using the dependency manager).\n
  • \n \n
  • Celix, Universal OSGi?

    1. 1. CelixUniversal
OSGi? Alexander
Broekhuis
 alexander.broekhuis@luminis.eu
    2. 2. Agenda• Celix• Services
in
C• Dynamic
Assembly• Remote
Services• Deployment• Celix
Status• Universal
OSGi• Demo
    3. 3. Celix• OSGi
specificaEon
implemented
in
C • Adapted
where
needed• Focussed
on
Embedded
Dynamic
Systems• Based
on
Apache
Felix• Remote
Services • Distributed
Systems • Interoperability
with
Java
    4. 4. Services
in
C• Follows
the
OSGi
SpecificaEon • A
Service
Registry
for
tracking
services • Bundle
AcEvators
for
registering
services • Bundle
Lifecycle
for
tracking
Bundle
state• Structs
instead
of
Interfaces • Using
funcEon
pointers
to
forward
calls
    5. 5. Services
in
C• Service • Struct
with
funcEon
pointers• AcEvator • start
/
stop Activator <struct>• Celix create + start Service registerService + stop • bundleContext create pointer • registry Celix Component • etc.. getService depends
    6. 6. 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
    7. 7. Remote
Services• Remote
Service
Admin • Enterprise
SpecificaEon• Interoperability• Protocol • Tuscany? • ZeroMQ? • Google
Protobufs?
    8. 8. 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
    9. 9. 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
    10. 10. 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• RunEme Service • Extracted
to
cache Initializes <shared object> Consumer Depends
    11. 11. 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
    12. 12. Status
‐
Extras• Shell
ImplementaEon
for
InspecEng
Bundles • ps/start/stop
command• Dependency
Manager
for
Dependencies • Simple
ImplementaEon • StaEc
Linked• Open
Source
at
Apache • Currently
in
the
Incubator
    13. 13. 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?
    14. 14. Universal
OSGi
‐
Celix• NaEve
port
in
C• Status • Based
on
the
R4
SpecificaEon • Deployable
bundles • Bundle
lifecycle • Service
registry • Framework
API • Remote
Services • Standards
for
IPC
and
communicaEons
    15. 15. Links• Original
Proposal: • hdp://wiki.apache.org/incubator/CelixProposal• Incubator
Mailing
List
Archive: • hdp://incubator.markmail.org/search/?q=Celix• IncubaEon
Status: • hdp://incubator.apache.org/projects/celix.html• Project
Page: • hdp://incubator.apache.org/celix/

    ×