incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: [PROPOSAL] Celix to enter the Incubator
Date Mon, 27 Sep 2010 15:15:18 GMT
Hi Sanjiva,

Sorry for the confusion, the CXF project is named as dependency to test the
remote services in combination with other java based OSGi implementations.
The C part should be in C, and Axis2/C seems a good candidate. But at the
moment we are also looking at other, lighter, protocols to use.

For example hessian [1] (not available in C), or protocol buffers (from
google). Both have limitations, as said, hessian is not available in C. And
while the protobuf project itself does not provide a C implementation, there
is a separate project [3].
Using any other protocol would also imply that it has to be implemented in
Java to be able to test interoperability. This is where the protobuf project
has a limitation. Remote services should be usable for any given interface
at runtime. In Java this is solved using reflection, and for example, the
Apache CXF JAX-WS implementation. Protobuf has a java implementation, but no
runtime support. It relies on .proto files to define and generate the
messages and services.

I hope this makes things a little clearer, and if someone has other
ideas/possibilities, I am really interested in them.

[1] http://hessian.caucho.com/
[2] http://code.google.com/p/protobuf/
[3] http://code.google.com/p/protobuf-c/

On Mon, Sep 27, 2010 at 4:51 PM, Sanjiva Weerawarana
<sanjiva@opensource.lk>wrote:

