Downloaded 55 times
More Related Content
![[WSO2] Deployment Synchronizer for Deployment Artifact Synchronization Betwee...](https://cdn.slidesharecdn.com/ss_thumbnails/wso2depsyncforartifactsynchronizationofclusternodes-121031005746-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[A3]deview 2012 network binder](https://cdn.slidesharecdn.com/ss_thumbnails/a3deview2012networkbinder-120919013240-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Celix, Universal OSGi?
- 1. Celix Universal 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/
Editor's Notes
- #2 \n \n
- #3 - 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
- #4 Assuming OSGi is know by most people, only a short overview.\n\n \n
- #5 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
- #6 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
- #7 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
- #8 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
- #9 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
- #10 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&#x2019;t be exposed using an interface\n-- Use a struct with function pointers to solve this, more details on next slide\n
- #11 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
- #12 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 &#x201C;depends&#x201D;\n- The framework needs to &#x201C;initialize&#x201D; 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
- #13 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
- #14 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
- #15 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
- #16 Status of Celix\n
- #17 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
- #18 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
- #19 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
- #20 \n \n