Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Gyrex » Blueprint/Hibernate/ECF Support
Blueprint/Hibernate/ECF Support [message #1494955] Mon, 01 December 2014 22:25 Go to next message
Florian Iero is currently offline Florian IeroFriend
Messages: 2
Registered: December 2014
Junior Member
Hi,

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!
Re: Blueprint/Hibernate/ECF Support [message #1495719 is a reply to message #1494955] Tue, 02 December 2014 13:04 Go to previous messageGo to next message
Gunnar Wagenknecht is currently offline Gunnar WagenknechtFriend
Messages: 486
Registered: July 2009
Location: San Francisco ✈ Germany
Senior Member

Hi Florian,

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/
Re: Blueprint/Hibernate/ECF Support [message #1512751 is a reply to message #1494955] Tue, 16 December 2014 01:13 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1030
Registered: July 2009
Senior Member
Hi Gunnar and Florian,

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:

1) Open APIs allowing the creation of the RS proxy to by arbitrarily customized. This allows the creation of arbitrarily complex consumer-side proxy implementations for a given remote service. For an example of what this allows, see this tutorial: https://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_for_Accessing_Existing_REST_Services

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):

https://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_for_Accessing_Existing_REST_Services

Thanks,

Scott
Previous Topic:Any hints on setting up the target platform?
Next Topic:what's the correct eclipse version shall I use for gyrex 1.3.2?
Goto Forum:
  


Current Time: Fri Nov 16 04:20:36 GMT 2018

Powered by FUDForum. Page generated in 0.02445 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top