During the week of April 6^th to 9^th, I had the good pleasure to attend AnDevCon or the Android Developer Conference. I will be sharing my experiences at this event in my next few postings.

This was the first ever AnDevCon so if you missed it, don’t worry; there will be one coming in November. The event was held at the San Mateo Marriott very close to San Francisco airport. The actual event started on the 7th as a whole day workshop where the attendees could choose a subject that was of particular interest to them and intently focus on it. The one I attended was, “Android for Java Developers” and the speaker was Marko Gargenta from Marakana. The workshop covered some of the challenges that Java developers have to overcome to program successfully on the Android platform. In addition, Marko briefly covered the Android stack (kernel, davik, Android System Server, etc.).

The workshop was very informative though much of what was covered was available for folks by coding the tutorials that are in the SDK. Since the discussion was so broad, the scope sometimes went into the weeds but by and large stayed on topic. The attendee’s skill level varied greatly from raw beginners to folks who had published apps. Most of the discussion in the workshop followed Marko’s new book, “Learning Android”; so if you downloaded the book from O’Reily (I did), you could review the topics.

I’ll cover the first full day of classes in my next post.

Several projects that I have seen while supporting ORBexpress have implemented a fairly complex processing architecture and still easily met stringent performance requirements. One commonality among these successful projects is that they identified and addressed architectural risks early on in the process.

Lots of projects, influenced by the "waterfall" development model, don't try to run any of their pieces together until all or most of the pieces have been developed. In the ensuing integration nightmare, new requirements are discovered and design flaws are uncovered -- with no time left to deal with them. In particular, performance bottlenecks or unexpected error paths are discovered only at this late stage…or in the words of Homer Simpson, D’OH.

Unlike the sitcom character, you can avoid this experience. To help ensure a smooth development that meets their proposed schedule, smarter projects develop a "skeleton" of the system early in the project. These can have many forms, but generally include all of the major components present, as token "stubs", and exercise all of the major data flow paths with "dummy data". The closer this “skeleton” is to the production processing environment, the better, but compromises are often necessary. The target hardware may not be available, the target operating system may not be easy to test on, or the communications infrastructure may be missing.

CORBA can help in all of these situations. It offers a degree of transparency that allows different processing hardware, different operating systems, and different communications to be used in the initial architectural prototype. For example, many ORBexpress users prototype their system on a standalone Windows or Linux machine, and then gradually move each component to their actual target operating system. The location transparency of ORBexpress makes it easy for developers to do this.

Performance is another aspect that can be explored and verified with a prototype using ORBexpress. The initial prototype can validate that sufficient bandwidth exists in the infrastructure, that sufficient feedback is present to handle congestion, and that fan-in and fan-out points don't introduce excessive latency. As the implementation proceeds, stubs and dummy data can gradually be replaced by more complete data representations and realistic processing algorithms.

Finally, an architectural prototype gives you something to show the customer. Customers are much more assured by a lash-up that just "blinks the lights" than all the progress charts showing thousands of lines of code you have developed to date. Incremental progress can be demonstrated by blinking the lights in ever more sophisticated patterns.

It is important that projects port the prototype skeleton to the actual target as it becomes available, since the benefit of transparency may hide real issues in the architecture. For example, calls on a single system never fail due to unavailability of the called subsystem -- the caller would also have failed! Thus these error paths cannot be discovered or exercised after discovery.

Projects that start with a skeletal architectural prototype have the opportunity to explore performance, reliability, and platform-application integration issues at an early stage of the project before a significant part of the application is developed. If the "bones" are strong and well connected, the application will be more robust when it is "fleshed out".

Once again, ORBexpress has been picked as the ORB of choice for advanced, next generation radios and waveforms. We announced today that ITT Electronics Systems chose ORBexpress for its next generation software defined radios.

The JTRS program picked ITT to develop and build the Soldier Radio Waveform (SRW). This is an incredibly strategic piece in the US DoD's efforts to build a next generation mobile and adaptive communications network. The SRW will be used in hundreds of thousands of radios built by a lot of different companies. It massively advances the state-of-the-art on a number of different levels, including a two orders of magnitude improvement in throughput as well as dynamic, ad-hoc networking.

ITT also developed and built three different radios conforming to the JTRS radio specfication, the SCA. Their Rifleman Radio is a lightweight body-worn radio that lets Marines that have left their vehicles communicate with each other and their surrounding vehicles (even unmanned vehicles!). Their Soldier Radio lets soldiers do everything from simple push-to-talk communications to networked data communications. Their SideHat radio enables legacy SINCGARS radios to take advantage of these new networks buy adding a JTRS-compliant second channel to the ITT SINCGARS radios that are already used on more than 100 different vehicle platforms.

All of this was done by ITT with a laser-like focus on producing these radios in very small form factors. ITT was able to meet their goal by using the small footprint, high throughput performance of ORBexpress while taking advantage of our quick and responsive support. Kudos to ITT for a job well done (and kudos to our development and support engineers).

Whenever I talk with my customers on the phone, at their site, or trade shows, sooner or later the discussion turns to “CORBA overhead” and what are we doing about it? Dig a little deeper and their real concern is some facet of message latency.  How many messages can their application send in some period of time? Or the time it takes to send a single message, or the order and reliability of message processing.

Many factors contribute to message latency. The usual suspects being; application architecture, third party libraries, operating systems, and network protocols.  As a middleware for distributed inter-process communication, CORBA provides an abstraction layer that protects developers from many of these criminal elements.  While this abstraction allows developers to build features instead of infrastructure, it also causes CORBA overhead to get blamed for their bad behavior.

Over the course of my next few posts, I’ll explore each of these shady characters in more detail. Discussing their roles, interactions, and trade-offs, hopefully helping you to identify which suspect to squeeze to improve message latency.

Charlie

Welcome to Middleware Matters, OIS's blog on all things about communications middleware. We plan to use this blog to communicate our thoughts about communications middleware, and some insights in particular to ORBexpress. We'll be letting you know about product announcements, product updates and upgrades, peformance optimization techniques and a whole host of other subjects.

We hope you find our blog useful, informative and entertaining. Please let us know your ideas, thoughts and reactions at OISblog@ois.com. We look forward to hearing from you!