Our Pattern Language

This paper describes a pattern language for parallel programming. The authors first make the point that the software industry must change from a sequential to a parallel approach in order to accommodate the increasing shift to parallel processors. This change does not affect all the programmers equally. Low level programmers, who works at the hardware- software interface needs to master parallel programming, while application programmers only need to be weakly aware of it. I found surprising that they mentioned that application programmers may have little background in computer science, specially knowing that a vast majority of computer science graduate work as application programmer.

The benefits of grouping the patterns into a language is that it gives parallel software architects a conceptual framework that help them organize their understanding of the problem and guide them from the beginning of a design to its realization on a real hardware.
As mentioned in the paper I think some of the computational patterns may even be whole pattern languages of their own. I take the example of Graph algorithms. Graph theory is a large area of computer science and there are many different problems that can be solved using some class of graph algorithms. I do not think that they can all be described in one pattern. There need to be pattern for each of the known graph problem, for which there is a solution that expert takes for granted.

I will really be interested in the Data Locality pattern. I took a class in computer architecture and realized our difficult it is to design cache coherence protocol in multicore systems. I think this is one of the major tasks that low level software for multi-processor platforms must handle. Depending on the underlying cache coherence protocol, the low level software must be implemented appropriately to avoid trashing the caches. In single processor systems, it is very easy to figure out where a line of memory is. It is either in memory, in L1 or L2 cache for systems with 2 levels of caches. I a system with multiple processors, the line can be in any processor's L1/L2 cache or in memory.

Metacircular virtual machines: Jikes BA ch 10

This paper presents another example of a system that emphasizes the advantages of using a single language for runtime and implementation of the system. Jikes is a VM developed completely in java to run java applications. The author describes the component of the system after first presenting the concept of self-hosting, which is writing a programming language in its own language.

The author argues that using java to write the components had many advantages. I completely agree that using Java’s collection simplifies the development by allowing the components to focus on their roles. It is a great advantage of Java compared to languages likes C where the programmer needs to take care of managing the underlying data structure and memory.

Jikes has its own threading model because there was a lack of threading support in operating system when it was developed. To the question of knowing if it was a good choice? I think they did not have any choice. There was no support for threading so they had to develop one. This has advantage because it allowed them to adapt the threading model to the need of the system allowing them to run many threads. The only downside as mentioned in the chapter is that it can have some undesirable performance problems because the OS does not know about the JVM managing threads.

The Adaptive Object Model Architectural Style

This Paper presents Adaptive Object-model (AOM), which are considered as a more flexible alternative to the conventional object-oriented design (OOD). Some nice examples along with advantages and disadvantages of AOM are presented. In AOM system, the object model is stored in a database and the system interprets it. AOM systems do not model the system based on the classes and their attributes and methods, but represent them as metadata, which are interpreted and translated to dictate the system’s behavior. So changing the application does not require changing the code, but the metadata. I think this is a very good feature compared to OOD systems where changing an application require changing the code and releasing a new version of the application.

The system is adaptable to changes, because any changes in the metadata are immediately interpreted and reflected in the running application.
This architectural style is very interesting and great for system where flexibility and dynamic runtime configuration are important. I never work on a large scale system requiring these characteristics, but I did a class project a couple of years ago, where a GUI was developed to read, interpret and display the products and the prices stored in a database. I am not sure if that was an AOM system, but it was very cool to see the system automatically changed whenever there was a change in the database.

I understand that Architects of AOM are very proud of their system. Who will not be proud to architect a system that adapt to modifications without requiring code changes? I think the AOM architectural style has a very interesting concept and provide a great solution. The author mentions that developers who have to use and maintain these systems usually find them hard to understand and do not think they are that great. Maybe this is an example where the architectural concept is great, but the implementation is not as great. I don’t have experience with these systems and I do not understand why this is the case. Maybe some folks with experience using AOM system can tell us why they are hard to maintain.

Among the examples provided, I especially like the User-Defined Product framework (UDP). It shows how an AOM architectural style can be used to allow users to construct new kind of components or various complex business objects from existing components without any code change.

JPC: an x86 PC emulator in pure Java BA ch 9

