Remote services are frequently useful for fog/edge use cases, where the communication transports (e.g. MQTT) may be different than those typically used in the cloud (e.g. http/https, jaxrs, enterprise messaging, etc).
Typically, remote services are run on OSGi-based frameworks and apps such as Equinox, Felix, Karaf, Eclipse, and others, and indeed ECF's RSA implementation works very well in any of these environments.
Perhaps less well known, however, is that remote services can be used in other inter-process environments...for example between Java and Python.
It's also possible to use ECF remote services without an OSGi framework, i.e. running only as Java applications. This repository has an example of using ECF remote services without an OSGi framework. The projects are Java applications (no OSGi framework assumed), on both the remote service provider side, as well as the remote service consumer side. The examples may be run within Eclipse by using the launch configs in the example projects.
Most of the benefits of OSGi Remote Services are still available...for example the ability to use multiple distribution providers for a service, the ability to remotely discover services and dynamically respond to network failure, and the ability to use the OSGi service registry for service dynamics, and service injection. Also, the service definition, implementation, registration and lookup are exactly the same whether via an OSGi bundle or a Java application. This allows services to be defined consistently across runtime environments in addition to cross-distribution mechanisms.
Please clone the ServiceRegistry github repository and give things a try!
4 comments:
nable to resolve 2.0: missing requirement [2.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.felix.dm)(version>=4.4.0)(!(version>=5.0.0)))
, agenda.service.simple-0.0.0 org.osgi.framework.BundleException: Unresolved constraint in bundle agenda.service.simple [3]: Unable to resolve 3.0: missing requirement [3.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.felix.dm)(version>=4.4.0)(!(version>=5.0.0)))
This appears to be the output from a framework that has a bundle agenda.service.simple with a requirement for org.apache.dm version >= 4.4 and < 5.0.0.
You have described how the problem of accessing the internal state of the components is solved (though, in fact, the OOP paradigm solves it just fine). But you haven't described how the problem of growing complexity of the project is solved by OSGi (new components are added, new arrows appear - obviously, this doesn't scale, even given that the internal state of the component is nicely encapsulated). Does OSGi provide a solution to that? Thanks.
Hi eu4,
encapsulation, information hiding, and separation of concerns (modularity) are enforced by the OSGI bundle layer. This provides the tools for scaling up system complexity, and I disagree with you that this doesn't scale. Of course for any large system (particularly a multi-process/distributed system) it's going to require more than just OSGI-provided modularity. That's why OSGI provides additional concepts, such as OSGi services, dynamic composition, subsystems, standardized services, versioning, and others. Even still, if these mechanisms are used poorly (e.g. one bundle/no modularity, no separation of concerns, etc), or not at all then it seems to me that scaling will be limited by complexity.
In other words, I think that OSGi provides a number of very useful mechanisms for building solutions that scale, but I don't see how any technology could force people to use those mechanisms appropriately.
Post a Comment