It’s been quite a while since my last post. The reason (as you might have guessed) is that we’ve been very busy with Ice Touch, which we released last week. If you haven’t seen it yet, I suggest that you head over and take a look.

Ice Touch really is quite a cool way to get network-enabled applications onto the iPhone and iPod touch. For example, we’ve ported our chat application to the iPhone, and you can use the chat server we host (or a server of your own) to run the Ice protocol straight from the phone to the server. We have also included an application that shows how to access a database from the iPhone.

Of course, strictly speaking, you don’t need Ice to do this. However, if you want to network your application using the facilities in the iPhone SDK, you are back to the way we did things twenty years ago, namely, raw sockets. And, as we all know, that’s a rather tedious way to do networking, and doubly so for a mobile device, with its often unreliable wireless network connections. Ice handles these things for you in its usual elegant way: failed operation invocations are retried automatically (provided they will not violate at-most-once semantics), and location transparency means that you do not have to hard-wire addresses and ports.

In fact, Ice Touch gives you a full-blown development environment with almost all of the features of Ice for Windows or Linux. To keep code size small, we made a few minor concessions in Ice Touch, but the important things are all there. In particular, the run time is fully thread safe, you can use TCP, UDP, and SSL, you can use synchronous and asynchronous invocations, and the iPhone can even act as a server.

Normally, you would not expect to run an Ice server on an iPhone. However, the server-side support is important for callbacks: you can implement an Ice servant in the iPhone and have it respond to invocations from a client elsewhere. In other words, with Ice, you can create push applications that allow a server in your corporate network to push information to the iPhone instead of having to poll the server from the phone.

Ice Touch provides the same router support as Ice for other platforms, which means that you can do all this even if the server you need to access from the iPhone is behind a firewall (thanks to Glacier2) and, because Ice Touch supports bidirectional connections, the firewall does not interfere with push applications.

The development language for iPhone applications is Objective-C so, naturally, Ice Touch includes an Objective-C mapping. The mapping is simple and elegant and nicely integrates with the Cocoa framework. For example, a Slice dictionary is mapped to a Cocoa NSDictionary, so you are already familiar with how to use it. After maybe half an hour of browsing the manual, you’ll be up and running, especially if you have experience with Ice for other programming languages.

Overall, Ice Touch is a great development platform for the iPhone and iPod touch. Ice Touch makes it easy to create networked applications that seamlessly integrate with your corporate computing environment. Or, if you are into the lighter side of computing, with Ice Touch you can create multi-user games without having to sink a large part of your budget into the development of custom protocol stacks and sockets code. And, in contrast to other mobile platforms, it is easy to distribute your application via the App Store.

We see a great future for Ice Touch. For one, the trend toward wireless mobile computing shows no sign of abating; the continuously improving wifi coverage and affordable unlimited data plans in many countries will accelerate this trend. Second, the iPhone’s computing power and memory capacity are at the point where it is possible to create fully-featured mobile applications with slick user interfaces that are fun to use, instead of having to live with applications that are crippled by the limitations of a less powerful device. Finally, future versions of the iPhone (and other mobile devices) will be more powerful still. It will be interesting to see the impact of Android, for example. I expect that, over the next few years, we will see a new renaissance in computing, driven by increasingly more powerful devices and applications that are truly distributed, with the user interface chores handled by the mobile device, and heavy-duty database and computing needs being met by remote data centers.

Ice Touch is the first and only middleware for the iPhone. It removes a major obstacle from the development of truly networked and interactive mobile applications. So, I suggest that you give Ice Touch a try, get your toes wet, and catch the wave. Or, as they say, the early bird catches the worm!

Cheers,

Michi.

Jose and Mark have just written a second article on our chat demo. This installment shows you how to build GUI clients for the chat demo in C# and Java, as well as how to build web-based clients with PHP or Silverlight.

The articles don’t just explain how to build a chat application, but discuss design trade-offs that confront many Ice applications, and how to choose an appropriate design. I suggest you give this a read—chances are that you will find it useful in your day-to-day development even if you are not into writing chat applications.

