Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EIG:Introduction to OSGi Remote Services"

Line 1: Line 1:
 
Chapter 13 in the 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 over a network.  
 
Chapter 13 in the 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 over a network.  
  
[[Image:ECF RS.png]]  
+
[[Image:ECF RS.png|center]]  
  
 
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:  
 
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:  

Revision as of 15:03, 12 February 2011

Chapter 13 in the 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 over a network.

ECF RS.png

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.

Back to the top