Zookeeper Based ECF Discovery

ECF 3.3 contains Apache Zookeeper based Discovery provider. Apache Zookeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by Check the distributed applications. ZooDiscovery is a discovery mechanism that runs as an OSGi service. It leverages Apache ZooKeeper robustness and implements Eclipse ECF Discovery API. For more details on Zookeeper based Service Discovery, please check Eclipse Wiki. ECF 3.3 contains helloworld examples explaining how to use Zookeeper for your distributed application development.

Asynchronous Implementation of OSGi Remote Services.

ECF 3.2 provided the initial implementation of the Remote Services in OSGi 4.2 specification. This specification provides destils for Synchrnous Remote Services but not for Asynchrnous Remote Services. The main issue in the synchronous Remote Services is, in distributed applications the time for method calls over network might have a large performance variability due to unpredictable behaviour of underlying network, etc. So the response time for a Synchronous Remote Service call might take a longer time than expected when the network traffic is high. Therefore the Thread which is responsible of handling the Remote Service call might be blocked for a very long time due to the blocking feature of synchronous systems. In order to avoid these types of problems, we need to use non blocking Asynchronous Remote Services where the result is sent back to the caller using a callback handler. Hence ECF provides the ability to create Asynchronous Remote Services as well. This support is added with the OSGi 4.2 initial implementation. Now there are several examples and documentation guides for the users on Asynchronous Remote Services. Please visit OSGi Remote Services and Sync vs. Async, OSGi Remote Services and ECF - Asynchronous services, Asynchronous Remote Services - part 2 and Asynchronous Remote Services - The future or the callback in the Eclipse Blog for more infomation.

Inclusion of ECF Remote Services in SOA Package

ECF has provided the support for OSGi 4.2 remote services in the ECF 3.2 release. Now ECF has created a new feature, org.eclipse.ecf.remoteservice.sdk.feature. This feature is a part of the org.eclipse.ecf.core and it feature includes around 10 other features that break up the ECF remoteservice implementation logically (i.e. discovery api, remote service api, osgi 4.2 implementation, various providers for apis, etc). This new feature is now hosted at the Helios contribution repository for ECF. The repository location is http://download.eclipse.org/rt/ecf/3.3/helios/site.p2. Eclipse community had strongly supported the idea of including ECF OSGi 4.2 Remote Services in the SOA-IWG package. So with the consent of the SOA committers, ECF Remote Services feature ( org.eclipse.ecf.remoteservice.sdk.feature) is now a part of the SOA-IWG package and ECF Remote Services are distributed with SOA package as well.

Remote Services Examples and Documentations

ECF 3.3 release contains a new set of examples and documetation guides for Remote Services. Getting Started with ECF's OSGi Remote Services Implementation, Asynchronous Proxies for Remote Services,Using Spring with ECF Remote Services, Load Balancing Remote Services are some of the new additions to the ECF. Please visit ECF Wiki for moer information.

Hudson Continuous Server for ECF

ECF now mainstains a Hudson Continuous Integration Server which is running at Origon State University Open Source Lab (OSUOSL). ECF Hudson CI Server runs an instance of Eclipse Buckminster to build the Eclipse Plugins and Eclipse Buckminster Project is developed with the aim of providing Component Assembly for Eclipse. Buckminster is a component resolution & materialization framework. Hudson CI server is one of the widely used CI server in the software industry today. Hudson Server runs in a servlet container and supports SCM tools such as CVS, Subversion, Git and Clearcase. Not only these SCM integrations but also it supports Apache Ant and Apache Maven project executions. Hudson is capable of executing the Windows Batch scripts and Shell scripts as well. It provides users to build system automatically without human intervention upon set of triggers such as SCM commits using post commit hooks, time based triggers such as nightly builds. Currently several ECF committers working on ECF Hudson Server. The location of the ECF Hudson Server is https://ecf2.osuosl.org/hudson/ and you can access this server to download latest build artifacts of ECF.

OSGi 4.2 remote
services standard