This chapter describes the architecture of an x86 pc emulator written in Java. The authors first give the motivation of developing the emulator despite the existence of emulators like QEMU and Bochs. They argued that those emulators have some security holes and need to be recompiled in order to run on a new host system. They also described why they choose an emulator instead of a VM. VMs need some degree of hardware support while Emulators are written completely in software and do not need any specific support from the underlying hardware. The emulator runs just like a normal application running on the computer and is therefore the most stable and secure way of creating virtual machines. Given these facts the authors decided to build as emulator in the JVM, which provides guaranteed security and performs good enough to stay practical.

After making the case for developing the JPC the authors focused on the most challenging aspect of emulation, which is dealing with performance. Applications running on the emulated machine incur significant software emulation overhead at runtime. So it was critical for JPC to deal and reduce the overhead of emulation. The authors took a very discipline approach and considered a series of performance tips in their architecture. I believe their approach to incorporating optimizations wherever it had a positive impact was very successful and is the right approach. Being able to boot a virtual DOS and run games within a secure JVM running on any machine is quite impressive.

I like the steps that the followed and presented at the end of the chapter as being the steps to a beautiful architecture. They focused on limited end-to-end prototyping of the complete system rather than prototyping components of the final product. This had the advantage that it allowed more flexibility and allowed to prove the concept before engaging in large scale work. This approach is unfortunately not always possible in commercial settings, where people do not have the luxury of getting paid for writing throwaway code. For an academic setting or for research teams at companies this is definitely a great recipe for creating beautiful architectures.

Guardian: a fault-tolerant operating system BA ch 8

Guardian is an operating system that was designed to work with the hardware to provide fault tolerance with minimum overhead. The author first describes the main idea behind building fault tolerant systems. The design was centered on the idea of avoiding a single point of failure. Failures should be contained and not cause the entire system to fail. This was achieved by using redundant components to provide continuous operation in case of a component failure. The system has at least 2 CPUs, 2 busses, as well as duplicated I/O and storage components. The downside of this approach as acknowledged by the author is the cost. Duplicating hardware components will almost double the cost of the system.

The operating system was designed to work with the duplicated hardware components. The OS manages the system and transfers the load if it detects a component’s failure. For example if a CPU fails, it is stopped and the load is transferred to the other CPU without system downtime. Depending on the type of failure, the OS either recover from it or the failing component is replaced. The system offered some cool features like the “nonstop” function, which is the ability to remove and replace components without turning off the system. This is very desirable and important feature especially in server environments, where reliability and availability are critical. So, the Tandem platform offered similar features as some of the most powerful and expensive servers in the world like IBM mainframes. If we take that into account, we can say that the high cost of the Tandem system shouldn’t have been a major issue if it offered features that conventional systems could not.
One aspect of their solution that I don’t like is check-pointing. It uses CPU cycles and the author mentioned that it is left to the programmer to decide when and how much data to checkpoint. I am not sure if that is easily feasible. It requires the programmer to have an in-depth knowledge of the system in order to take appropriate checkpoints.

BIG BALL OF MUD

This paper is definitely the most interesting of the papers I have read so far in this class. All the points made in the paper are very applicable to many of the projects I worked on. big ball of mud systems are unstructured, with no clear defined architecture style. It typically has many code smells like, duplicated code, spaghetti code. These systems evolve over time with no formal architecture, with various people working on it and making fixes just to keep the system running. From my experience there many reasons that impact the quality of the software: Ever changing requirements, cost and aggressive schedules are usual characteristics of many software projects. People do not have the time and the money to invest on good architectures and therefore big ball of mud are created. It is very interesting that the authors document this kind of systems. They explain why this kind of architecture is so popular. Among the forces behind theses systems are the cost of architecture and the skills of programmers. The authors explain in the patterns how the programmer maintaining the messy code should learn to understand how it evolved, what it does, and how to improve it.
I like this quote:
“Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control”
This is such an important statement. If it is hard to understand, restructure and make changes to a system, it is important to stop the system from getting even worse. This should be done by correctly planning and structuring any new addition to the system so that the mess can be restricted to a fixed area

I have worked on a legacy system that was first developed about 30 years ago. Most of the senior members on the project started with horizontal microcode, then change the project over the years to use C and C++. The code is messy because of the thousands of patches and new functionalities that have been added over the years to keep the system running and provide new value to customers. Working in that environment I realize how many factors influence the quality of a system and how important it is to try to understand theses system as described in this paper.

Xen and the beauty of virtualization BA ch 7

