Software architecture is a subset of system architecture. Software architecture concerns itself with the internal and external manifestations of a program. System architecture concerns itself with the GIS software, the hardware, any external databases, and the people who build, maintain, and use these systems. An example of a good system architecture problem would be considering the costs and trade-offs with adopting an "Enterprise" GIS system. (In my mind, an "Enterprise" GIS is one that allows for distributed editing of spatial data; if you have a different view, please comment at the bottom of this page).
System architecture is a broad topic; in many ways it is the overall subject of this course. Doing needs assessment, creating designs, and analyzing available solutions are all means of doing systems analysis. Database, programming language, and open source choices will all dramatically affect which software architecture is appropriate as well. We focus more on the sub-topic of software architectures in this lesson. However, please keep in mind the ways that the other systems architecture issues affect software architecture.
Major Components of GIS Software Architecture
Most of you are quite familiar with GIS architecture, having worked with it daily for years. Others of you may have had your first hands-on exposure to GIS through the MGIS program courses. Either way, you have had substantial engagement with GIS architectures for a while. Therefore, we will not spend much time on the basics, but skim over the major components here. A GIS can be thought of as having three main sets of components: 1. Data Store Components 2. Analysis Components 3. Presentation Components. The data store is at the foundation of the GIS (the INFO in ArcInfo was originally Esri's in-house database, for example). Choosing the database and how it is structured is a huge part of GIS design. Analysis components are all the things that happen between reading the records from the database and having everything rendered to screen. Every computer program has an implicit or explicit model realized in how it encodes and manipulates data. A GIS should have a rich spatial data model (and increasingly, a rich temporal model). Finally, the presentation portion is critically important as well. If you can't provide information to users, available as maps and other data graphics, all the database and analysis components are useless. And, with the advent of web mapping, presentation technologies have taken an interesting new turn.
SOAP vs REST
Here we are going to take a look at a current debate in information architectures in general, and in GIS in particular: SOAP vs. REST. SOAP stands for simple object access protocol, wherein computers can call methods on other computers, defined by XML documents. Both .Net and Java are heavy SOA creators and users for inter-machine processes, also called web services. REST stands for REpresentational State Transfer, and it takes a very different approach to inter-machine coordination: it recommends exposing the data over HTTP, and then allowing clients to use the regular HTTP verbs (GET and POST mainly) to access the data.
One way to think about the difference is that SOA is a verb based approach (it specifies what to do) and REST is more of a noun based approach (it shares some specific things). The advantage of SOA is that the communication is well-specified, and with the right tools, it can be fairly easy to set up. The disadvantages are that there is a performance cost, and any changes need to be coordinated across machines. REST is simpler at the machine level (no XML or heavy object orientation), and it can leverage all the things that make the Internet scale.
Please review the slides titled "SOAP vs. REST: Complements or Competitors?" which can be found in the Lesson 5 Module in Canvas. It was the keynote talk at the 2009 Esri developer summit. It provides a good introduction to the two technologies, and what is appealing about each.