Difference between revisions of "OSGi Remote Services and ECF"

From Eclipsepedia

Jump to: navigation, search
(Introduction)
(Introduction)
Line 1: Line 1:
 
==Introduction==
 
==Introduction==
  
Chapter 13 in the [http://www.osgi.org/Specifications/HomePage OSGi 4.2 compendium specification] describes a new service-oriented architecture (SOA) standard.  This standard uses the OSGi service registry to expose '''remote services'''...i.e. OSGi services that are actually implemented in processes distributed on a network.
+
Chapter 13 in the [http://www.osgi.org/Specifications/HomePage OSGi 4.2 compendium specification] describes a new service-oriented architecture (SOA) standard.  This standard uses the OSGi service registry to expose '''remote services'''...i.e. OSGi services that are distributed on a network.
  
 
ECF's support for this standard is implemented as a layered set of application programming interfaces (APIs).  This layered and modular structure allows service builders and service consumers to use an 'ala carte' model for defining, creating, deploying, integrating, and running distributed services.  Such an 'ala carte' model of modularity is helpful for two primary reasons:
 
ECF's support for this standard is implemented as a layered set of application programming interfaces (APIs).  This layered and modular structure allows service builders and service consumers to use an 'ala carte' model for defining, creating, deploying, integrating, and running distributed services.  Such an 'ala carte' model of modularity is helpful for two primary reasons:

Revision as of 19:02, 26 January 2010

Introduction

Chapter 13 in the OSGi 4.2 compendium specification describes a new service-oriented architecture (SOA) standard. This standard uses the OSGi service registry to expose remote services...i.e. OSGi services that are distributed on a network.

ECF's support for this standard is implemented as a layered set of application programming interfaces (APIs). This layered and modular structure allows service builders and service consumers to use an 'ala carte' model for defining, creating, deploying, integrating, and running distributed services. Such an 'ala carte' model of modularity is helpful for two primary reasons:

  1. It helps reduce overall system complexity. By only including technologies that are actually necessary, rather than including/requiring functionality needed to support other use cases. For a lucid presentation about the value of modularity for simplifying complicated systems, see How Module Systems Drive Architectures.
  2. It provides flexibility. This flexibility allows consumers to mix-and-match transport protocols and serialization formats, supports interoperability, and easy integration with existing systems, and supports use of synchronous and/or asynchronous invocation patterns as needed.

Here is a diagram showing the relationship between these APIs.

Distributedosgi1.png

Here are two examples (with source) showing the use of ECF's remote services to expose and access a 'hello world' remote service.

  1. RFC119 - Getting Started with ECF's RFC119 Implementation
  2. Remote Services API - Getting Started with Using the ECF Remote Services API

Related Documentation

ECF API Docs

API Javadocs

Getting Started with ECF's RFC119 Implementation

Getting Started with Using the ECF Remote Services API

Distributed EventAdmin Service

Eclipse Communication Framework
API
API DocumentationJavadocProvidersECF/Bot Framework
Components
ServersShared EditingShared Code Plug-in
Development
Development GuidelinesIntegrators Guide