This chapter presents one of the hottest topics in information technology. Virtualization is increasingly becoming critical in today’s infrastructure because of its economic benefits and the features like isolation and security. Xen is an open source virtual machine monitor that allows multiples guess operating system to concurrently run on the same computer hardware under the supervision of the hypervisor.
One of the major challenge in architecting virtual machine monitors is to figure out how to executive privileged instructions in guess Operating system. This is because the hypervisor runs in the most privileged mode and the guess Os in lower privileged levels. In some systems, executing an instruction at an inappropriate privileged level causes an exception that the hypervisor can trap. However, this is not always possible because some system do not generate the exception.
Before Xen this issue was addressed by rewriting the OS code at runtime and replacing privileged instructions by direct calls to the hypervisor. The advantage of that approach is that The guess OS can run unmodified because emulation makes the virtual machine looks exactly the same as the physical hardware.
Xen introduced a new idea called paravirtualization, which presents an interface to the virtual machine that is not identical to the physical machine. The features of a machine that are hard to virtualize are replaced with hooks that allow the guess and the Host OS to communicate in executing the instruction. Paravirtualization remove the overhead of runtime code rewriting and emulation and can also allow some instruction to be executed directly by the guess OS. The only problem is that Guess OS need to be modified to support the paravirtualized architecture.

Xen’s architects designed the hypervisor to be a simple small layer between the hardware and the guess Operating systems, responsible for managing the hardware and scheduling Guess’s tasks and ensuring that each guess get a fair share of the hardware time. So to reduce complexity and the risk of damaging the whole system, most of the management functions are not done in the hypervisor, but at domain 0.

With the increasing use and importance of virtualization, most processor manufacturers are now providing virtualization support in their platform to allow unmodified guess operating systems to run on the hypervisor. The hardware is changed to notify the hypervisor each time a privileged instruction is executed. Latest version of Xen added support for these hardware virtual machines. The author makes the point that Xen was able to quickly provide this support because of its open source status. Developers from Intel and AMD helped write the low level code needed to supports the new CPU and Xen also used other open source projects like QEMU for device emulation. This is an example of some of the advantages of open source.

Layered Architectures

The Layered architectural pattern describes the widely used principle of decomposing a complex task into a number of subtasks. Almost any development team and organization where I have worked claimed to use this principle in their developments. Most classes or books on software engineering emphasize the notion of decomposing systems into layers and defining interfaces between them. So, when I saw the name “layered architecture” my first impression was that it is a basic and fundamental concept. When I started reading the pattern I found very interesting that the authors mentioned at the beginning that most systems that people claim to use layered architectures are either a collection of multiples architectural styles or just some collection of cooperating components without clear boundaries. In this pattern the author attempts to give a more rigorous definition and properties of corrects layered architectures.

Some of the important ideas to keep in mind when designing a layered architecture includes: localizing changes to one part of the system, cohesion within components and loose coupling between unrelated components, avoid crossing too many components, reusable parts and parts that can be exchanged by different implementations without affecting other layers. The multiple obvious advantages of this approach are presented by the authors. I liked that they also gave some disadvantage of the solution. I believe layered architectures are great to tackle complexity in large complex system, but they add unnecessary complexity to simple systems. For example there is a lot of overhead if the lower layers need to perform expensive tasks not needed by the upper layers. Even though this is considered good software engineering practices, it should be determined just as with any other pattern if layered architecture is a good solution for the problem before using it.

Data Grows Up (Facebook) BA ch 6

This chapter has a significant number of details about the Facebook system. It is more like a low level design to me. I got lost many times trying to understand all the details. The author explains the design decisions made and the rational behind them. Facebook was initially conceived as a social website where a user request causes data to be fetched, transformed and displayed. The platform was then extended to include other web services, a query language and a data-driven markup language (FBML) that allows outside applications to incorporate facebook’s data into their system. This feature is very helpful to other applications because it allows them to use valuable information already on facebook.
To guarantee user’s privacy, not all data are available through the data services. External applications do not have access to some data that facebook make available to the user.
I found very interesting the way the data-driven markup language is interpreted by facebook. Basically the external applications are some sort of data services providing the content to be displayed. Facebook interprets the FBML and displays the content provided by the application without violating the privacy of the user.

