ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: Ignite modularisation: client/server separation
Date Mon, 03 Aug 2015 16:21:07 GMT
Hi Raul,

At my company we run Ignite in an OSGi container. If I remember correctly we only had to provide
our own (OSGI-aware) implementation of the Marshaller SPI and add the bundle manifest.

As for the "client" bundle, wouldn't the Ignite REST API be sufficient for what you have in
mind? It's quite easy to write a very "thin" client with no 3d party dependencies (except
maybe the REST client) on top of the REST API.

Regards
Andrey

> From: raulk@apache.org
> Date: Mon, 3 Aug 2015 16:01:19 +0100
> Subject: Re: Ignite modularisation: client/server separation
> To: dev@ignite.incubator.apache.org
> 
> Hi Sergey,
> 
> That's great if you think that the OSGi enablement can be achieved without
> separating client from server. My concern with OSGifying all of current's
> ignite-core is that we would be incurring the cost of OSGi-enabling the
> server side when, quite honestly, there's probably little interest in that.
> Folks will be interested in interacting as clients with Ignite servers from
> OSGi, not in running Ignite servers within OSGi containers.
> 
> Out of over 200 Camel components hosted at the ASF, there are only around
> 12 that are *not* OSGi-friendly. When we create a component that leverages
> a library/framework that's not OSGi-compatible, we try to engage with the
> relevant communities to enhance the library in that direction. Or if the
> communities are not in a position to collaborate and the OSGi enablement
> can be achieved without structural changes (sometimes it's just a matter of
> adding the right manifest headers – but I get the impression Ignite's
> server-side will be more complex), we create a wrapper in the ServiceMix
> Bundles community and publish it to Maven Central.
> 
> The ~ 12 components which are not OSGi-friendly are young, mostly
> introduced in Camel >= 2.15. So it's ok to create a camel-ignite component
> without OSGi support for now, but we should be having a roadmap to not
> frustrate our OSGi users (as I said, we have a significant base) and for
> the component to be accepted into Camel without objections.
> 
> With regards to the separation itself, I still think a JAR of nearly 7mb is
> too big a burden for all clients. This is not an opinion about "right
> engineering practices", but my practical opinion as an Ignite user. I get
> excited with the applications of Ignite in the IoT – for pure caching, one
> can use the Memcached client, but the compute capability, service registry,
> messaging, etc. make it really appealing in this context. And given the
> resource scarcity inherent in IoT devices, I don't see why a mobile client
> or an embedded device should spare 7mb for the library when it won't even
> use 20% of its capability given that it'll never act as a server.
> 
> Regards,
> 
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
> 
> On Mon, Aug 3, 2015 at 2:23 PM, Sergi Vladykin <sergi.vladykin@gmail.com>
> wrote:
> 
> > Raul,
> >
> > As far as I understand your main concern is that Ignite is incompatible
> > with OSGi (other points seem to be more about your personal feelings about
> > "right engineering practices" than about real problems). I believe that we
> > can achieve this compatibility without such a big refactoring of
> > everything. But do we really need that if it is not a requirement for
> > Camel?
> >
> > BTW client/server API of Ignite is intentionally unified to make it easier
> > to use (simply switch one flag in config instead of rewriting your code to
> > completely different API). In this case unification works better than
> > separation of concerns.
> >
> > Sergi
> >
> > 2015-08-03 14:31 GMT+03:00 Raul Kripalani <raulk@apache.org>:
> >
> > > Hello guys,
> > >
> > > Spoke to Dmitriy over the weekend about the modularisation of Ignite.
> > >
> > > At Apache Camel we strive to make all our components (including the
> > future
> > > camel-ignite) OSGi compatible because have a significant user base
> > > deploying Camel apps on Apache Karaf.
> > >
> > > I see some groundwork before we can aspire to make OSGi components
> > > communicate with Ignite:
> > >
> > >    * There seems to be no concept of a client. Client-side and
> > server-side
> > > coexist in ignite-core. There's no code separation, so a client wanting
> > to
> > > communicate with an Ignite topology will end up importing the server-side
> > > implementation too.
> > >
> > >    * ... and the server-side implementation uses classloading constructs
> > > (e.g. Zero Deployment) which may prove hard to engineer for compatibility
> > > with OSGi. This re-enginering is a waste of time IMHO because there's no
> > > interest in running Ignite servers on top of OSGi - only clients.
> > >
> > >    * The ignite-core JAR (6.7mb) is too heavy for a component that's
> > > nothing but a client. Some average Java client API sizes for reference:
> > > hazelcast (400kb), activemq-client (1.2 mb), kafka (300kb).
> > >
> > >    * Possible dependency leak. Currently not a problem as we lack 3rd
> > party
> > > deps in ignite-core. But if we introduce any, we'll impose our dep
> > versions
> > > on the client creating possible classpath hell. Or seen from another
> > > perspective: I don't know the reason we have no 3rd party deps, and I'm
> > > sure we've had to reinvent the wheel at some point... Perhaps we avoided
> > > them because we knew we would be imposing them on the client? If that's
> > the
> > > case, separating server and client will bring lots of flexibility.
> > >
> > >    * This architecture/design entails a lack of separation of concerns,
> > > IMO. While it's true that a client can start an embedded Ignite instance
> > > (and for that it'll need the server-side code), not all clients will do.
> > In
> > > my opinion, ignite-java-client (hypothetical name) should discover
> > > ignite-core (just the server-side impl) in the classpath if starting an
> > > embedded Ignite is requested.
> > >
> > > What's your opinion? Obviously such a refactoring is a large undertaking
> > > and not for immediate action. If the community shares this vision, I
> > would
> > > start thinking about this for 2.0.
> > >
> > > P.S.: With regards to Camel, a warning on the camel-ignite doc page for
> > not
> > > being OSGi-compliant will suffice.
> > >
> > > Regards,
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message