Applications & Distributed Computing - Review

Types Of Applications

Applications come in all kinds of flavors and levels of use. Here are some primary ones, some features, etc.

Operating Systems

AKA: ‘OS’. These are programs that manage a piece of hardware, either a PC, and large university mainframe, or a cellular phone. These programs act as “managers” for the device (not all of these apply all the time):

An OS controls access by users, by asking for a username/password (any code can do this, it’s just that OS’s are the most common we encounter);

They provide access to system resources: disk drives, network, phone line, speaker, etc.

They provide access to system/user applications

They provide the administration back-bone to the system administrator, like tools, databases, error logs, etc.

OS’s can be very simple or very complex, but they all manage the hardware. God OS’s have qualities like not-crashing, providing clean interfaces to users, administrators, and developers. They also are behind-the-scenes – you shouldn’t know they exist based on the system behavior.

User-Apps

User Applications wer written for use by a user of the system, and they provide some specific functionality (purpose). For exmaple, Word for Windows, Notepad, Excel, Internet Explorer, cp, rn, cvs, diff, etc. These are either bought or are free.

Servers

I make this a separate category for the following reason: They run in the background, and they don’t manage the machine. Servers are applications that “wait” for a reason to do something (like a waitor in a restaurant.) They have to be asked to do something, otherwise they sit idle. They provide any possibel service to the “client” (customer.)

Application Domains

Application Domains is a classification of user-applications. This is a way of saying what the application does. Certain segments of the computer-user community will be intersted in one or more of these kinds of software.

Development Tools

These are applications used by people developing some part of a system: they could be creating any of the types of applications mentioned above. These applications allow creating applications, customizing existing applications, or testing the system for performance, usage, statistics, etc. Examples include tools in the JDK, Borland C++, a BASIC compiler.

Document Management

These applications allow the editing of user-viewable documents. For example, Word, Excel, a web page editing package, etc.

Modeling and Simulation

These applications allow people to create virtual systems and test them. These systems can model most anything: bridges, airplanes, economics, the fashion industry, optimal class sizes for high schools, which types of people to target for recruitment into the CIA, anything!

So this brings up another use of the word “domain” – the field of study of the M&S application. Is the domain named “static structures”, “fluid mechanics of flight”, “human behavior in jobs and shopping centers” or “human behavior in current societal trends” (an attempt to generalize the M&S examples in the previous paragraph)?

Modeling and Simulation applications can be specific to a field domain, or general. People can use these to create scripts that look at specific types of situations, like electronic digital circuitry, military battles, how liquids mix, etc.

Analysis Tools

These are applications that allow people to compare data, or look for trends based on some algorithm, or display data. These are usually specialized to take adavntage of some theoretical basis, or process. Some analysis tools are general, and offer a script-type language for creating specialized applications that perform a specific kind of analysis. All fields of science use these applications.

Distributed Computing

Distributed computing applies to any Application Domain that operates (as requirement or option) on more than one machine. There are two types of distibuted computing: synchonous (serial) or asynchronous (parallel).

Serial computing is basically a regular application that’s distributed so that it can be accessed from various locations. Examples of this are most web sites, cvs, etc. These applications can be any kind of user type – user management, documentation, server administration, web sites, business-to-business transactions (B2B), etc.

Parallel Computing is a much harder problem. This is taking a particular task, and breaking it into chunks that can run at the same time. After the last of the chunks finishes, the results are compiled and used. This is meant to make things faster but requires a lot of upfront work to break the system up into chunks. These tend to be math-intensive programs, operating on large matrices, etc. Examples of this are weather models, fluid dynamics, etc.

Protocol

Getting distributed systems to work is not necessarily a hard problem. The problem comes in when two entities (businesses, schools, etc) want to hook up their systems together, but they use different machine types or OS’s. Machines treat data differently. This leads to the issue of “protocol”.

By protocol I mean “the standard format of the communication.” Human language is a great example of this. If a English-speaking person and a French-speaking person talk “at” each other, neither understands the other, and nothing gets communicated. In order for them to understand, one has to speak the other’s language (and accents aren’t allowed!) The language of choice, whether English or French, is “the protocol.” Success of the communications is defined by the same language chioce, same vocabulary, and same context/semantics.

Machines have many protocols to choose from (due to loading development/tool applications on the system) and each has it’s uses (pros/cons.) Now there really are 3 types of protocols that have to chosen between two systems before they can talk. Hardware, Byte Data, and semantics.