> Alexander, I'm confused about the remote API aspect- since Celix is in C
> why
> would you implement the remote API in Java with CXF? Why wouldn't you use
> Axis2/C?
>
> Sanjiva.
>
> On Fri, Sep 24, 2010 at 8:15 PM, Alexander Broekhuis
> <a.broekhuis@gmail.com>wrote:
>
> > Hello,
> >
> > I would like to announce  the following proposal as a new incubator
> > project.
> > Abstract
> >
> > Celix is a OSGi like implementation in C with a distinct focus on
> > interoperability between Java-OSGi and Celix.
> > Proposal
> >
> > Celix will be an implementation of the OSGi specification adapted to C.
> It
> > will follow the API as close as possible, but since the OSGi
> specification
> > is written primarily for Java, there will be differences (Java is OO, C
> is
> > procedural).
> > An important aspect of the implementation is interoperability between
> > Java-OSGi and Celix. This interoperability is achieved by porting and
> > implementing the Remote Services specification in Celix. These Services
> > will
> > be made available in separate bundles.
> > Background
> >
> > In embedded/realtime situations software is mostly implemented in C. In
> > situations where interoperability and dynamics are important, a good
> > architecture and design principle is needed. OSGi provides such
> middleware
> > for Java based systems.
> > To be able to have such dynamic environment implemented in C, a OSGi like
> > implementation is needed. Besides a dynamic environment, OSGi also makes
> it
> > easier to reuse parts of the system, reducing time needed to implement
> and
> > maintain software.
> > The implementation started with the basics to make it possible to load
> > libraries dynamically, and steadily grown towards an implementation where
> > large parts of the OSGi framework API is implemented.
> > The implementation of Celix is heavily based on Apache Felix (where
> > appropriate it is even a direct port of the Apache Felix code (Java) to
> C).
> > Since distributed systems are used more and more in services based
> > environments, a scalable and transparent solution is needed for remote
> > communication. The OSGi specification describes remote services, this
> > specification will be a part of the first release.
> > Remote services also make it possible to communicate between Java-OSGi
> and
> > Celix. To achieve this interoperability, both Java and C implementations
> of
> > remote services for a common protocol are needed. For local services JNI
> > can
> > be used, for remote services SOAP and/or REST can be used. In the latter
> > case, Apache CXF can be used to implement the Remote Services API in
> Java.
> > Rationale
> >
> > In embedded/realtime/distributed environments there is a need to be able
> to
> > create dynamic and maintainable software. Currently there are no off the
> > shelf middleware/frameworks for this. Celix tries to provide such a
> > framework.
> > The choice to base the implementation on the OSGi specification makes it
> > possible for a developer to use Celix as well as Java OSGi implementation
> > without much differences and without a steep learning curve.
> > The community and user driven platform created by Apache provides a great
> > base for middleware such as Celix. Also the fact that Celix is based on
> > Apache Felix, and Apache Felix is hosted by Apache, makes it a logical
> > choice to have Apache as home for this project.
> > Initial Goals
> >
> >   - Provide a basic implementation of the OSGi Framework API
> >   - Provide an implementation of Remote Services to be able to create
> >   distributed systems (and Celix <-> OSGi interoperability).
> >   - Build/Expand a community using/developing Celix
> >   - OSGi like implementation in C
> >   - Provide a module/component based software solution for embedded
> >   Platforms
> >      - RealTime software
> >      - Distributed systems
> >      - Provide Services based solution
> >   - Investigate if Apache Portable Runtime can be used for platform
> >   abstraction
> >
> > Current Status Meritocracy
> >
> > Celix was created by Alexander Broekhuis. While he is no active
> > committer/participant of Apache projects, he has used Open Source and is
> > well known with it and how a meritocracy works. Currently there are
> several
> > other possible committers.
> > To be able to create and maintain complex middleware (such as Celix) a
> good
> > structure is needed. A meritocracy following the rules and traditions of
> > the
> > ASF is a good choice for Celix.
> > Community
> >
> > Currently the Celix community exists out of the core developers, and the
> > users integration Celix in an end-user product (all from Thales).
> > Core Developers
> >
> >   - Alexander Broekhuis (Luminis)
> >   - Jasper Gielen (Humiq)
> >   - Herman ten Brugge (Thales)
> >
> > Alignment
> >
> > Celix is heavily based on Apache Felix. Since Apache Felix is an Apache
> > project it makes sense to develop Celix under Apache.
> > Also, Celix is a complex and large middleware project, it makes sense to
> > have a supporting/developing community. Apache provides a solid base,
> with
> > established processes and rules, to create such community.
> > Known Risks Orphaned Products
> >
> > Celix will be used by Thales, and so there is no direct risk for this
> > project to be orphaned.
> > Inexperience with Open Source
> >
> > The committers have experience using and/or working on open source
> > projects.
> > The Apache process is new, but most likely not a problem.
> > Homogeneous Developers
> >
> > Currently all committers are from the Netherlands, but they do work for
> > different organizations.
> > Reliance on Salaried Developers
> >
> > All committers working on Celix (currently) are paid developers. The
> > expectation is that those developers will also start working on the
> project
> > in their spare time.
> > Relationships with Other Apache Products
> >
> >   - Celix is based on Apache Felix
> >   - Using Apache ACE it probably is possible to provision Celix bundles
> >   - For remote services Apache CXF can be used (either SOAP or REST)
> >   - Possibly Apache ZooKeeper can be used for remote service discovery
> >   (Apache ZooKeeper vs SLP)
> >   - Possibly Apache Portable Runtime for platform abstraction
> >
> > An Excessive Fascination with the Apache Brand
> >
> > Celix itself will hopefully have benefits from Apache, in terms of
> > attracting a community and establishing a solid group of developers, but
> > also the relation with Apache Felix. These are the main reasons for us to
> > send this proposal.
> > We think that a good community is needed to build and maintain large
> > middleware projects, such as Celix.
> > However, even if Celix would not be accepted, development will continue.
> As
> > such, there is no need to, or reason to, "abuse" the Apache Brand.
> > Documentation
> >
> > Currently all documentation and information is stored on a private
> > corporate
> > wiki.. This has to be moved to a public place. (is this part of the
> process
> > after acceptance, or should this be placed on (eg) the luminis open
> source
> > server?)
> > Initial Source
> >
> > Development of Celix started in the summer of 2010. The source currently
> is
> > located on a private corporate SVN repository.
> > All the source is available for Open Sourcing and can be found at
> > http://opensource.luminis.net/wiki/display/SITE/Celix
> > Source and Intellectual Property Submission Plan
> >
> > Celix is currently developed solely by Luminis employees. All source will
> > be
> > donated to Apache.
> > External Dependencies
> >
> >   - MiniZip source , zlib license
> >
> > This source can be included, according to
> > http://www.apache.org/legal/3party.html
> > Required Resources Mailing Lists
> >
> >   - cosgi-dev
> >   - cosgi-private
> >
> > Subversion Directory
> >
> > https://svn.apache.org/repos/asf/incubator/celix<
> > http://svn.apache.org/repos/asf/incubator/cosgi>
> > Issue Tracking
> >
> > JIRA Celix
> > Other Resources
> >
> >   - CMake
> >
> > Celix uses Cmake as build environment. CMake generates Make files for
> > building, bundling and deploying Celix.
> > This build environment can also be used by project using Celix, it
> provides
> > simple methods for creating and deploying bundles to a named target.
> >
> >   - Confluence Wiki
> >
> > To be able to provide help, documentation, faq etc, a wiki is needed.
> > Initial Committers
> >
> > Alexander Broekhuis a.broekhuis@gmail.com
> > Sponsors Champion
> >
> > Marcel Offermans
> > Nominated Mentors Sponsoring Entity
> >
> > Celix is a new project and proposed is to release to code under the
> > sponsorship of the Incubator.
> >
> > --
> > Met vriendelijke groet,
> >
> > Alexander Broekhuis
> >
>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2; http://wso2.com/
> Founder & Director; Thinkcube Systems; http://www.thinkcube.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Member; Sahana Software Foundation; http://www.sahanafoundation.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>



-- 
Met vriendelijke groet,

Alexander Broekhuis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message