Howdy,
Apologies if I'm misinterpreting Mike's comments below as I was not able
to attend this presentation (but will watch it when available).
On 4/30/2020 2:20 PM, Mike Hummel wrote:
Hello,
<stuff deleted>
- A common topic for clustering is a common cache and locking. It's possible
with hazelcast. But I was not able use hazelcasts caching service - lots of
class loader issues. I was able to use ehcache (no locking) and redis for this
features. It's a shame that specially 'java caching api' is not possible in
OSGi using hazelcast. It's also not easy with ehcache but I found a workaround.
[Scott] It seems possible to me that remote services could be useful for
creating such a 'java caching api', and ECF has a distribution provider
based upon hazelcast [1]...allowing a nice separation between 'caching
api' (set of interacting osgi services), implementation (OSGi service
impls) and distribution (Hazelcast and/or other distribution providers).
<stuff deleted>
I found the presentation of Dimitry very helpful. I will try not to divide each
service in a separate container. In this scenario it's also possible to share
database entities in the same JVM engine - this will even boost the performance
- instead of using it via rest all the time.
Also interesting is the support of API gateways. For me a big problem is the
service discovery. It's absolutely stupid to configure each service manually in
the API gateway. A more comfortable way would be some kind of discovery. Karaf
could automatically configure/update the gateway depending on the provided jax
rs resources.
WRT service discovery...remote services specifies service discovery
using an arbitrary comm protocol, and ECF has a discovery provider based
upon etcd [1], which is also used in Kubernetes I believe. With this
etcd provider [2], I expect that creating a Kubernetes remote service
publish/discovery would be straightforward.
Scott
[1] https://github.com/ECF/HazelcastProvider
[2] https://github.com/ECF/etcd-provider
