Celix, Universal OSGi?
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Celix, Universal OSGi?

  • 1,858 views
Uploaded 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.

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,858
On Slideshare
1,715
From Embeds
143
Number of Embeds
5

Actions

Shares
Downloads
44
Comments
0
Likes
0

Embeds 143

http://www.eclipsecon.org 116
http://lanyrd.com 13
http://eclipsecon.org 8
http://paper.li 5
https://www.eclipsecon.org 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

  • 1. CelixUniversal
OSGi? Alexander
Broekhuis
 alexander.broekhuis@luminis.eu
  • 2. Agenda• Celix• Services
in
C• Dynamic
Assembly• Remote
Services• Deployment• Celix
Status• Universal
OSGi• Demo
  • 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. 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. 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. 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. Remote
Services• Remote
Service
Admin • Enterprise
SpecificaEon• Interoperability• Protocol • Tuscany? • ZeroMQ? • Google
Protobufs?
  • 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. 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. 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. 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. 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. 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. 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. 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/