Application Model, Part 1

As programmers, we participate in an evolving discourse around the tools, languages, platforms, and APIs that we can use. Sometimes this discourse is purely academic or reflects personal preferences; often, though, the goals are broad: higher quality software, developed more efficiently, with more reliable outcomes than what we do today.

But one critical and useful piece of terminology seems to be missing from the conversation. I propose the term 'Application Model' to describe the essential 'shape' of how a basic program would be arranged, given a particular platform, libraries, tools, and possibly even architecture.

One way to think about this is to imagine a full stack, with a non-trivial Hello World program. The non-trivial Hello World program is a basic program that exercises the core purpose of the stack in the way that the stack intends. So, for example, a simple blogging or e-commerce app might serve as the non-trivial Hello World for a web application programming stack. For a big, high-level graphics library (like WPF), maybe rendering Hello World in a specific font, extruding, rotating to an arbitrary angle, and texture mapping with a streaming video source is the non-trivial Hello World.

Now, remove the platform, libraries, etc., and, assuming it's constructed the way the stack intends, look at the shape of what's left -- of the actual Hello World app. That arrangement or shape of the code is the Application Model.

Another way to think about it in general is to consider the set-wise complements of the API/platform/language stack, in a collection of 'typical applications' running on that stack.

The complement will be a little different for each app, but across the collection, a certain shape should emerge at the boundary.

This boundary, the edge between 'app developer' code and 'stuff that app developer code uses' is different from the formal interface mechanisms (linking/loading; object interfaces) because it is shaped by the practices, patterns, and intents of the platform.

Let's describe a few examples in case it's all too abstract so far:

What is the 'application model' for a C app meant to run in a console? A main function where the execution starts, #includes to access additional platform/API/library capabilities, and a routine to set up signal handling. Compile/link/run. Those characteristics make up the application model. From there on out, it's features and "business logic."

How about a COM Win32 raw (non-MFC) C++ app with a little GUI?  Well, that's a lot more complicated. You need the basic WinMain stuff, the GUI and message loop stuff if you want a real window not just a ShowMessage, then you need the OLE/CoInitialize stuff, and the basic COM dance (CoCreateInstance, QueryInterface) to get the COM object you want. Then you can do myObj -> HelloWorld. Compile/link/run. With the bonus that you don't need to link DLLs (including COM objects).

Win32 via .Net and C#? You're back to void just a main function and a couple of using directives. Compile, don't link, run.

Raw J2EE Hello World? not a ton of code, but you need a lookup service for your other services, you need to do lookups, create bindings, and ask for HelloWorld from whatever service(s) you are demo'ing. Reference other code using import and classpath references. Compile, don't link, but put together descriptors, and subpackages, wrap in an EAR file, deploy, possibly configure app server, run.

J2EE using an IoC container and libraries? access other Java code the same way, but a lot of the other steps drop out. Maybe the packaging work is even automated (and requires less inside anyway), depending on which framework and/or appserver you're using.

The idea is that the 'application model' represents (1) the typical development experience on the platform as well as (2) the core knowledge that a developer will need to have or acquire to be productive.

Different combinations of platform, language, and supporting frameworks create different application models -- so it's a matter of comparing entire stacks and looking at the shape of their photographic negative -- that's the space that will be inhabited by developer work.