This chapter illustrates how an architecture can evolve from a simple social web page to a powerful platform with various other features. Each new change caused architects to change the system using even more powerful design decisions to add the features while keeping the fundamental requirements of data privacy and site experience integrity. So scalability is very critical to this architecture. Given the large number of people using facebook today, I am pretty sure that changes are ongoing and will continue on this architecture to provides new features

Pipes and Filters

The Pipes and filters pattern is very popular and widely used. It is almost a common sense idea to divide a large processing task into small sequences of independent steps and have some kind of connection between them. This is exactly what this pattern does: the processing steps are encapsulated into filters components and they are connected by pipes.
I have used this architectural pattern in an I/O project at work. The work involved moving data from a server’s memory to storage devices on a fiber channel network under the control of an adapter firmware. The task consisted of fetching the I/O request from the server’s memory, interpreting the request, fetching the data, computing and verifying a checksum on the data, then setting up DMA engines to send the data over the fibre channel network. We used the pattern to divide the task into several sequential processing steps. The work of each filter was isolated from the other components and this was a major advantage this year when we decided to use multiple threads on the system.

Resource-oriented architectures: BA ch 5

The chapter begins with an embarrassing fact that many organizations face today. It is very common for employees and internal users to search for their own information using the web even when there are internal search engines. Maybe it is just because we are so dependent on web that we are very quick on turning to it when we are looking for information. The sad true is that, most of the times this is not because of the Google’s dependency, but it just because it is easier to find information on the web than it is to find information internally. This is primarily because organizations focus more on the software and services and underemphasize the data. So the author makes the point that organization should focus more on finding ways to manage and reuse their data.

The paper defines resource-oriented architecture and all its advantages. ROA use logical names for named resources. This approach does not leak implementation details and provide a clear separation of the resources from the URL. The logical request is sent to a resource-oriented engine, which interprets it and turned it into a physical representation of the resource. That way, resources can be migrated and backend implementation changed without affecting the clients. Among other important properties of the ROA design choice are scalability, caching, and a focus on information.

I think there is a big advantage in putting data at the forefront. Making data available and easily accessible allows the backend system to cache results and make changes without affecting the clients. However, I am not sure how practical this can be in the real world. Many systems are based on the technologies described in this chapter as conventional web services or software centric architectures. It is will take a significant effort and will be very disruptive to change existing designs to ROA. Maybe ROA can be attractive for large organizations with massive amount of data that should be organized and decouple from clients to make them easily manageable and accessible internally.

Excerpts from Christopher Alexander One Two Three

The author starts in chapter one by making many analogies to explain that complex things in the world do not just happen. In other words, we cannot suddenly give birth to something gigantic without explanations. Those things can only be generated by a process. After that, the authors talks about buildings and the process of their construction.
He describes in a very interesting and simple way how the process of building is just a collection of patterns that give builders the ability to combine them to create an infinite variety of buildings.

We can clearly see how this applies to software architecture. In architecting a system, the architect uses patterns, which are things that repeat. That is he does not invent or suddenly give birth to the architecture of the system, but uses known best practices and solutions to similar problems as references while building the new architecture. Those known best practices and solutions can be combined and arranged into different ways to form various new architectures. So the architect makes the appropriate use of the patterns to produce the new architecture.

The notion of having a pattern language is also very interesting because we can think of the collection of patterns as a set of words in a language. To support that the author makes the analogy that ordinary languages give us the power to create an infinite variety of sentences. So if we think in theme of software architecture we can say that the pattern language gives architects the power to create a variety of architectures.

ArchJava

This paper attempts to solve a very relevant and important problem. It is critical to correctly architect a system, but even more critical to implement a system that complies with its architecture. What is the point of making a great architecture if the implementation does not follow it? I cannot count how many times I discussed with my colleagues about violations of architecture that are a direct consequence of the separation of the architecture from the implementation. Even when inconsistencies are found between the implementation and the architecture, both are updated separately leaving room for inconsistencies. ArchJava presents a very interesting idea that unifies implementation and the architecture to ensure that the implementation conforms to the architecture.

I really like the section about ensuring communication integrity among the components. I think that is one of the most common violation. It is very easy to add calls to methods from different components without making sure it is allowed by the architecture. It is a great feature to be able to detect any such communication integrity violation and decide if the architecture should be updated or the dependency removed. The author pointed out the limitation in detecting the communication violation because they considered only methods calls. I believe it is not a big deal for many java applications because method calls are the most common inter-components communication mechanisms.

Beautiful Architecture Ch 4: Making Memories

