For those interested, there’s a new Distributed OSGi EventAdmin Service remote services example now available.

What does this mean? Well, you can now create distributed implementations of OSGi services using JMS or other messaging frameworks for distributing messages to other OSGi frameworks. This is all possible because of ECF’s provider architecture that allows the creation of a distributed EventAdmin implementation that can use a variety of wire protocols (e.g., XMPP, ActiveMQ).

Please let email the ecf-dev list if you have any questions!

Tags: ecf, equinox, OSGi, rfc119

As part of our next release cycle, the Eclipse Communications Framework (ECF) project is going to implement the Google Wave Protocol as described in this enhancement request.  Please join the request if you are willing to contribute to this effort, or would like to use the implementation.

This will make it easy for Eclipse and any Equinox, RCP or RAP-based application to interoperate with other Google Wave applications.

Tags: ecf, equinox, google, OSGi, wave

Once upon a time a guy named Roy Fielding made his disertation about a design aproach called REST. From this point REST is getting very popular. Many service provider using REST to offer developers access to their services i.e. Twitter, Facebook and so on.

But what is this REST thing? It’s a way to publish web services without any overloaded technology like SOAP for example. Every REST service is available under a unique URL and can accessed by everybody. Mostly it sends a response using XML but this is different from service to service. To get the idea of REST let’s take a look at an example. There is a realy huge REST example out there. Probably you using it every day – it’s called the World Wide Web

Yes, the web is nothing else as an landscape full of REST web services. Mostly the services response are HTML but as I said before the response can vary from service to service.

The special thing about REST is that it uses a very well known technology called HTTP. Fielding was involved in the design of HTTP1.1. So REST is nothing else as a way to use HTTP the right way. The HTTP methods (GET, PUT, DELETE, UPDATE) are used for the interaction. The benefit for us developers is, that we can use any programming language to access such a REST service.

And why does ECF want to kiss REST? As I said before, many providers already provide RESTful interfaces. So if ECF has a common API to access a REST based web service it would be much easier to implement providers for these services. On this point GSoC enters the field.

There is a GSoC project called “REST abstraction for ECF” which is my project for this year. You can read more about this project in my proposal and edit or update ideas. Please feel free to get involved.

The overall goal for this project is to make the Eclipse IDE more social. Sounds terrifying isn’t it? But imagine, you open your workspace and activate a mylyn task which is probably a bug. On the same time the bug id and your name is tweeted on Twitter. So everybody who’s interested in your project can see that you working on a new feature or bug. I think this would be really awesome to improve collaboration. There are many other use cases, if you have any ideas please feel free to add comments. Maybe we can realize it if the project has finished. There is only one hurdle left.

The project has to be nominated. So if you are a mentor for GSoC2009, please vote for this project and on the same time for me. Every vote counts

Thank you all for your interest.

Tags: ecf, eclipse, soc

We are all busy preparing our talks and demonstrations for EclipseCon, aren’t we? This year I am trying to use in all of my talks a common set of examples.

The plan is to showcase technology from several projects. I will start with the EPP Download Wizard (at the moment ‘Friends-of-Eclipse’ only) from my EPP project that has been build as a RAP application and uses Equinox, p2, and the p2 installer. With the EPP Download Wizard, a user is able to pick and choose from a set of available installable units. On the last wizard page, he or she can download a small customized p2 installer that will download the selected pieces from the p2 repositories. There will be various talks about the things that we do in EPP, e.g. the talk of my colleagues about the internals of the EPP Wizard, or my other talk about the EPP Usage Data Collector.

But what if a developer who is developing this wizard or another application wants to deploy it on a server? The first problem: You need a server! The answer to this question is easy: Use g-Eclipse, our Grid and Cloud Computing tooling, and start your own server on the cloud. This can be done within minutes and we are going to show this in our Equinox above the Cloud talk.

Now that you have your own server up and running, all you need to do is deploying your application on it. But how is this done… well, attend our talk and you will find out how easy it is with p2!

Tags: aws, cloud computing, ec2, ecf, eclipsecon, epp, g-Eclipse, OSGi, p2, rap

I’ve blogged previously about what we (ECF) are doing WRT to RFC 119 (Distributed OSGi Services):  RFC 119 and ECF – part 2

The news for today…I’m rather excited to report…is that we now have a working implementation of RFC 119, with support for both discovery and distribution parts of the specification.  This will be part of the ECF 3.0/Galileo release, and of course we will be talking about it in Markus’ and my tutorial, as well as some other talks.

What’s So Cool About Yet Another Spec Implementation?

In my view, what makes this implementation interesting and useful is that we’ve used the abstract ECF discovery and remote services APIs to implement this spec, meaning that without doing any other work, RFC compliant distributed OSGi services are supported using the following transports

Distribution

• r-OSGi (http)
• XMPP
• ECF Generic
• Skype
• Java Messaging Service (JMS)
• JavaGroups

Discovery

• Service Location Protocol (RFC 2608)
• Bonjour/Zeroconf/DNS-SD

And, of course any other transports that people are willing to create, as the ECF remote services API is completely open.

Our desire/hope is that others will implement ECF providers built from other protocols/transports of their choosing (both commercial and open source)…with the payoff to them being that they will then automagically have a RFC 119-compliant implementation…since all ECF providers are now RFC 119 compliant (and will remain so, as we will update the impl as the spec changes).  All the existing implementations done by the ECF team (e.g. r-OSGi, ECF generic, etc) are open source and so may be used/reused to create new providers as desired.

Another thing that I think is cool is that even though RFC 119 specifies using transparent proxies for accessing remote OSGi services, it allows (and even encourages) implementations to support non-transparent/asynchronous remoting (i.e. using one-ways, asynchronous rpc, and futures).  ECF’s remote services API already has support for futures, and asynchronous/non-blocking remote invocation via its IRemoteService interface.

