Architecting for multiple CPUs

There are two popular approaches to building applications that benefit from multiple CPUs:

The application must be written to be multi-threaded.


The application is packaged into small components, and placed in containers that take advantage of multiple CPUs.

You may recognize the first approach as your typical monolithic application, while the second leans towards Service-Oriented Architecture (SOA).

Each approach has it’s advantages and disadvantages. The first approach is popular with developers, as the developer has direct control of the system (whether virtual or not). However, it is less popular with IT Operations because big monolithic applications are harder to manage, and may hog the resources of the system.

In comparison, SOA breaks things down into small lego-sized pieces, and then assembles them together into something useful. This is not a new concept, rather it is as old as the UNIX shell itself. Whenever you use a pipe (|) in the shell, you are effectively taking small programs and connecting them together into something useful. For example:
ls | grep '\.txt' | sort
The component architecture that is used above is the text input and output of the UNIX shell. Because each command depends on the previous command for input, there is little benefit with multiple CPUs. However, programs that take a long time to complete can be assigned a different CPU, resulting in smoother operations.

The potential disadvantage of SOA is that you may end up having multiple pieces, but not a coherent strategy or way of stitching the pieces together. Component architecture and testing is something that should be worked out beforehand. The component architecture defines how these components communicate. Functional tests ensure that each piece behaves as expected. With functional tests, you should know exactly what you’re going to get based on what you put in.

There are other ways to take advantage of multiple CPUs, but the principles are the same. Those are: manage concurrency manually, or break things apart to manageable pieces and let the container (AKA: process, actor, isolate, etc.) manage the CPUs.

Presenting at Toronto Java User Group

Update: I’ve placed the slides from my presentation on Prezi. Example code and PDF is on the Toronto Java User Group site.

I’ll be presenting at the next Toronto Java User Group meeting, on Thursday January 19th 7pm, at the Free Times Cafe (320 College Street).

Here is what I will cover:

Developing for Android using Adobe AIR

1. What is Adobe AIR? (hint: Flash, HTML5, and Native Extensions)
2. Structure of an AIR app
3. Using Flash Builder IDE
4. Using AIR and Flex SDKs
5. Using Native Extensions
6. Developing Native Extensions using Java
7. Questions?

Click here for a map of the location:
Toronto Java User Group

2011: I hardly knew you

So 2011 came and went quickly. There were many challenges and opportunities. Highs and lows for me.

Like many at this time of year, here are my goals for 2012:

Business goals

I plan to move more from service-based consulting to selling software products. This is easier said than done, and may be a longer term goal. Ultimately, companies pay big bucks for results, and results can only be guaranteed by full services. I collated some interesting data that showed that even established companies (in the same field) make 70% of their revenues from services.

I see a symbiotic relationship evolving where the products help push the services and vice-versa. Ofcourse, this means that I have to devote time to both aspects of the business. Time management is going to be critical.

Personal goals

My weight in 2011 fluctuated dramatically (damn you high metabolism). I need to do something to keep my body occupied between long stints behind the keyboard, meetings, and general office dweller lethargy.

I’ve already ran a couple of marathons in the past, so I’m interested in doing something related yet new by competing in a triathalon. Realistically though, I probably won’t have the substantial amount of time to train for a triathalon, so I may have to content myself with the now comforting familiarity of marathon training.

So marathon it is. The difference now is that I’ll start to track my progress. That might give me a fresh perspective. I was never interested in tracking the length of runs, pace, etc. In my mind, the final marathon time was the only number that counted. My best time was 3:21, and I would need to dedicate myself again to break that time.

Another goal is to involve myself in open-source. This would be in such activities as writing, presenting, and in contributing bug reports and source-code. I’ve been doing this in the past, but it somehow ends up for a company that uses the open-source software versus directly to the cause. Gotta go to the source! There are lots of exciting projects. Flex and Backbone.js interest me the most.

OK, that’s it for me. Hope you have an exciting and fruitful 2012.

What is a mobile application?

Through casual conversation, I received a few questions regarding mobile applications. The questions were in essence: what is a mobile application, and how is it different from a regular web application?

