ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: Ignite modularisation: client/server separation
Date Mon, 03 Aug 2015 16:14:41 GMT
Raul,

Again, for the sake of unification I don't see why client will be OSGi
compliant but server will not. It will only confuse users. Having said
that, if we are going to add OSGi support IMO we should try to do that for
both client and server. And I'm sure this still will be cheaper than
separating client and server.

As for jar size, I can burn a big server out of resources with a single
Java class less than 1kb in size =) So this is still a wrong metric to me.
If I was IoT stuff developer I would not trust any third party dependencies
at all until I know that they were *initially designed* for IoT and
restricted devices. And what is needed here is exactly separation of
concerns: tiny, as optimized as possible for each particular IoT device
client + powerful Ignite cluster bundled with application logic on the back
end.

Time ago at GridGain we were experimenting with iOS and Android clients,
but this did not actually pay off..

Sergi



2015-08-03 18:40 GMT+03:00 Sergi Vladykin <sergi.vladykin@gmail.com>:

> Gianfranco,
>
> Honestly, I don't like that we allowing to run computations on clients,
> because anyways in most cases it is meaningless, but now we must keep this
> for backward compatibility. And for example if we would decide to implement
> separate client with the same API as suggests Raul, this will be an
> obstacle.
>
> Sergi
>
> 2015-08-03 16:48 GMT+03:00 Gianfranco Murador <
> murador.gianfranco@gmail.com>:
>
>> Hello everyone,
>> I have a question about this topic :
>> the unification between client and server is also due to the fact that I
>> can do computations on the client nodes ?
>> For computation I mean something like this:
>>
>> ClusterGroup clientGroup ignite.cluster().forClients ( ) ;
>> IgniteCompute clientCompute = ignite.compute ( clientGroup ) ;
>> // Execute computation on the client nodes .
>> clientCompute.broadcast ( ( ) - > System.out.println ( " Hello Client " )
>> )
>> ;
>>
>> Thanks, Regards, Gianfranco
>>
>>
>> 2015-08-03 15:23 GMT+02:00 Sergi Vladykin <sergi.vladykin@gmail.com>:
>>
>> > 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