The Java Fork/Join framework is meant to simplify parallel programming in Java. It allows the pattern of forking an algorithm into several parallel tasks and then joining the results to be abstracted out by the developer.
I found it interesting that they left it up to the developer to still determine when to actually use separate threads. This makes it useful if you know that for some threshold the algorithm can be solved faster than with separate tasks, you can use the alternative method rather than a full task.
The authors implemented this in Java and showed that garbage collection is a major hit as the the number of threads grows, due to the pausing of all threads when the collector is running. I think this same kind of framework can be written on modern OSes in a faster language, but it will not be as portable as the given solution. For example, on Windows one could use Fibers or other smaller units than threads if needed.
Wednesday, September 30, 2009
Emacs: Creeping Featurism as a Strength
Emacs can be a rather polarizing subject, as most people either love or hate it. This chapter put forth the architecture of emacs as a good way to support add-ons. The following questions and answers address this architecture.
1. Is it possible for a system like Emacs to be created in a non-open
source way?
Yes. The key strength of emacs is the ease of creating add-ons. It is quite possible to design such
a system in a commercial setting. The key is documenting how to create the add-ons and making
the extra features as easy as possible to create.
2. What are some of the disadvantages of a system like Emacs?
Finding what you want. When the base feature set is limited, everything is available as add-ons.
This can make finding certain features difficult as they may not be accessed in the most intuitive
way.
3. What architecture decisions have allowed Emacs to grow like it
has?
The ease of adding new features. When developers don't have to worry about display and other
subsystems that are ancillary to what they want to do, it makes it simple to work on.
4. When is avoiding complexity a good/bad argument for
implementation?
The only time I can think of when it would be bad is when something such as performance has a
higher priority than maintainability.
5. Do you think Firefox will replace Emacs?
No. =) The world will probably end first.
Monday, September 28, 2009
Our Pattern Language
Our Pattern Language is a paper defining patterns used during parallel programming. Different patterns are grouped into different categories: the interrelated architectural and computational patterns, parallel strategy, implementation strategy and concurrent execution patterns.
I thought their division was reasonable. While the paper lacks depth on describing each pattern, other papers can give the details of why and when to use each pattern. This paper tackles the problem of why they are needed at all and to facilitate communication between people working on parallel programs. When the language is defined, less confusion of terms occurs.
As parallelism becomes more prevalent with multiple cores in each CPU, programmers need to learn to take advantage of it. The problem is not so much in the tools available to develop with, but in educating programmers on how to design programs to take advantage of the parallelism. Knowing that these patterns exist for creating such programs is half the battle, and this paper helps on that front.
I thought their division was reasonable. While the paper lacks depth on describing each pattern, other papers can give the details of why and when to use each pattern. This paper tackles the problem of why they are needed at all and to facilitate communication between people working on parallel programs. When the language is defined, less confusion of terms occurs.
As parallelism becomes more prevalent with multiple cores in each CPU, programmers need to learn to take advantage of it. The problem is not so much in the tools available to develop with, but in educating programmers on how to design programs to take advantage of the parallelism. Knowing that these patterns exist for creating such programs is half the battle, and this paper helps on that front.
Jikes: A Metacircular VM
A metacircular VM is a sandbox written in the same language as the programs it is running. In this case, Jikes is a Java runtime written entirely in Java!
While this takes a bit of a performance bit, it has the advantaged of being able to take advantage of the facilities of the Java run-time such as managed code and garbage collection. However, it is not quite as fast. It is also not usually good practice from a security standpoint to implement an interpreter for a language is the same language, but in this case may be acceptable due to Java sandbox.
Jikes had to implement its own threading model due to the lack of support in operating systems when it was created (1997) for support of potentially hundreds of threads. By providing their own threading model they are able to support as many threads as needed. While the OS limit isn't as much of an issue today (see Pushing the Limits of Windows: Processes and Threads), having a consistent model can make portability a little easier.
While this takes a bit of a performance bit, it has the advantaged of being able to take advantage of the facilities of the Java run-time such as managed code and garbage collection. However, it is not quite as fast. It is also not usually good practice from a security standpoint to implement an interpreter for a language is the same language, but in this case may be acceptable due to Java sandbox.
Jikes had to implement its own threading model due to the lack of support in operating systems when it was created (1997) for support of potentially hundreds of threads. By providing their own threading model they are able to support as many threads as needed. While the OS limit isn't as much of an issue today (see Pushing the Limits of Windows: Processes and Threads), having a consistent model can make portability a little easier.
Wednesday, September 23, 2009
Adaptive Object Model
The Adaptive Object Model is a programming model that provides the ability to just describe an object and allow the interpreter to model the object for you. This avoids the need to compile a new object every time something new is added to a system, instead requiring just a description that can be added dynamically.
I found this pattern quite interesting, as it provides a lot of flexibility, with the cost of more work for the initial design and implementation. Maintenance and adding new features should be must simpler when this model is used for a system, but this only makes sense if there are potentially many different objects that may be added over time.
To avoid objects needing to know about other objects, abstractions are used to represent attributes and business rules. This allows different objects to have different attributes and ways of validating these attributes without requiring the interpreter to know about all the different possibilities. I can see this pattern being quite useful for certain situations.
I found this pattern quite interesting, as it provides a lot of flexibility, with the cost of more work for the initial design and implementation. Maintenance and adding new features should be must simpler when this model is used for a system, but this only makes sense if there are potentially many different objects that may be added over time.
To avoid objects needing to know about other objects, abstractions are used to represent attributes and business rules. This allows different objects to have different attributes and ways of validating these attributes without requiring the interpreter to know about all the different possibilities. I can see this pattern being quite useful for certain situations.
JPC: A Java based x86 Emulator
JPC is a Java based x86 emulator that is capable of launching a full OS.
What advantages do emulators have over VMs? What advantages do VMs have over emulators?
An emulator is fully run in software, it does not allow the actual code to run on hardware at all. A VM typically runs the code on the processor, at a much faster speed, while an emulator can run code for one hardware on a totally different platform.
Why would one prefer to use a Java emulator like JPC over a C++ emulator like Bochs, and vice-versa?
A Java implementation gives the security of the sandbox and ease of portability without recompiling, at the sacrifice of some speed.
Are there any performance and/or security considerations the JPC design team missed?
They didn't mention how few full OSes they can currently boot. Until it is capable of running common OSes, it will not be used for some of the security applications, such as auditing users without their knowledge.
For what purposes can you see yourself using an emulator like JPC? Any interesting uses on your mobile phone?
I would typically use an emulator for debugging otherwise hard - to - debug code, such as the bootup sequence of a computer. It provides the ability to save at any point, making is possible to debug tough race conditions if one can be produced once.
What advantages do emulators have over VMs? What advantages do VMs have over emulators?
An emulator is fully run in software, it does not allow the actual code to run on hardware at all. A VM typically runs the code on the processor, at a much faster speed, while an emulator can run code for one hardware on a totally different platform.
Why would one prefer to use a Java emulator like JPC over a C++ emulator like Bochs, and vice-versa?
A Java implementation gives the security of the sandbox and ease of portability without recompiling, at the sacrifice of some speed.
Are there any performance and/or security considerations the JPC design team missed?
They didn't mention how few full OSes they can currently boot. Until it is capable of running common OSes, it will not be used for some of the security applications, such as auditing users without their knowledge.
For what purposes can you see yourself using an emulator like JPC? Any interesting uses on your mobile phone?
I would typically use an emulator for debugging otherwise hard - to - debug code, such as the bootup sequence of a computer. It provides the ability to save at any point, making is possible to debug tough race conditions if one can be produced once.
Monday, September 21, 2009
Gardian: A Fault-Tolerant OS Environment
Guardian was the OS used by Tandem starting in the 1970'2. Its goal was to eliminate all single sources of failures in an effort to create an extremely reliable system, and became popular for ATMs an other critical infrastructure.
Security was not a strong point of this architecture. The only thing guarding privileged code is the location and privilege bit in a register. If these can be manipulated, admin access can be achieved by untrusted components.
Due to the messaging bottleneck and other overhead, the system was not very fast or terribly scalable. This led to its downfall as regular hardware became more reliable without sacrificing speed.
Security was not a strong point of this architecture. The only thing guarding privileged code is the location and privilege bit in a register. If these can be manipulated, admin access can be achieved by untrusted components.
Due to the messaging bottleneck and other overhead, the system was not very fast or terribly scalable. This led to its downfall as regular hardware became more reliable without sacrificing speed.
Big Ball of Mud
The Big Ball of Mud architecture is what many projects end up as - a bunch of code tangled together with no clear boundaries. This may happen over time as fixed are placed in the easiest place in the effort to get something together quickly.
The authors listed a couple of ways to prevent this that I agreed with - code reviews and refactoring. The problem with many products is that time is not budgeted for this as it may seem superfluous. The main benefit - lower maintenance costs over the long term - is deemed beneficial enough to risk delaying putting the product on the market. This may in fact be the case in which case the manager made the correct choice! If the product works to the customer's expectations, is needed immediately, and will not need much maintenance, the reviews and refactoring may be overkill. Not every architecture needs to be beautiful.
I have worked on code that was supposed to be throwaway code that ended up being used. Now if code is going on the shelf as as part of IRAD, I check that it is easy to understand and handles errors. Rapid prototyping may be needed some times to reduce risk during development, but time should be allotted for actual cleanup if the prototype is going to be used in the final project. Putting in the extra effort up front makes no sense in the cases where the prototype ends up being scrapped anyway.
The authors listed a couple of ways to prevent this that I agreed with - code reviews and refactoring. The problem with many products is that time is not budgeted for this as it may seem superfluous. The main benefit - lower maintenance costs over the long term - is deemed beneficial enough to risk delaying putting the product on the market. This may in fact be the case in which case the manager made the correct choice! If the product works to the customer's expectations, is needed immediately, and will not need much maintenance, the reviews and refactoring may be overkill. Not every architecture needs to be beautiful.
I have worked on code that was supposed to be throwaway code that ended up being used. Now if code is going on the shelf as as part of IRAD, I check that it is easy to understand and handles errors. Rapid prototyping may be needed some times to reduce risk during development, but time should be allotted for actual cleanup if the prototype is going to be used in the final project. Putting in the extra effort up front makes no sense in the cases where the prototype ends up being scrapped anyway.
Wednesday, September 16, 2009
Layered Architecture
This pattern refers to the practice of layering services on top of each other, with the prime example being the OSI network layers.
My main exposure to this pattern has been in network stacks, having written some of the layers for one. This approach makes it less cumbersome to add layers, such as ICMP when IP is already separate. They also recommend in the paper decoupling the layers, through callbacks if necessary. I can say from personal experience that this works quite well until someone new doesn't follow the architecture. From there it is a downward slope toward becoming unmaintainable.
With the evolution of mobile technologies more people expect to be able to access software from more devices, where do you see this expectation having the biggest impact on the architectural layers (ranging from close to the client to close to the hardware or anywhere in between)?
I believe the impact is in two places, the hardware layer and the presentation to the user layer. The hardware is different, often with substantially less memory and resources, thus requiring changes. Also, the way a person interacts with mobile devices is substantially different from a PC, and this presentation layer needs to be changed accordingly.
My main exposure to this pattern has been in network stacks, having written some of the layers for one. This approach makes it less cumbersome to add layers, such as ICMP when IP is already separate. They also recommend in the paper decoupling the layers, through callbacks if necessary. I can say from personal experience that this works quite well until someone new doesn't follow the architecture. From there it is a downward slope toward becoming unmaintainable.
With the evolution of mobile technologies more people expect to be able to access software from more devices, where do you see this expectation having the biggest impact on the architectural layers (ranging from close to the client to close to the hardware or anywhere in between)?
I believe the impact is in two places, the hardware layer and the presentation to the user layer. The hardware is different, often with substantially less memory and resources, thus requiring changes. Also, the way a person interacts with mobile devices is substantially different from a PC, and this presentation layer needs to be changed accordingly.
Tuesday, September 15, 2009
Beautiful Architecture: Xen
Xen is an open source virtual machine capable of running an sevreal OSes beneath it. One of the early contributions of Xen was its use of paravirtualization. Xen needs to capture all interaction with the OS, and older x86 systems made this impossible as some instructions which should have been privileged were not, such as sidt. Other VMs solved this problem by using binary translation, a way of catching these instructions before they executed and replacing them. This is an expensive operation and Xen improved it by rewriting the binaries in the OS before they were installed. This one cost penalty was negligible compared to the savings incurred when running the VMs.
Thankfully, today processors provide a special mode for hyper visor VMs such as Xen to use. Due to the open source status of Xen, major vendors such as Intel and AMD contributed the code as it provided a good reference for others to use. This makes the VMs even faster.
I also appreciated the use of a separate domain for the controlling of the VMs running in Xen. This separation helps security by removing potential vectors of attack from the OSes being virtualized by Xen.
Thankfully, today processors provide a special mode for hyper visor VMs such as Xen to use. Due to the open source status of Xen, major vendors such as Intel and AMD contributed the code as it provided a good reference for others to use. This makes the VMs even faster.
I also appreciated the use of a separate domain for the controlling of the VMs running in Xen. This separation helps security by removing potential vectors of attack from the OSes being virtualized by Xen.
Monday, September 14, 2009
Pipes and Filters
This architectural pattern is quite common. I have worked on it personally when doing work in the windows kernel. Both the file system stack and network stack use this pattern, as any driver can plug in a filter in different spots without needing to know who is directly above or below. This is helpful as it gives a standard API for developers to work with and be interoperable with both the OS and third party filters in the system.
In this case, the filters are passive, waiting on input coming from a device or for data to be written to the device. This is beneficial in reducing the number of threads and time spent in the kernel. Because all filters are in the kernel, to context switching is needed either, reducing the time needed for marshaling data as would be required in other cases.
In this case, the filters are passive, waiting on input coming from a device or for data to be written to the device. This is beneficial in reducing the number of threads and time spent in the kernel. Because all filters are in the kernel, to context switching is needed either, reducing the time needed for marshaling data as would be required in other cases.
Sunday, September 13, 2009
Beautiful Architecture: Facebook Growing Up
This chapter covered the architecture of Facebook. Facebook, as a social networking site, has personal information available that can indicate the preferences of individuals on the web site. This information could be extremely useful to other sites that want to use that information, either for marketing or other applications.
The architecture of Facebook keeps security at a forefront, as no information can be divulged without an individual allowing it. Third party sites can interact with the information either remotely through the API or using FQL (a way of batching API requests). Alternatively, information can be displayed on the Facebook site itself using FBML, a limited version of HTML. In both of these cases, all interaction with data occurs on Facebook's servers, ensuring nothing is displayed that should be hidden.
I thought Facebook did a great job of keeping the architecture simple enough to understand, but still protect security of individuals by proctoring all interactions with the data. They also copied well known language paradigms in SQL and HTML to create FQL and FBML respectively. This makes the learning curve much easier for third party developers, ensuring that these interfaces are actually used and benefit Facebook by providing more content for users.
The architecture of Facebook keeps security at a forefront, as no information can be divulged without an individual allowing it. Third party sites can interact with the information either remotely through the API or using FQL (a way of batching API requests). Alternatively, information can be displayed on the Facebook site itself using FBML, a limited version of HTML. In both of these cases, all interaction with data occurs on Facebook's servers, ensuring nothing is displayed that should be hidden.
I thought Facebook did a great job of keeping the architecture simple enough to understand, but still protect security of individuals by proctoring all interactions with the data. They also copied well known language paradigms in SQL and HTML to create FQL and FBML respectively. This makes the learning curve much easier for third party developers, ensuring that these interfaces are actually used and benefit Facebook by providing more content for users.
Wednesday, September 9, 2009
Excerpts from Christopher Alexander
We read a couple of chapters from books by Christopher Alexander, who advocated patterns for creating physical buildings in the 70's. For him, a pattern is like the word of a sentence, and patterns put together create a building instead of a sentence. The way they are structured follow more patterns in order to create a "grammar" for the language.
I think it would be interesting to see how many of the building patterns could be applied to software. For example, one of the patterns for building was to design the building in such a way that more intimate rooms are farther away from the entrance where visitors come. For example, the foyer, then formal entertaining space, then kitchen, then bedroom. In software, this could apply to the design of GUIs - make the administration part that is rarely used several clicks farther than the typically used interface.
Any thoughts?
I think it would be interesting to see how many of the building patterns could be applied to software. For example, one of the patterns for building was to design the building in such a way that more intimate rooms are farther away from the entrance where visitors come. For example, the foyer, then formal entertaining space, then kitchen, then bedroom. In software, this could apply to the design of GUIs - make the administration part that is rarely used several clicks farther than the typically used interface.
Any thoughts?
Tuesday, September 8, 2009
Resource Oriented Architecture
This chapter in Beautiful Architecture dealt with the benefits of the architecture the World Wide Web uses. This would be useful inside many businesses, as many finding items on the web is often easier than finding things on the company network, an observation that I know holds true where I work anyway!
The REST architecture was held up as the best architecture in this scenario, which consists of the GET, PUT/POST and DELETE verbs. While only 4, I think they are fine for managing information, as creating, editing, viewing and removing information are the only things that need to be done, and these are covered.
It is also important in this architecture to separate the information from the address. Decoupling these two parts allows one to change the information without breaking any existing users/connections. This is important in providing reliability to users.
The REST architecture was held up as the best architecture in this scenario, which consists of the GET, PUT/POST and DELETE verbs. While only 4, I think they are fine for managing information, as creating, editing, viewing and removing information are the only things that need to be done, and these are covered.
It is also important in this architecture to separate the information from the address. Decoupling these two parts allows one to change the information without breaking any existing users/connections. This is important in providing reliability to users.
Saturday, September 5, 2009
ArchJava - Architecture Language
ArchJava is a descriptive architectural language that builds on top of Java. It ensures that anything written in its language does not violate the architecture, for example, communication modules is only possible where these points are defined.
This could be helpful as it builds on top of the type safety to prevent the programmer from violating the architecture, make it easy to diagram the architecture and easier to refactor.
However, as it stands now, it would need several improvements to be used commonly. The architect still has to write code in the language, or teach others how to. The graphing was not shown in the paper, and being able to visualize makes it much easier to understand architecture than looking at a definition in code.
Perhaps the biggest limitation is the inability to coordinate between multiple projects. This makes it impossible to use to describe the architecture for some projects, such as the Making Memories architecture described in the previous post. It could not describe the communication between the sides and the rendering farm, or between third party applications. Any comments?
This could be helpful as it builds on top of the type safety to prevent the programmer from violating the architecture, make it easy to diagram the architecture and easier to refactor.
However, as it stands now, it would need several improvements to be used commonly. The architect still has to write code in the language, or teach others how to. The graphing was not shown in the paper, and being able to visualize makes it much easier to understand architecture than looking at a definition in code.
Perhaps the biggest limitation is the inability to coordinate between multiple projects. This makes it impossible to use to describe the architecture for some projects, such as the Making Memories architecture described in the previous post. It could not describe the communication between the sides and the rendering farm, or between third party applications. Any comments?
Friday, September 4, 2009
Beautiful Architecture: Making Memories
Making Memories describes the architecture used for photography labs, where pictures are taken in a studio, enhanced and ordered at the studio. They are then sent to a processing center where they are rendered and printed, then sent back to the studio for pickup by the customer.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
I especially appreciated their solution for keeping their DVD formats opaque. Because third parties need to interact with it, they correctly anticipated that the third parties may write their own tools to grab the format, making it impossible to change without breaking it. This is an example of Conway's law - software is structured around the communication structures. To solve the problem, they created a loader that parsed the DVD and called routines. This is a useful solution to remember when creating interfaces third parties may use.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
I especially appreciated their solution for keeping their DVD formats opaque. Because third parties need to interact with it, they correctly anticipated that the third parties may write their own tools to grab the format, making it impossible to change without breaking it. This is an example of Conway's law - software is structured around the communication structures. To solve the problem, they created a loader that parsed the DVD and called routines. This is a useful solution to remember when creating interfaces third parties may use.
Wednesday, September 2, 2009
4+1 Architectural View Model
Let's say you're a software architect and you want to know how to arrive at and document a an architecture. This paper puts forth a process for accomplishing this objective. Architecture is documented from separate views, each with its own goal.
I thought this was a great approach to follow, for two reasons. One, in my experience, use cases or scenarios can be extremely useful for verifying what the customer is envisioning, and this process uses them extensively (the "+1"). Second, it is flexible. I often work on small projects, and following an exhaustive process for documentation will take longer than actually doing the designing and implementing.
I have not used the 4+1 model before, but I can envision using it more in the future. Anyone else have experience with it?
I thought this was a great approach to follow, for two reasons. One, in my experience, use cases or scenarios can be extremely useful for verifying what the customer is envisioning, and this process uses them extensively (the "+1"). Second, it is flexible. I often work on small projects, and following an exhaustive process for documentation will take longer than actually doing the designing and implementing.
I have not used the 4+1 model before, but I can envision using it more in the future. Anyone else have experience with it?
Subscribe to:
Posts (Atom)