Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OSGi Remote Services and ECF"

(Introduction)
Line 1: Line 1:
 
==Introduction==
 
==Introduction==
  
ECF's support for OSGi 4.2 Remote Services standard is a layered set of application programming interfaces (APIs).  This modular structure (coming from the use of OSGi and modular design principles) allows service creators to decide (at runtime if necessary) which mechanisms and underlying protocols are appropriate for their remote service, and then use only those mechanisms.
+
As part of the [http://www.osgi.org/Specifications/HomePage OSGi 4.2 compendium specification] is a new service-oriented architecture (SOA) standard for remote services.  This standard uses the OSGi service registry to expose '''remote services'''...i.e. services that are actually implemented in external processes that are distributed on a network.
  
This approach benefits the service creator in two major ways:  1) it reduces the complexity of creating, deploying, managing, and using remote services...by only using the mechanisms that are actually needed; and 2) giving flexibility to meet any needs for integration and interoperabilityIn other words, system complexity is reduced by using only the modules needed for the service, while flexibility is increased.
+
ECF's support for the OSGi standard is implemented as a layered set of application programming interfaces (APIs).  This modular structure allows service creators to use an 'ala carte' model for defining, creating, deploying, integrating, and running services in their distributed application. Such an 'ala carte' model of modularity is helpful to the service builder and consumer for two primary reasons:
 +
 
 +
# It helps reduce system complexity. By only including technologies that are actually necessary for a given use case, rather than include functionality needed to support other use casesFor a lucid presentation about the value of modularity for simplifying complicated systems, see [http://www.martinlippert.org/events/MeetTheExperts-Architektur-2009-ModuleSystemsAndArchitectures.pdf How Module Systems Drive Architectures].
 +
# 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 the various layered APIs in ECF's support of OSGi Remote Services.   
 
Here is a diagram showing the relationship between the various layered APIs in ECF's support of OSGi Remote Services.   
Line 9: Line 12:
 
[[Image:distributedosgi1.png]]
 
[[Image:distributedosgi1.png]]
  
Here are two pages (with source) showing the use of ECF's remote services to expose and access a 'hello world' remote service.   
+
Here are two examples (with source) showing the use of ECF's remote services to expose and access a 'hello world' remote service.   
  
 
#RFC119 - [[Getting Started with ECF's RFC119 Implementation]]
 
#RFC119 - [[Getting Started with ECF's RFC119 Implementation]]

Revision as of 17:12, 21 January 2010

Introduction

As part of the OSGi 4.2 compendium specification is a new service-oriented architecture (SOA) standard for remote services. This standard uses the OSGi service registry to expose remote services...i.e. services that are actually implemented in external processes that are distributed on a network.

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

  1. It helps reduce system complexity. By only including technologies that are actually necessary for a given use case, rather than include 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 the various layered APIs in ECF's support of OSGi Remote Services.

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 DocumentationJavadocProviders
Development
Development GuidelinesIntegrators Guide

Back to the top