ICE and Low Bandwidth/Disrubtable Environment

[beaudetious]

My team is working on a C# application for vehicles that operate in a low bandwidth, TCP/IP wireless (but secure) environment prone to frequent dropped connections, etc. Multiple vehicles (clients) communicate with a single server sending and receiving messages. Currently we communicate with the server (on the backend) using standard VS.NET 2005 generated web services.

We've been tasked with improving our messaging performance and, as such, I've been doing some reading on ICE. My understanding so far is that we are just begging for problems - using SOAP and it's xml parsing overhead, compression overhead, encryption overhead, etc.

Is ICE something more suited to what we are trying to achieve? I'm concerned with some of the blog posts out there indicating that ICE is nice (can I trademark that?) but it's not appropriate for interoperability. However, my reading on your site makes me feel that you've got that covered (as far as Java, C++, Python, C#, etc. are concerned).

Thanks for any input I may recieve,

Brian

[matthew]

On the face of it Ice sounds ideal for what you are trying to achieve. If you try to use SOAP then you will have to deal with many things that Ice deals with automatically yourself such as request retry, connection re-establishment. In addition, you will have to deal with the bloated request size, the CPU required to process the unearthly XML, lack of standardized language APIs and, of course, the lack of any real object model, etc.. In addition, you will not be able to take advantage of the significant existing infrastructure components that Ice provides (IceGrid, IceStorm, Freeze, SSL, IceBox, Glacier2).

Is ICE something more suited to what we are trying to achieve? I'm concerned with some of the blog posts out there indicating that ICE is nice (can I trademark that?) but it's not appropriate for interoperability. However, my reading on your site makes me feel that you've got that covered (as far as Java, C++, Python, C#, etc. are concerned).

As to the above comment -- when you speak of interoperability this can mean many different things. Interoperability with what?

Other object systems, for example, with SOAP? What you cannot do is talk natively to a SOAP Server with Ice and vice versa -- that is you need to write some sort of bridge (if indeed you need to bridge). There have been many different automatic bridging products written in the past for other RPC systems which have invariably resulted in failure because of mismatches in the object models, type systems and so on. Hand coded bridges are invariably better -- they present a more suitable object model which is more convenient to use and more efficient.

A better question is why would you want to bridge? Using Ice in your applications certainly does not precludes the use of SOAP. For example, you could write an Ice server that issues SOAP requests to some web service out there, and you can write Ice clients that talk to both Ice servers and SOAP servers.

How about other platforms? Ice is supported on most modern operating systems, such as Linux, Windows, Mac OS, Solaris, etc.

Language interoperability? In this respect I think Ice has all modern popular languages covered.

Another thing you might want to consider is support and documentation. In this respect I think we are second to none. As you can see we provide timely accurate support here on our forums. Our documentation is in many forms -- the Ice book a large tome of knowledge, our monthly connections newsletter where we provide real world advice on how to use Ice, the ZeroC forums and our community of developers.

Hope that helps!

[beaudetious]

Thanks for the prompt reply. I was given a few hours notice to explain the benefits of ICE and then the meeting was promptly canceled. So I have spent little more time familiarizing myself with the ICE API and reading through the (immense) documentation.

I hope I can make a clear argument for ICE because I like what I see and our Java developers agree. It's just our C# devs (me included) that are more familiar with the auto generated web service code via Visual Studio.

Personally, I think it's time to expand our knowledge base.

Take care,

Brian

[beagles]

I'd like to add a little bit about platform support and portability. IceE picks up where Ice leaves off, allowing very small devices to participate in your Ice based systems. Check out our supported platforms page, for a list of platforms that we currently are developing and testing on.

[beaudetious]

In our case, Mobile is a project name. Our client software is installed on a touch screen laptop running Windows XP (in an officer's patrol car) and our server is typically deployed on Windows 2000 or higher.

The big problem we are facing is reliable message transfer. I can't get into specifics because a) I'm not supposed to and b) I'm still learning the architecture myself.