This chapter describes the architecture of a photo processing workflow system. The typical scenario of a customer's order is as followed: The photographer takes pictures using a camera, loads them to a studio workstation, selects the good ones and enhanced them. After the enhancements the order is burned into a DVD, which is sent to the printing facility for further processing and printing. The printed pictures are sent back to the studio for customer pickup.

During the architecture they considered many aspects that I can now considered common sense after reading a few chapters in this book. For example, they divided the system into components and defined clear interfaces between them, kept module dependencies minimal, and built a very scalable and flexible system.

I specially liked the UI model separation from the domain model. Typically when the IU is closely tight to the domain model, it is difficult to change the domain and do unit testing. The author addressed this problem by separating both models using the facade design patterns to simplify their communication. The façade defined a higher level interface that made the domain model easier to use by the IU model. The IU only needs to ask the façade for service that it would otherwise need to traverse the graph of domain objects to figure out. This was a great use of a design pattern.

Beautiful Architecture Chapter 3: Architecting for Scale

We are in an era of computing where optimization to increase performance on a single processor his slowly hitting the wall. We started to see new processing platforms with many processor cores tightly integrated for parallel processing. The problem is that very few programmers know how to program these multicore systems. people are predicting that parallel programming skills are very important and will increasingly become important and valuable. My company started investing in equipping programmers with the right tools and concepts of parallel programming.
Is everybody wrong? is there a way of hiding concurrency from the programmer? At least that is the first impression that I got from reading the paper. Their goal was to hide the complexity of programming multiple threads and cores from the game developers, allowing them to see the system as a single threaded machine. This made me very excited about the paper until I read the section about performance and latency.
For their approach of hiding concurrency from the developer to work, they do not keep significant data in main memory. One of the major design decision here is to store the data persistently. This is will have a major impact on the response time and performance of the system.
So I see a couple of contradictions in the paper and I am not sure if I will classify it as a "beautiful architecture"
If latency is of big concern for games as mentioned in the paper, why will the author architect a system knowing that it will suffers from latency problems?
Parallelism should be a way of improving performance. If the goal is to make it simple for the developer, we should have significant performance benchmarks to make sure the solution does not take away the advantage of parallelism.

4 + 1 Views

I found this paper very interesting and simple to read and follow. The author presents a simple, but powerful way of dealing with complexity when architecting large systems. The main goal of many architectures is to use a single architectural style to provide a single view of the system. We all know how challenging and confusing it can be to look at a convoluted diagram. The author proposes to separate the architecture of the system into four essential views: logical, process, development, and physical. The four views work together and their collaboration is illustrated by the use of important scenarios.

I believe that “4+1” is a beautiful architecture for software architectures. What I mean is that it is a simple method to build and document powerful systems from an architectural perspective. It is very flexible and can be adapted to almost any project. The various views assure that all aspects of the system are taken into consideration and documented. This is usually difficult to achieve in single view architecture.

I am not very sure about the relation between the logical and the development views. The author says that they are very close, but address different concerns. I am thinking that the logical view described here is only important from the end-user perspective to see that the behavioral requirements are met. From a developer perspective, I think the development view deals with dividing the system in major subsystem, with each subsystem having a logical view (subsystem’s cohesion) and an interface for external subsystems (coupling)

A Tale of Two Systems - BA Chapter 2

This paper describes the environment where many new recruits work in when they join a new organization. For the folks still fulltime students, unless you are very lucky, you must be prepared to deal with a messy metropolis once you start your career. Most of the jobs out there today are to replace baby boomers that are retiring, and work on legacy systems that are usually messy metropolis. So refactoring and reverse engineering skills are very critical and hot in the market place.

Many legacy systems started as a small project, but have grown over the years into messy systems because of the constant need of delivery new functionalities under aggressive schedule. I agree with the author that it was very brave for the organization to take the step of rewriting the application. For some critical systems a very thorough analysis is needed to asset the risk and the cost of rewriting the system. From my experience rewriting messy systems has never worked because they are deployed on thousand of machines around the world and the ability to understand and refactor it is the only option.

The author mentioned some great factor to consider in order to make a good architecture. This is very important and useful when building a new system. Unfortunately most professionals do not get the chance to build new systems. They work with existing systems and spend their time either fixing bugs or testing code written by others. So, the ability to figure out the design from the messy code is even more valuable.