This forum has been archived. Please start a new discussion on GitHub.

IceBox use case

I'm sorry if this is a stupid question, but I've read and re-read the manual on IceBox and I don't really understand what it buys you. When would it be desirable to use IceBox.Service instead of Ice.Application? I'd appreciate some help understanding this topic. Thanks.


  • mes
    mes California
    Hi Isaac,

    Here are the main benefits of IceBox:
    • For a language like Java where a program is executed in a virtual machine, being able to execute several independent services in the same JVM reduces memory utilization.
    • For interdependent services in performance-sensitive applications, implementing them as IceBox services gives you the option of using collocated invocations between services. This essentially reduces the overhead of a "remote" procedure call to a simple native method call. Ice takes care of this automatically thanks to its location-transparency behavior.
    • Building services as discrete entities forces developers to think in terms of independent components instead of monolithic applications, and this in turn allows you to deploy services in whatever combinations you see fit.
    Let me know if anything is unclear.

  • I couldn't agree more

    Even in C++ using IceBox Services is extremely useful to keep components as independent as possible. We created icebox service rules in our build system, that let you build and unit test each service separately using very simple python scripts that emulate surrounding service within the unit (e.g. CustomerService, ContractService, AccountService) and at runtime these core services are combined into one IceBox that uses collocation optimization. Definitely payed out for us for many reason, separating responsibilities and improving QA being the most important ones.