ECF's implementation of OSGi Remote Services supports the creation of custom distribution providers. Why would anyone wish to do this, when they could simply reuse one of the existing providers? Here are some good reasons:
Service Backward Compatibility: There are cases where it's not a new service being developed, but rather a new facade for an existing (e.g. web) service. With ECF, one can easily create a custom distribution provider that reuses the existing service to expose it as an OSGi service. This allows existing services to continue to be exposed as they were originally written, but also be exposed as an OSGi Remote Service.
Custom Transport Requirements: Remote services also frequently have specific transport requirements...for example using MQTT rather than HTTP, or using JSON rather than XML. With ECF, distribution providers can completely control these transport-level decisions.
Standardization and Interoperability: ECF fully implements both the OSGi Remote Services (RS) and Remote Service Admin (RSA) standards. One thing this means is that all ECF Remote Service providers (both those created by us as well as others) are automatically compliant with the RS/RSA specifications. Also, Remote Service providers can be proprietary/closed source or open source as desired.
We've created this tutorial to show how a custom RESTful (HTTP+JSON) remote service provider can be easily built: Creating a RESTFul Remote Service Provider
Tuesday, December 17, 2013
Monday, December 09, 2013
New tutorial: OSGi Remote Services
ECF team has created a new introductory tutorial on creating standard OSGi Remote Services
Building your first OSGi Remote Service
Our plan is to create a number of such tutorials on OSGi Remote Services and focus on additional topics such as using/configuring alternative discovery or distribution providers, creating REST-based providers, asynchronous remote services and others. They will generally first appear here.
Building your first OSGi Remote Service
Our plan is to create a number of such tutorials on OSGi Remote Services and focus on additional topics such as using/configuring alternative discovery or distribution providers, creating REST-based providers, asynchronous remote services and others. They will generally first appear here.
Sunday, October 27, 2013
Wednesday, October 16, 2013
ECF 3.7
ECF 3.7 was just released.
Highlights/What's New
Thanks and Congratulations are due to ECF committers, contributors, and community
Highlights/What's New
- Servlet API - for Creating OSGi Remote Services with HttpService and Servlets
- OSGi Remote Service Examples
- Testing Against OSGi R5 Compatibility Test Suite - For Remote Services (chapter 100) and Remote Service Admin (chapter 122) in OSGi Enterprise Specification
- Zookeeper Discovery Server
Thanks and Congratulations are due to ECF committers, contributors, and community
Tuesday, October 01, 2013
Evolution of Cooperation
For some time in the Eclipse community, several people have repeatedly discussed the Tragedy of the Commons problem, and it's applicability to Eclipse. In short, as 'platforms', Eclipse and OSGi can be seen as a kind of 'commons' that we all use and benefit from...for creating developer tooling/IDEs, for creating web servers, for creating mobile applications, etc.
The problem being that this 'commons'...if not sufficiently supported and maintained, will degrade over time...and all of us that depend upon, use, and in some cases profit from this commons will suffer from that degradation. Some of us in this community (committers) feel that such degradation has been occurring...and continues to occur. Even though many of us (including me) expend a lot of personal time/effort/expense to continue to support the community.
The question seems to be: how do you get everyone to cooperate in order to maintain the commons? Where 'cooperation' means real cost, and real effort on everyone's part. It seems to me that a big part of the difficulty of doing this is that you have to get not just individuals (committers/people technically capable and knowledgeable enough about Eclipse to actually maintain things), but also both small and large corporations to recognize the need for cooperation and respond to it with more than what I would call lip service ('sure we'll pay for the EF, but we won't pay 8 full-time committers to work on maintaining the platform'). I've pointed out before that small and large groups have different ways of thinking about cooperation...aka collective action...and I further would assert that individuals have a totally different calculation about whether cooperation to maintain a commons even makes sense for them.
In any event, in a previous life I did research work in the psychology of judgment and decision making, and one of my areas of interest was in game theory and the prisoner's dilemma. As part of this work I read a fascinating book called the Evolution of Cooperation by Robert Axelrod. The main message of this work (by my interpretation) is that cooperative behavior..coming from self-interest...can be learned. In my view this work opens up possibilities for solutions to the commons problem...but the hard nut (IMHO) is that group/org learning is an order of magnitude more difficult than individual learning. And of course...individual learning of the self-interested benefits of cooperation is hard/slow enough.
The problem being that this 'commons'...if not sufficiently supported and maintained, will degrade over time...and all of us that depend upon, use, and in some cases profit from this commons will suffer from that degradation. Some of us in this community (committers) feel that such degradation has been occurring...and continues to occur. Even though many of us (including me) expend a lot of personal time/effort/expense to continue to support the community.
The question seems to be: how do you get everyone to cooperate in order to maintain the commons? Where 'cooperation' means real cost, and real effort on everyone's part. It seems to me that a big part of the difficulty of doing this is that you have to get not just individuals (committers/people technically capable and knowledgeable enough about Eclipse to actually maintain things), but also both small and large corporations to recognize the need for cooperation and respond to it with more than what I would call lip service ('sure we'll pay for the EF, but we won't pay 8 full-time committers to work on maintaining the platform'). I've pointed out before that small and large groups have different ways of thinking about cooperation...aka collective action...and I further would assert that individuals have a totally different calculation about whether cooperation to maintain a commons even makes sense for them.
In any event, in a previous life I did research work in the psychology of judgment and decision making, and one of my areas of interest was in game theory and the prisoner's dilemma. As part of this work I read a fascinating book called the Evolution of Cooperation by Robert Axelrod. The main message of this work (by my interpretation) is that cooperative behavior..coming from self-interest...can be learned. In my view this work opens up possibilities for solutions to the commons problem...but the hard nut (IMHO) is that group/org learning is an order of magnitude more difficult than individual learning. And of course...individual learning of the self-interested benefits of cooperation is hard/slow enough.
Thursday, July 25, 2013
Article on OSGi Remote Services in Newsletter
ECF has an article in the Eclipse Newsletter about our support of Remote Services/Remote Service Admin Standards.
Friday, June 28, 2013
ECF Kepler/3.6.1 - Remote Services Takes Center Stage
As part of the Kepler simultaneous release, ECF has just released version 3.6.1. The complete new and noteworthy is here, but the highlights are:
ECF's implementation is the only existing RS/RSA implementation with an open and modular provider-architecture, which enables new discovery and distribution providers to be created...or existing ones extended...by us or others. Any such extended/new providers are/will be automatically be RS/RSA standards compliant.
- Remote Service (RS) and Remote Service Admin (RSA) implementations passing the OSGi Test Compatibility Kit for OSGi R5 Enterprise Specification
- Support for SSL/TLS secure transports in ECF generic provider
- REST remote services provider based upon Restlet 2.2
ECF's implementation is the only existing RS/RSA implementation with an open and modular provider-architecture, which enables new discovery and distribution providers to be created...or existing ones extended...by us or others. Any such extended/new providers are/will be automatically be RS/RSA standards compliant.
Monday, March 25, 2013
ECF 3.6.0
ECF has just released version 3.6.0. Download here.
Highlights since ECF 3.5.0
Congratulations to the ECF committers, contributors, and community!
Highlights since ECF 3.5.0
- ECF 'generic' remote services provider with secure (TLS/SSL) transport
- Restlet-based Remote Services Provider
- Improved implementation of OSGi Remote Services Admin (RSA) specification
Congratulations to the ECF committers, contributors, and community!
Subscribe to:
Posts (Atom)