There are many definitions. Most definitions associate mobile with devices, but I think that misses the point. People are mobile, not necessarily devices.
My definition of a mobile application is, to put it as simply as possible: an application that a person can use anywhere. A person is mobile and is not limited to one place or device. A person may seamlessly switch between a notebook computer at their desk, to a tablet while reclining on a sofa, and to a phone while in transit.

Based on that definition, the criteria for a mobile application is as follows:
1. The mobile application must be available where a person is and on multiple devices (computer, tablet or phone).
2. Network connectivity may be lost temporarily. The mobile application should make provisions for this, and continue functioning without interrupting the person.
3. The mobile application should notify the person of important events or status updates.
4. The mobile application should seamlessly synchronize the data between the devices.

Many social applications such as Twitter and Google+ are also mobile applications. Another popular mobile application is Google’s mail application Gmail. What makes it a mobile application? Gmail can be accessed from a web browser, but can also be installed as an application on a phone or tablet. The application provides additional features that are not found on the web-only version.

So how do common web applications fit it? Some web applications are functional mobile applications with some limitations, but some do not meet even a single criteria outlined above.

At the very least, a web application should meet the first criteria and work on all devices. Careful consideration needs to be taken for web applications to support all web browsers on computers, tablets and phones. In particular, phones have much smaller screens, requiring specialized user interface design.

Many web applications fail if the network is not available, limiting their usefulness for people on the go. Mobile applications, on the other hand, may store data locally on the device in a secure manner, thereby allowing continuous uninterrupted use.

Notification in web applications is provided separately by e-mail. This is cumbersome as it requires switching between the e-mail client and the web browser. This can also be a security risk as e-mails can be faked easily. In comparison, notification is an area that mobile applications handle in an integrated and secure manner.

There is a growing trend towards complete integrated solutions (mobile applications) and movement away from tools (web browser and e-mail). This is being driven by customers who are using social mobile applications, and recognize the ease of use and other benefits that mobile applications deliver.

Focus On Mobile Applications

“When one door closes another door opens; but we so often look so long and so regretfully upon the closed door, that we do not see the ones which open for us.” – Alexander Graham Bell

With all the busy and loud commotion around the discontinuation of Flash on the mobile browser, another message is not being heard:
Adobe AIR 3 is better than ever for building mobile applications with Flash, Flex, HTML5, PDF, and native code. The major new addition is Adobe Native Extensions. This allows the creation of uncompromising full-featured, fast, and flexible mobile applications.

Before the introduction of Adobe Native Extensions, AIR applications were limited to the sandbox, with no additional capability beyond what was provided by Adobe. The door is now wide open–you can now mix additional functionality within your AIR applications.

Java developers may be familiar with this concept. The Java Virtual Machine allows native code by way of the Java Native Interface (JNI).

In addition to supporting native C or C++ code, an API is available for mixing Java code on the Android platform. This should make it easier for Java developers working on Android.

There are three main scenerios where native code would be beneficial:
1. To access native platform features as soon as they become available, without waiting for Adobe to provide the support. For example: using the new notification API in iOS 5.

2. To extend the AIR runtime. A clear example is spawning multiple threads for long-running tasks.

3. Performance. Native code will almost always run faster than interpreted or byte-code. Custom sound filters and image processing are strong candidates for the use of native code.

Adobe seems committed to this strategy. They are eating their own dog food. The new Adobe touch-based applications are built using AIR and Native Extensions. For an example of this, look for Adobe Photoshop Touch and Adobe Ideas on the Android Market.

The key to moving forward is a vibrant community and catalog of ready-to-use native extensions. There are already a few interesting projects contibuted by the community. I’ll add some links in subsequent posts.

Of course, there are other frameworks such as PhoneGap for creating portable mobile applications. However, they are all limited to some extent. Adobe AIR is heavy duty in comparison. Competition is good. I’d like to see Oracle release a JVM for Android and iOS, but even then it will take a while to mature.

There has never been a better time to create mobile applications. Using AIR or a similar framework will get you there faster.