ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <ra...@apache.org>
Subject Ignite modularisation: client/server separation
Date Mon, 03 Aug 2015 11:31:49 GMT
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