With our current impl of RFC 119, clients can access the IRemoteService instance (in addition to or instead of the proxy), via a standard service property on the ServiceReference.  This gives clients a runtime choice of whether to access a remoted service via a proxy…or via asynchronous/non-blocking techniques like futures and one-ways.

One final thing…the size cost for the ECF remote services API is fairly small (<60k of code) next to the size of the implementations…making it possible to use in smaller (as well as larger) execution environments.

Tags: api, discovery, distribution, ecf, equinox, rfc119

Some time ago, I blogged about RFC 119 and ECF part 1, so now it’s time for part 2…

ECF now has a set of plugins that serve as a bridge between the RFC 119 spec (see part 1) and ECF’s discovery and remote services API (note:  all the following plugins begin with ‘org.eclipse.ecf’ and can be found in /cvsroot/rt/org.eclipse.ecf/framework/bundles at dev.eclipse.org):

1. osgi.services
2. osgi.services.discovery
3. osgi.services.distribution

The osgi.service bundle only contains the classes that are included in the OSGi 4.2 compendium, i.e. interfaces such as DiscoveryProvider, DiscoveredServiceTracker, and DistributionProvider.  These interfaces are defined by the OSGi Enterprise Experts group, and are part of the RFC 119 specification.  The implementation is from the OSGi Alliance, as are other parts of OSGi that are implemented in Equinox.

RFC 119 is divided into two parts:  1) service discovery; 2) service distribution.  Service discovery is optional, and service distribution is required.

The osgi.services.discovery bundle implements the RFC 119 discovery and uses ECF’s discovery API to implement protocol independent network service discovery.   There are two existing provider implementations of the ECF discovery API right now:  zeroconf/bonjour and SLP…so users will be able to publish their services automatically over both SLP and zeroconf discovery mechanisms with a single service publication.

Similarly the osgi.services.distribution bundle implements RFC 119 distribution using ECF’s remote services API.   When this is complete, it will mean that without any additional coding, remote services will run immediately on the following transports:

1. r-OSGi/http
2. TCP/ECF generic
3. XMPP/XMPPS
4. Skype
5. JMS – ActiveMQ, Weblogic JMS
6. Others under active development:  EMF/CDO, http-with-rest

Further,  the ECF remote services API also allows non-transparent access to remote services, in order to support asynchronous remote method invocation, one-ways, futures, explicit failure handling, and other features not part of RFC 119 at this point.

Note also that other providers that implement the ECF remote services API will automatically be RFC 119 compliant…i.e. they have to do no work to be compliant with RFC 119 for transparent remote procedure call.  Further, with ECF remote services, if clients wish to use non-transparent remoting…in combination with or in exclusion to transparent remoting…that is also available.

We’re closing in as rapidly as we can on having this all ready and working…and EclipseCon 2009 is coming up fast…so stay tuned.

Tags: discovery, distribution, ecf, OSGi, rfc119

There seems to be a lot of interest in doing distributed services with OSGi/Equinox, and so I wanted to begin a series of postings about what the ECF project is doing in this area (short story: a lot), and what we are planning for supporting standardization via RFC 119.

What is RFC 119?

First, here is the OSGi 4.2 early draft, which includes a draft of RFC 119 (toward end of PDF).  RFC 119 is an effort to standardize some aspects of creating, publishing, discovering, and accessing out-of-process OSGi services.  It is not yet complete, but is quickly moving toward standardization.

What is ECF Doing with Discovery and Remote OSGi Services?

For some time, ECF has had both a discovery API, and a remote services API.

These APIs have two interesting characteristics (relevant to this post, anyway):

1. They are transport independent
2. They expose both transparent and non-transparent remote method access

Why is Transport Independence Useful?

Transport independence means that multiple implementations can and do exist, for both the discovery and remote services APIs.  So, for example, for discovery ECF currently has two implementation…also known as ‘providers’:  the Service Locator Protocol (RFC 2608), and Zeroconf/Bonjour.

Transport independence also exists for the remote services API, and we already have implementations based upon r-OSGi, XMPP, a simple tcp-based protocol, and JMS.

In general, transport independence is helpful because provider implementations can be replaced/changed without affecting clients (i.e. code that uses remote services).

Among other things, this is important for interoperability and cross-vendor openness, as it allows multiple servers/services to be used without rewriting the clients of those services.

Exposing both transparent and non-transparent remote method access

There is a long (and sometimes bitter) dialog in the distributed systems literature about whether transparency in networked services is a ‘good idea’.   ECF has attempted to skirt this entire large and complicated philosophical issue by providing both transparent access to remote services (i.e. through the normal OSGi services registry), and non-transparent access (via IRemoteService interface…see javadocs here) and leaving the decision about which is appropriate to the service creator and service client.

For non-transparent access to remote service, ECF provides the IRemoteService interface.  It exposes methods to remotely invoke methods via non-blocking techniques (e.g. with listeners for receiving callbacks or with a ‘future’).  This gives clients the flexibility and the tools to use transparent invocation (via proxy) if desired/appropriate, or use the asynchronous, non-blocking mechanisms present on IRemoteService.

What about ECF and RFC 119?

The short story is that we have plans to implement RFC 119 with the ECF discovery and remote services APIs.  Specifically, see bug 249240.   Given the existing drafts of RFC 119, we believe that we can implement it by writing code above the ECF discovery and remote services APIs, without significant changes to the APIs themselves.   This would mean that all ECF providers would then implement RFC 119, without having to do any additional work.

More on this and other issues in subsequent posts.

Tags: api, ecf, OSGi