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.
Difference between revisions of "OSGi Remote Services and ECF"
(New page: ==Introduction== ECF's support for OSGi 4.2 Remote Services is a layered set of application programming interfaces (APIs). The API layering and the associated modularity (coming from the...) |
(→Introduction) |
||
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
| − | ECF's support for OSGi 4.2 Remote Services is a layered set of application programming interfaces (APIs). | + | 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 mechanisms. |
| + | |||
| + | 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 interoperability. In other words, system complexity is reduced by using only the modules needed for the service, while flexibility is increased. | ||
Here is a diagram showing the relationship between the various layered APIs in ECF's support of OSGi Remote Services. APIs are shown in white and gray, implementation/providers are shown in blue. | Here is a diagram showing the relationship between the various layered APIs in ECF's support of OSGi Remote Services. APIs are shown in white and gray, implementation/providers are shown in blue. | ||
Revision as of 16:00, 21 January 2010
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 mechanisms.
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 interoperability. In other words, system complexity is reduced by using only the modules needed for the service, while flexibility is increased.
Here is a diagram showing the relationship between the various layered APIs in ECF's support of OSGi Remote Services. APIs are shown in white and gray, implementation/providers are shown in blue.
Here are two pages (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
- 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 |