ECF 3.2 has support for the OSGi 4.2 remote services specification which is specified in chapter 13 in compendium section. This is the initial mplementation of this specification. The notable features of this ECF's implementation are Transport Independence, Lightweight, Standard Open Source Open Team Open Process, Extensibility and etc. See ECF Blog, ECF Wiki on OSGi 4.2 and ECF and ECF Wiki on Getting started with OSGi Remote Services for more details about this.

SOAP and REST APIs for Remote services

ECF 3.2 is consists of SOAP based provider support for remote services. REST based remote service support was added to the ECF 3.1 release and ECF 3.2 now have OSGi 4.2 remote services implementation along with SOAP based remote services support. SOAP is not a protocol but it is a rpc style and it works as a serialization format as well. Hence ECF's does not have a single SOAP provider. Instead of a single implementation of a SOAP provider ECF 3.2 has included some utility and implementation classes for creating SOAP based providers. See ECF Wiki and ECF blog for more details.

REST API support for Remote Services was initially added to the ECF 3.1 release and See ECF Wiki and ECF Blog for more details about the ECF REST support for Remote services.

Load Balancing for Remote Services

ECF remote services API allows arbitrary services to be exposed for remote access and invocation. Some of these services are long running and/or computationally intensive. So it is a good practice to use multiple servers to execute these services. Dynamic load balanacing among these servers helps to prevent servers being overloaded. ECF now has dynamic load balancing example that uses a JMS Queue via ECF ActiveMQ provider implementation of JMS to do dynamic load balancing for ECF remote service method/request invocations. See ECF Wiki for more details.

Remote Services Examples

Remote services API is an major API in the ECF and it has been there for a quite long time. Though the API was there, number of exmaples existed in the ECF was very few. So in this ECF 3.2 release a set of examples for ECF remote services being included. These examples give a thorough knowledge on using ECF Remote Rervices API. See ECF Wiki for more.

Google Wave Provider

Google's wave protocol is an emerging server-to-server protocol for real-time updates and replicated state synchronization. The protocol is being specified and developed in the open at www.waveprotocol.org. Using the following 3 ECF characteristics

1) ECF's provider architecture
2) the ECF sync API for implementing operational transformation and
3) Our existing XMPP provider

it is straightforward to implement a Wave provider in ECF, allowing Equinox-based runtimes to both host Waves/wavelets, and participate in waves/wavelets hosted by google and by other implementers.

Currently the implementation is not completed and it is under construction. See ECF Bug request for more details.

Representational State Transfer (REST) API

ECF 3.1 has support for creating REST-based remote services. ECF's existing remote services API has been extended to specifically support the access of REST-based services (such as the Twitter API). See ECF REST API wiki page for more details and examples.

Distributed EventAdmin

OSGi 4.1 defines an EventAdmin service for delivering events asynchronously or synchronously to an arbitrary set of listeners. ECF has created a distributed version of the EventAdmin service, which uses publish and subscribe to deliver Events to remote listeners. The This implementation uses the abstract ECF shared object API, which abstracts publish/subscribe communication above the transport, so that that the use the Distributed EventAdmin service may be bound at runtime to a selected message bus. For example, ActiveMQ/JMS may be used as the message bus, or ECF generic groups, or JavaGroups/reliable multicast, or other transports. See the Distributed EventAdmin wiki page for documentation and examples.

Salvo, the Eclipse Newsreader

Committer work is underway on a NNTP Newsreader client (called Salvo) together with an ECF Container implementing the NNTP protocol. For details of this work, and to participate, see here.

Here is a screen shot from a recent version of the Salvo work

TweetHub

Community-initiated work is underway on a Twitter client (called TweetHub) that uses ECF APIs, as well as Eclipse RCP user interface technologies. For details of this work, and to participate, see here.

Here is a screen shot from a recent version of the TweetHub work

File-based Discovery

As part of the ECF RFC119/Distributed OSGi implementation in ECF 3.0/Galileo, two discovery providers were previously released: one based upon jSLP (Service Location Protocol aka RFC 2608) and the other based upon Apple's Bonjour/zeroconf protocol. File-based discovery provides a way to publish and discover remote service endpoints without using a network protocol at all (or in addition to a network protocol), but rather using an XML file that describes the endpoints of the remote services available. See the File-based Discovery wiki page for documentation and examples.