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.
Difference between revisions of "OSGi Remote Services and ECF"
(→Introduction) |
(→Introduction) |
||
| Line 3: | Line 3: | ||
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. | 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). | + | In keeping with OSGi's modularity, 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 two primary reasons: |
| − | # It helps reduce overall system complexity. By only including | + | # It helps reduce overall system complexity. Networked/distributed applications frequently can 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. | + | # It provides flexibility. Networked applications frequently require a good deal of flexibility...i.e. the flexibility to replace one protocol with another, flexibility in deployment and management, etc. The flexibility of using OSGi modularity 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 | + | Here is a diagram showinthe ECF modules that implement the standard. |
[[Image:distributedosgi1.png]] | [[Image:distributedosgi1.png]] | ||
| Line 14: | Line 14: | ||
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 - [[Getting Started with ECF's OSGi Remote Services Implementation]] |
#Remote Services API - [[Getting Started with Using the ECF Remote Services API]] | #Remote Services API - [[Getting Started with Using the ECF Remote Services API]] | ||
Revision as of 19:10, 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.
In keeping with OSGi's modularity, 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 two primary reasons:
- It helps reduce overall system complexity. Networked/distributed applications frequently can 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.
- It provides flexibility. Networked applications frequently require a good deal of flexibility...i.e. the flexibility to replace one protocol with another, flexibility in deployment and management, etc. The flexibility of using OSGi modularity 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 showinthe ECF modules that implement the standard.
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 OSGi Remote Services Implementation
- Remote Services API - Getting Started with Using the ECF Remote Services API
Related Documentation
Getting Started with ECF's RFC119 Implementation
Getting Started with Using the ECF Remote Services API
Distributed EventAdmin Service
| Eclipse Communication Framework |
| API |
| API Documentation • Javadoc • Providers |
| Development |
| Development Guidelines • Integrators Guide |