This post marks the end of one era, and the beginning of another. What is ending is our newsletter Connections. After some navel gazing, we decided that the newsletter format was too inflexible as an effective communication tool. Besides creating the content for the newsletter, quite a bit of work goes into the typesetting for each issue that, apart from making for pretty PDF pages, does not really contribute anything. Moreover, because we publish Connections every two months, it does not provide us with a way to deal with “little” topics that are too small for an FAQ or an article. And, occasionally, we would like to discuss a news item or a topic that has popped up on someone else’s blog but, by the time we publish the next issue of the newsletter, the topic is yesterday’s news…

What we really need is something that gives us more flexibility and allows us to throw in short and sharp snippets about middleware without having to go to the trouble of publishing a newsletter, and blogs are an ideal way to do that. So, here we go—you are reading the first of our blog entries, which marks the start of the new era.

In this new era, are you going to have to make do without all the awesome information we used to publish in Connections? (Big pat on our collective shoulders here…) The answer is “Of course not!”

• We will continue to publish FAQs. (We have just added two new ones, about distributed garbage collection and MQ Series.)
• We will continue to publish articles that discuss various topics in depth. (See our article page for our latest literary masterpiece.)
• We will continue to publish opinion pieces in the style of the Connections editorials.

So, everything you have come to love (yes—I know I’m in a presumptuous mood today) will still be there, just in a different format. In addition, you’ll get more topical and off-the-cuff contributions from us that, up to now, we did not really have an outlet for. And, of course, blogs allow you to comment and discuss things whereas communication with PDF documents is very much like Ice oneway invocations. I hope that you will take advantage of the comment feature and praise us for our latest brilliant ideas. (For example, you’ll be at liberty to tell me straight away that, today, I’m being too presumptuous and put me back in my place, instead of having to send me an email that I will dutifully ignore.) In other words, we can have a good old chat about all things Ice, middleware, ZeroC’s plans for world domination (just kidding…), and whatever else happens to pop up.

Which brings me to another way of chatting… If you look back through past issues of Connections, you will notice that most articles have concentrated on a specific feature of Ice, or explored a single design or implementation technique. All these designs and techniques are useful, apply in the real-world, and a typical Ice application will likely use several of these designs and techniques. And that is exactly the point: a typical Ice application will use several of these designs and techniques, not just a single one. As always in software development, different designs do not stand in isolation and, when combined, can interact with each other and present design challenges that, otherwise, would not arise. Ice is no different, so we thought it would be useful to present a more complex Ice application that combines several features and services.

This show-case application is a chat application that allows people to communicate with each other in real time over the internet, much like MSN Messenger or Yahoo! Messenger. We have no ambitions to supplant these existing services, which do a fine job. Rather, we chose a chat application because it presents design and implementation challenges that are common to many distributed applications. For example, it must be possible to authenticate clients that want to use the application, eavesdroppers must not be able to monitor other people’s conversations, the application must co-exist with existing client- and server-side firewalls, and it should be robust in the face of misbehaved or malicious clients. In other words, the idea is to show how to design and implement an industrial-strength Ice application that meets real-world requirements and is more than just a toy demonstration.

Obviously, you would expect Ice to be suitable for this (otherwise we would not dare to present the application in the first place). But you may not expect how remarkably easy it is to develop such an application. Despite the realistic requirements, code complexity rises (almost) linearly with the number of requirements and not as some higher-order function. This is because Ice provides features and services that are well designed, address orthogonal concerns, and, as a result, are easy to combine and adapt to specific application requirements. This is no accident; our design philosophy is that features do not make it into Ice because we think someone may find them useful. Instead, features make it into Ice when we encounter a real shortcoming that cannot reasonably be overcome without new functionality in the platform. This means that everything in the platform exists because it really was needed and that its design and implementation were driven by real (instead of imaginary) requirements. In the few cases where requirements interact with each other, we show you how to deal with them without suffering a blowout in complexity and development cost.

So, check out our new chat demo pages, where you can read about how the application works and get an overview of its design and implementation. If you want more meat, you can read our in-depth article that gives you the complete run-down, and, for even more meat, you can download the source code for the application. Of course, you can also point your browser at our chat server and chat via HTTPS, or use one of the clients to chat via the Ice protocol straight from your machine into our server (securely, of course).

If you do like (or don’t like) what you see, you can let us know: by posting in our forum, by adding comments to this blog entry, or in real time, by chatting in our chat room.

At ZeroC, there are many ways to chat!

Cheers,

Michi.