Jump to: navigation, search

Difference between revisions of "OSGi Remote Services and ECF"

 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Introduction==
 
==Introduction==
  
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.
+
Chapter 100 in the OSGi Enterprise specification provides a new standard for service-oriented architecture (SOA).  This standard uses the well-established OSGi '''service registry''' to expose '''remote services'''...i.e. OSGi services that are distributed on a network rather than only available to the single OSGi process.
  
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:
+
ECF's support for this standard is implemented as a layered set of application programming interfaces (APIs).  The 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 is helpful for implementing distributed applications 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 cases.  For 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 '''reduces''' overall '''system complexity'''.  Networked/distributed applications frequently can quickly become very complicated.  By only including modules that are actually necessary, rather than including/requiring functionality needed to support other use cases for distributed services, overall system complexity is reduced.  For 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.
+
# It provides '''flexibility'''Networked applications frequently require a good deal of flexibility...i.e. the flexibility to replace one transport with another, one security model for another, one deployment and management approach with another, synchronous RPC with asynchronous messaging.  The flexibility of using OSGi modularity and ECF allows service developers and consumers to mix-and-match transport protocols and serialization formats, supports interoperability and 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. 
+
  
 
[[Image:distributedosgi1.png]]
 
[[Image:distributedosgi1.png]]
Line 14: Line 12:
 
Here are two examples (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]]
+
#[[Getting Started with ECF's OSGi Remote Services Implementation]]
#Remote Services API - [[Getting Started with Using the ECF Remote Services API]]
+
  
 
==Related Documentation==
 
==Related Documentation==

Latest revision as of 17:13, 14 October 2013

Introduction

Chapter 100 in the OSGi Enterprise specification provides a new standard for service-oriented architecture (SOA). This standard uses the well-established OSGi service registry to expose remote services...i.e. OSGi services that are distributed on a network rather than only available to the single OSGi process.

ECF's support for this standard is implemented as a layered set of application programming interfaces (APIs). The 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 is helpful for implementing distributed applications for two primary reasons:

  1. It reduces overall system complexity. Networked/distributed applications frequently can quickly become very complicated. By only including modules that are actually necessary, rather than including/requiring functionality needed to support other use cases for distributed services, overall system complexity is reduced. For a lucid presentation about the value of modularity for simplifying complicated systems, see How Module Systems Drive Architectures.
  2. It provides flexibility. Networked applications frequently require a good deal of flexibility...i.e. the flexibility to replace one transport with another, one security model for another, one deployment and management approach with another, synchronous RPC with asynchronous messaging. The flexibility of using OSGi modularity and ECF allows service developers and consumers to mix-and-match transport protocols and serialization formats, supports interoperability and integration with existing systems, and supports use of synchronous and/or asynchronous invocation patterns as needed.

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. Getting Started with ECF's OSGi Remote Services Implementation

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