In my view Ignite service grid supports a lot more than Hazelcast and provides much simpler API for it.
1. You can deploy service on any single node in the cluster, any cluster group, or on the whole grid. 2. Ignite Service is not a wrapper around cache. It can have any user logic within a service and access any kind of data structure provided by Ignite. For example, your service can access several Ignite caches, or queues, issue computations on the grid, etc, etc. 3. Ignite service grid supports a rich deployment model. In addition to deploying any number of services on any node, you can also use convenient service deploy methods on Ignite API to deploy cluster-singletons, node-singletons, and key-singletons. 4. Ignite series can be accessed locally on the servers they are deployed on and remotely. In case of remote access, Ignite will still provide you with the same deployed service API, but will proxy the calls internally to the servers on which the services are deployed. 5. You can use Ignite services in sticky or non-sticky mode. In case of sticky mode, Ignite will always proxy service API calls to the same remote server. For non-sticky usage, Ignite will automatically load-balance service invocations among the service that have the service deployed. As Valentin suggested, if you describe your use case, will may be able to suggest in more detail how it can be implemented with Ignite. D. On Thu, Feb 11, 2016 at 9:16 PM, vkulichenko <[email protected]> wrote: > Hi Gareth, > > Ignite's Service Grid really differs from Hazelcast SPI. From what I see > these are completely different features. > > Can you please elaborate what your service does? If we know more details > about your use case, it would be easier to propose the best solution. > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Migrating-From-Hazelcast-Service-Interface-To-Apache-Ignite-Service-Interface-tp2970p2971.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
