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"
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
| − | + | OSGi Enterprise specification provides a new standard for service-oriented architecture (SOA). This standard uses the well-established OSGi '''service registry''' to export services for out-of-process access...i.e. OSGi services are distributed via 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, | + | 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, running and managing distributed services. Such an 'ala carte' model is helpful for implementing distributed applications for two at least reasons: |
| − | # It '''reduces''' overall '''system complexity'''. | + | # It '''reduces''' overall '''system 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. |
# 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. | # 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 standardized Remote Services can be used with ECF's implementation. | ||
[[Image:distributedosgi1.png]] | [[Image:distributedosgi1.png]] | ||
| − | |||
| − | |||
==Related Documentation== | ==Related Documentation== | ||
| + | |||
| + | [[Getting Started with ECF's OSGi Remote Services Implementation]] | ||
| + | |||
| + | [[ECF#Introductory_Materials]] | ||
[[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 Using the ECF Remote Services API]] | [[Getting Started with Using the ECF Remote Services API]] | ||
Revision as of 15:06, 27 October 2014
Introduction
OSGi Enterprise specification provides a new standard for service-oriented architecture (SOA). This standard uses the well-established OSGi service registry to export services for out-of-process access...i.e. OSGi services are distributed via 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, running and managing distributed services. Such an 'ala carte' model is helpful for implementing distributed applications for two at least reasons:
- It reduces overall system 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.
- 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 are several tutorials showing how standardized Remote Services can be used with ECF's implementation.
Related Documentation
Getting Started with ECF's OSGi Remote Services 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 |