Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsBlueprint/Hibernate/ECF Support
https://www.eclipse.org/forums/index.php/mv/msg/877313/1494955/#msg_1494955
our company is planning to implement an OSGI-based private cloud platform including both web nodes and backend nodes hosting business services.
I am evaluating Gyrex and walked through the learning material - it looks promising to me, though some important open points arise:
- Gemini Blueprint Support:
The provided examples use OSGI-DS. Are there any experiences on using Blueprint services in the context of a (production) clustered Gyrex environment?
- Hibernate / JPA:
Any experiences on Hibernate instead of EclipseLink?
- ECF integration:
I refer to "Bug 383415 - Integrate ECF OSGi Remote Services" (sorry cannot yet post links).
Are there any updates on ECF integration or was the idea skipped in favour of the implementation of the distributed event bus?
Thanks in advance!]]>Florian Iero2014-12-01T22:25:06-00:00Re: Blueprint/Hibernate/ECF Support
https://www.eclipse.org/forums/index.php/mv/msg/877313/1495719/#msg_1495719
On 2014-12-02 03:34:15 +0000, Florian Iero said:
> our company is planning to implement an OSGI-based private cloud
> platform including both web nodes and backend nodes hosting business
> services.
> I am evaluating Gyrex and walked through the learning material - it
> looks promising to me, though some important open points arise:
That's great to hear. :)
> - Gemini Blueprint Support:
> The provided examples use OSGI-DS. Are there any experiences on using
> Blueprint services in the context of a (production) clustered Gyrex
> environment?
I don't have any. We use DS because OSGi services is the level of
integration/extensibility that Gyrex provides. We never felt a need for
using Blueprint, though. We use the runtime context a lot for
multi-tenancy which supports JSR 330 DI. That together with DS/OSGi
service provided us with a programming model that we found sufficient.
But I don't see any reasony why it shouldn't work. It should be
possible to add any Blueprint implementation to the stack.
> - Hibernate / JPA:
> Any experiences on Hibernate instead of EclipseLink?
Yes, there is some history with Hibernate. But those experiences aren't
recent. We went with EclipseLink because of the much better support for
OSGi back then. Also, the communication with the development team was
great and we were able to get many things done necessary for a proper
JPA integration into OSGi.
Things might have changed meanwhile. Thus, I recommend doing a
evaluation and pick the technology you want. JPA/EclipseLink is just an
additional integration add-on which doesn't have to be used with Gyrex.
I'm happy to help with any of this.
> - ECF integration:
> I refer to "Bug 383415 - Integrate ECF OSGi Remote Services" (sorry
> cannot yet post links). Are there any updates on ECF integration or was
> the idea skipped in favour of the implementation of the distributed
> event bus?
Kind of, the reason ECF remote service is not yet there is that we
never had a strong case for adding it to the stack. I'm not a fan of
"transparent" remoting of OSGi services. I love web apis (rest,
websockets) and prefere them over anything else. All that was already
available.
Gyrex comes with ZooKeeper integration and even provides an embedded
ZooKeeper. That might help with things like service discovery/lookup
and availability/failover. Again, I'm happy to help anyone who is
interested in in integrating ECF with Gyrex. :)
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxx http://runolarity.com/]]>Gunnar Wagenknecht2014-12-02T13:04:03-00:00Re: Blueprint/Hibernate/ECF Support
https://www.eclipse.org/forums/index.php/mv/msg/877313/1512751/#msg_1512751
Quote:
I'm not a fan of
"transparent" remoting of OSGi services.
Although I believe I understand what Gunnar is saying when he refers to Remote Services as 'transparent', I mildly disagree with Gunnar that ECF's impl of OSGi Remote Services constitutes a 'transparent' remoting of OSGi services.
Of course it's true that OSGi Remote Services expose OSGi services for remote access..and this can be done completely 'transparently'. But there are several things about both the spec and ECF's impl that make Remote Services more flexible than traditional remoting systems.
By my definition, fully transparent remote services are those that attempt to 'hide' the underlying networking/communication from the service consumer.
First, the OSGi Remote Services spec defines a set of standardized service properties (meta-data about the service). One of those standard properties identifies the RS proxy as a proxy, allowing consumers of the service to identify at runtime the service instance as a proxy or a local service use the service reference in different ways. By itself, this provides quite a lot of flexibility for consumers and comes completely naturally given the existence and standardization of OSGI service properties that the Remote Service specification provides.
Second, it's completely feasible (even likely) that the creators of OSGi services (i.e. the ones that define the service interfaces) will choose to define a service as 'local only' or 'remote only'...or even define two service interfaces, one for local access and the other for remote access. For many use cases, I would be inclined to do this, and not to try to make an existing (local) OSGi service available for remote access. The ability to have such a design (one service interface for local access, another for remote access) provides a good degree of flexibility for service creators and their service consumers.
Third, the Remote Service Admin specification (an admin agent for remote services) allows significant flexibility in deciding *when* and *if* an OSGi service is actually exported for remote access, and provide a means to easily implement the approach described above (defining a local and remote service interface).
Fourth, the dynamics available for OSGi services can easily be used to deal with partial failure...one of the harder problems created by 'fully transparent remoting'.
Fifth, ECF's implementation provides two relevant technologies that may also be used to avoid the problems typically associated with network transparency:
2) An approach to defining and automatically constructing asynchronous proxies. Asynchronous proxies provide non-blocking access to arbitrary remote services. See here for an example and links https://wiki.eclipse.org/Tutorial:_Building_your_first_Asynchronous_OSGi_Remote_Service
Asynchronous proxies address another part of traditionally 'transparent' remote services (RPC with blocking I/O).
To reiterate my main point: the flexibility of OSGi services, the RS standardized meta-data, RSA, OSGi service dynamics, and ECF proxy creation and asynchronous proxies allow the creation of Remote Services that are not limited to transparent approaches. Full transparency is allowed, if that is desired/needed for a given service use case, but the standardized and ECF-specific mechanisms defined above can and do allow the flexibility for Remote Services to be defined and used in a non-transparent manner, while still getting many of the benefits of (e.g.) having a clear separation between contract and (remote) implementation.
One other quick comment about this part of Gunnar's comments:
Quote:
I love web apis (rest,
websockets) and prefere them over anything else. All that was already
available.
ECF is attempting to provide the best of the web apis world, along with being able to use the advantages of OSGi Remote Services by allowing the customization of the RS proxy. See this tutorial for an example of what this allows (both web API service consumers along with RS/OSGi services consumers):