Hardware Protocol - The hardware chosen for the comminucations must match in some way, or atleast be patched together to they make sense. (This is the “medium” of human communictations, ie. face-to-face, over the phone, etc.) This boils down to having pathways of conductivity for electircal signals. Issues that come along with this are: transmission distance, minimum bend radius, number of conductors, voltage levels for each conductor, etc. Examples of hardware protocols are “RS-232”, “RG-6”, “GPIB” (also fiber-optics!)

Byte Data Protocol - Once the hardware has been selected and the machines are physically connected, the communication rules must be combined into a specification for use by developers. (the “etiquete” of human communictations, ie. “I promise I won’t yell at you if you address me nicely”) This set of rules represents a “handshake” – if you’re a client, and I’m the server, I expect you to send me some bytes, in effect waking me up to you, and then I can determine from those bytes if you want me to respond. When I respond, then you can continue. This is an example of a software handshake. There can be hardware handshakes, but we won’t go into those. Examples of this are “TCP/IP” and “DCE-RPC.” Amino uses TCP/IP for this level – this is due to the usage of the internet.

Semantic Protocol – This protocol defines the set of bytes (the “language” of human communictations, ie. French or English.) Examples of this are “CORBA IIOP”, “Java RMI”, and “GSS-API.” Amino primarily uses CORBA (IIOP) for the distributed communications.

Mechanics Of Application Architectures

Architecture in software engineering means the same thing as architecture in buildings. There is a foundation, user-interfaces, beautiful structures, elegance, efficiency, and trade-offs. There are different systems of resources that must coexist in harmony, and emergencies have to be serviced. And by all means there must be maintenance!

Software Architecture is the combining of many systems, technologies, and procedures into a usable system that performs a specific set of tasks.

Let’s present a hypothetical layered architecture diagram:

Figure 1 Generic 3-tier Architecture

In the above diagram, we have three layers: User Interface (aka “UI”, or “GUI” for windowing applications), System Services, OS Resources.

UI – this represnts the user-view of the system: is a command-line syste, or is a window application? Does the system present a prompt, or do windows and menus pop-up? The user is presented with things/text/buttons that make sense, and they have a limited number of permutations before actions become replicated over-and-over. Examples include “file menu with an import”, “button for stepping a motor in a direction/speed”, and “analyze selected data.”

Domain Services – This layer presents the Domain actions that can be performed. These actions don’t necessarily make sense by them selves. Examples include “import a text file”, “move the drive motor into forward, speed of 15”, and “determine the trend of user activity over the last X days.”

OS Resources are things like opening a file, sending bytes to a data acquisition card in the computer, or performing a matrix inversion using a built-in OS library.

Now let’s make this example more specific:

Figure 2 Fundamental Amino Architecture

The above diagram goes the next step in terms of specifying specific technologies, libraries, and “middleware” – middleware is basically the CORBA package.

So, you see, we can specify the sytem at various levels of detail, that is various levels of “fidelity” (this is where the term “HI-FI” came from in the old days – the introduction of newer, “high-fidelity” record players.) Figure 1 Generic 3-tier Architecture is at a lower fidelity than Figure 2 Fundamental Amino Architecture. But Figure 2 Fundamental Amino Architecture incorporates both hardware and software into the layers. There can be layered architectures that have only hardware, or only software, and they present different “views” of the system – kind of like looking at a clear cube, and seeing different things when you look at each side separately, though you’re still looking at the same thing in all cases.

The following diagram presents the architecture of the CORBA middleware:

Figure 3 CORBA Conceptual Architecture

This diagram is more abstract that Figure 2 Fundamental Amino Architecture. Here, we represent two fictitous processes, say one client in France, and a server in the USA, communicating over the internet. The protocol of choice is CORBA IIOP (of TCP/IP.) The blob called “CORBA ORB” is a conceptual entity – there isn’t really anthing actually reaching through the wires from France to USA and connecting the two machines or users together. This is a “representation of their relationship” – the fact that they share a protocol. It’s kind of like when two twins live across the country – they’re connected by their history together, their family ties, and once in awhile they call each other up. They share a common bond, that may exist on many levels. But they’re connected. In CORBA, objects are connected by the protocol they agree to use, their semantics (like being part of a financial software package), and a TCP/IP socket that once in awhile may come down because someone cut the wires with a backhoe (this actually happened on a project I worked on!)

Sometimes it is desireable to “not care” whether an object is “on some remote machine.” The ideal situation is that you get a reference to an object, and you can call methods on it, and the use the return data. You don’t care that you made a remote call, or read from a file vs. reading from a database, or even that you ran an algorithm written in a different language. All you care about is that the work got done. Amino strives to accomplish this transparency through the use of patterns like Factories & Builders, and system/language-independent interfaces using CORBA.

Amino Home

Last revised: Mar 10, 2003