Jump to: navigation, search

Difference between revisions of "OSGi Remote Services and ECF"

(Introduction)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Introduction==
+
The OSGi Alliance provides a new standard for distributed service-oriented architecture called Remote Services.  Remote Services extends functionality of the OSGi '''service registry''' to export arbitrary services for out-of-process access.
  
Chapter 13 in the [http://www.osgi.org/Specifications/HomePage OSGi 4.2 compendium] specifies 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.
+
ECF's support is implemented as a layered set of open, stable, documented, community-created and reviewed APIs.  This layered modular structure allows service implementers and service consumers to easily but flexibly declare, implement, test, deploy, and manage their distributed services. Such an model is helpful for implementing distributed applications for two at least 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 '''reduces''' overall '''sytstem and application complexity''' by promoting loose coupling and high cohesion via OSGi ServicesDistributed applications can easily become complicated and difficult to manage, version, and maintainThe use of OSGi Remote Services to create a formal separation between contract/service type and implementation makes system complexity much easier to understand and manage.
 
+
# It provides '''flexibility''' and '''extensibility'''.  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.
# 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 reducedFor 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].
+
# '''Eliminate''' vendor transport lockin.  ECF's open implementation of OSGi Remote Services is the only transport independent implementation, allowing custom distribution and discovery providers to replace existing implementations.  Such custom providers may be FOSS or not; the decision is up to the custom provider implementer.
# 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.
+
  
 +
[[ECF#Introductory_Materials|Here are several tutorials]] showing how ECF Remote Services can be used on several OSGi frameworks.
 
[[Image:distributedosgi1.png]]
 
[[Image: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. 
+
==Under Construction==
 
+
#[[Getting Started with ECF's OSGi Remote Services Implementation]]
+
  
 
==Related Documentation==
 
==Related Documentation==
 +
 +
[[Getting Started with ECF's OSGi Remote Services Implementation]]
 +
 +
[[Tutorial: Building your first Asynchronous OSGi Remote Service]]
 +
 +
[[ECF/Asynchronous_Remote_Services|Asynchronous Remote Services]]
 +
 +
[[ECF#Introductory_Materials|ECF Remote Services Tutorials]]
  
 
[[ECF API Docs]]
 
[[ECF API Docs]]
  
 
[http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/ API Javadocs]
 
[http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/ API Javadocs]
 
[[Getting Started with ECF's RFC119 Implementation]]
 
  
 
[[Getting Started with Using the ECF Remote Services API]]
 
[[Getting Started with Using the ECF Remote Services API]]
  
 
[[Distributed EventAdmin Service]]
 
[[Distributed EventAdmin Service]]
 
{{ECF}}
 
[[Category:Eclipse Communication Framework]]
 
[[Category:EclipseRT]]
 
[[Category:Draft Documentation]]
 

Latest revision as of 13:22, 26 November 2014

The OSGi Alliance provides a new standard for distributed service-oriented architecture called Remote Services. Remote Services extends functionality of the OSGi service registry to export arbitrary services for out-of-process access.

ECF's support is implemented as a layered set of open, stable, documented, community-created and reviewed APIs. This layered modular structure allows service implementers and service consumers to easily but flexibly declare, implement, test, deploy, and manage their distributed services. Such an model is helpful for implementing distributed applications for two at least reasons:

  1. It reduces overall sytstem and application complexity by promoting loose coupling and high cohesion via OSGi Services. Distributed applications can easily become complicated and difficult to manage, version, and maintain. The use of OSGi Remote Services to create a formal separation between contract/service type and implementation makes system complexity much easier to understand and manage.
  2. It provides flexibility and extensibility. 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.
  3. Eliminate vendor transport lockin. ECF's open implementation of OSGi Remote Services is the only transport independent implementation, allowing custom distribution and discovery providers to replace existing implementations. Such custom providers may be FOSS or not; the decision is up to the custom provider implementer.

Here are several tutorials showing how ECF Remote Services can be used on several OSGi frameworks. Distributedosgi1.png

Under Construction

Related Documentation

Getting Started with ECF's OSGi Remote Services Implementation

Tutorial: Building your first Asynchronous OSGi Remote Service

Asynchronous Remote Services

ECF Remote Services Tutorials

ECF API Docs

API Javadocs

Getting Started with Using the ECF Remote Services API

Distributed EventAdmin Service