A Java Fork/Join Framework

The Java Fork/Join framework developed by Doug Lea is a framework that aims to simplify parallel programming type tasks. The framework is particularly suited to divide-and-conquer type algorithms where tasks are recursively split into smaller tasks and then executed. Results are then reassembled after all subtasks are completed.

Overall, the framework is pretty small. I think I saw a quote in the write-up that the entire framework was somewhere around 800 lines of code. At a high level, the framework uses a thread pool with task runners to execute tasks. This avoids some of the performance penalties associated with the Java Thread class. I liked the work-stealing algorithm implemented using the double-ended queues.

Performance of the framework seemed to be reasonable. I would be interested in seeing updated performance results using a more recent version of the JRE. I think when this paper was published, the author used version 1.2 of the JRE which is fairly outdated in today's standards.

GNU/EMACS: Creeping Featurism is a Strength (BA ch 11)

I have to admit, I am one of those people that never felt comfortable with Emacs. I'll use it if I have to, but that is about the extent of it. Overall, the whole concept of Emacs add-ons almost seemed a bit like the new version of web apps where end users are generating the content and driving traffic to the site. In this scenario, it is the open source developers and some end users of the application that are developing add-ons that are being rolled into the source tree.

I liked the way in which Emacs handled the buffers, frames and windows isolating the complexity of screen refreshes from the add-on developer. Only having to focus on the core "business logic" of the macro is a big plus.

I think a big reason for Emacs success is in its flexibility and ease with which its base functionality can be expanded upon. It reminds me of two separate systems that I have worked with in the past. Both systems contained screens with a bunch of buttons that could be used to carry out various tasks. One of the systems exposed an object model and allowed users the ability to link the button presses to custom javascript functions. These javascript functions could then manipulate the DOM as desired. The other system was identical in purpose, but the logic for the button actions were compiled into the application binary. Any changes to the button press functionality would require modifications to the application. One of these applications was successful and the other was viewed by many as a failure. Do you want to guess which one was successful?

Our Pattern Language

Hardware trends in recent years have definitely shown the need for an increase in parallelism. The number of processor cores seems to be increasing at a fairly steady rate. If this truly is the trend of the future, parallel software is a must.

The Our Pattern Language (OPL) initiative is a project with a goal of helping to foster parallel development through the use of patterns and a conceptual framework. To date, OPL has been organized into several different layers: architectural patterns, computational patterns, parallel algorithm strategy patterns, implementation strategy patterns, and concurrent execution patterns. The lower layers are where most of the work has been focused to date.

I am excited to see how the future unfolds in terms of parallel programming. It is definitely a trend that needs to be on any developer's radar and will almost certainly continue to shape the development landscape over the next few years (decade(s)?). The degree to which he/she may need to engage will be driven to a certain degree on the type of projects that they work on. However, I think it is important enough and definitely warrants at least some thought.

Metacircular Virtual Machines: Jikes (BA ch 10)

Just coming off of a read about a java PC emulator, we are asked this week to read about metacircular virtual machines. A metacircular virtual machine is a VM where the runtime environment is coded in the same language as that being hosted. In the case of Jikes, Jikes is coded in Java and acts as a Java runtime environment.

The obvious question for such systems is how are they bootstrapped? A good portion of the chapter is spent talking about how this feat is accomplished and the overall design of the system. I personally liked the portion of the chapter that talked about some of the virtual machine myths.

While Jikes is interesting, my overall question as with the JPC case study is the applicability of the system and how/where it would be used. I think it the case of both systems there are some definite academic uses.

Adaptive Object Model Architectural Style

Today, change is constant in business. Whether it is processes, pricing, supply chain, etc. the rule of thumb at least from my perspective is that things will change. The adaptive object model is a great way for developers to try and curb the consequences of change and be able to adapt quickly.

Early in my development career I used to despise systems like these. They were hard(er) for junior developers to understand and get up to speed with. But as I matured a bit, I see the value in systems like this. Not having to interrupt my current work to go back and make changes to previous systems to support new requirements is a great plus for everyone involved. The business can adapt quicker and hopefully there will be fewer potential bugs as well.

Building the GUI of such systems can be challenging though. The chapter introduces some concepts on how to handle this issue along with some good case studies. Overall, two thumbs up!

JPC: Java x86 PC Emulator (BA ch 9)

PC emulators by nature are slow. Layer on top of that an emulator written to run in a managed environment such as java and they are *really* slow. So the question I had when first reading the title of the chapter is why? Why would anyone want to do this? One of the core performance metrics of any emulator is performance. That is of course the target of emulation is something comparable to the current applications being run on the native hardware (ie you are not emulating an original Nintendo Entertainment System using a quad core 3GHz Xeon processor).

I will admit though the authors make a pretty good case (although I am still not sure I am fully a believer). I did like some of the discussion on the performance challenges the authors faced specifically in regards to the complexities of class loading and the processor protected mode/memory performance bottlenecks.

All in all it was interesting learning about the platform and the java performance tips that were shared. But my question still stands … is it useful for anything other than research? What do you think?

Big Ball of Mud

When I signed up to present on this paper, I had no idea what exactly it was about. I was not disappointed! The authors description of a big ball of mud in the opening paragraphs drew me in: "haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle."

I liked the content and thought it was a fresh perspective on what occurs in real world systems. I think that overall several topics seem to be repeated and that the paper could have been pruned down a bit. The HTML formatting was also interesting ... it wasn't the typical conference paper format. Perhaps a play on the "big ball of mud" concept?

Guardian: A Fault-Tolerant Operating System (BA ch 8)

The Tandem/16 NonStop hardware was the Sherman tank of computers. Redundancy and fault tolerance were built in from the start. The designers premise that things will fail and taking a proactive approach in this regard was great. Personally, I have never worked on one of these machines myself. I would be interested to hear from others who actually have. Did the machines truly fail with a slow degradation of services or was one or two failures enough to set off a cascading avalanche of failures rendering the machine unusable? How was performance compared to other machines from the same timeframe?

There is no doubt that these things were beasts. It was a remarkable piece of engineering and it would be great to see more of this type of thinking in our PCs of today.

Layered Architectures

Layered architectures help to provide a natural level of abstraction between components in a system. We see this pattern all the time in practice. As the book points out, one of the common uses of this pattern is in situations like the OSI network model where requests propagate down through the layers and responses return in the reverse order. In theory, layers are isolated from each other using well defined interfaces. In practice however, this separation can be difficult to achieve. Competing forces such as performance and error handling chip away at these boundaries.

Additionally, layering can introduce unintended consequences. Take for example the TCP/IP model discussed in the text. TCP assumes that a packet loss at a lower layer is due to network congestion. In response to this action, TCP reduces the congestion window and attempts a resend after a predetermined timeout interval. However, what if the standard ethernet datalink layer was replaced with a wireless implementation? Packet loss in a wireless network could simply be due to interference. The proper response to this type of error would be immediate retransmission. However, due to the layered architecture, the upper TCP layer is unaware of the reason as to why the packet was lost and cannot differentiate between the appropriate responses. In an effort to resolve this type of situation, interfaces between layers would need to be refactored to add in the appropriate conduit for data sharing.

One positive attribute of the layered architecture is that it promotes buildability. Interfaces between layers can be well defined and specific layers can be assigned to specific resources and worked on and unit tested in parallel. Once coding is complete, layers can be combined and should hopefully integrate with minimal additional effort.

Xen and the Beauty of Virtualization (BA ch 7)

Let's face it ... Virtualization is just plain cool. The problem though is that when virtualization began to gain renewed popularity about five to ten years back, the x86 hardware was not "virtualization friendly". Many protected mode instructions had to be trapped in protected mode and emulated. This was costly. Device I/O and DMA was also difficult. Xen worked around these issues by using paravirtualization which required replacement of all instructions in the guest operating system that were difficult to virtualize with a system call to the host hypervisor. The adavantage of this approach was that performance was good and the added costs of emulation was avoided. The downside was that the guest operating system required modifications. This type of virtualization was rarely supported by commercial OSes.

Now let's fast forward a few years. Virtualization is gaining increased popularity and hardware vendors are beginning to react. Both AMD and Intel introduce hardware support such as an IOMMU within their processors to ease the virtualization overhead previously experienced. With this shift, the performance gains of paravirtualization also began to diminish. This leads to a fairly radical design shift in Xen 3.0 in which support for hardware virtualization is also added.

I think there is still a lot to come in regards to the future of virtualization. Hopefully Xen will be there and continue to provide an open source alternative to the commercial products.

Facebook: Data Grows Up (BA ch 6)

The whole time I was reading the chapter on Facebook integration I kept thinking to myself, "Man ... what is something really cool that I could write to use these APIs?" Then I started to think about the business drivers Facebook was being presented with that drove them to develop the web service interface, FQL, FBML/FBJS. Obviously there is a desire for third party applications to be able to tap into the Facebook data as it can be extremely valuable for marketing purposes. However, Facebook has to figure out how to meet that demand but still keep the data "under wraps" as it is one of their core assets. This is what I think drove the decision of FBML/FBJS as it gave Facebook a way to allow third-party applications access to the data that they wanted without giving them access to the data itself.

Personally, I am not a fan when more and more competing standards or frameworks are introduced to accomplish the same task. For example, did Facebook really need to go as far as designing another HTML and JavaScript variant for providing a safe sandbox for these third-party applications? Could they simply have used HTML and JavaScript as they exist, but do some strict parsing before presentation to end users? I'm not sure in this case...

Pipes and Filters

What more can I say? Pipes and Filters is a solid style that has been around for at least as long as I have been working with computers. The ability to pipe input from one filter to another (maybe in the same process maybe not) breaking the work into distinct tasks is something that is easily understood and lends itself to making a system that is simple to build, easy to maintain and future-proof to a certain degree. The added benefits of being able to reconfigure/add/remove the order of filters or topology of how filters are applied (sequentially, in parallel, in a different order, etc.) is also a great benefit.

Excerpts from Christopher Alexander

Christopher Alexander has a unique style of explanation that I find quite interesting. Normally, I am not one to ponder the meaning of life or one to try and draw parallels from seemingly different ideas. I tend to see things in black and white (with maybe one or two shades of grey shimmied in between). However, I think Alexander makes some good points and I do think there is an alignment between building architecture and software architecture.

The main takeaways that I got from Chapter 9 were that we should trust in the process. Define the architectural style and allow it to guide the project to completion. Software projects today are more elaborate and complex than ever. Having a single architect attempt to design every line of code in a system is most likely to end in failure. Chapter 10 goes on to talk about pattern languages which are unique in the way that they are interpreted. They provide the framework for building and help to explain why "things" are built in the manner in which they are and the uniqueness but yet similarities that exist between them. The final excerpt concludes with several general "rules of thumb" for building. All in all very interesting!

Resource-Oriented Architectures (BA ch 5)

I enjoyed reading this chapter in the book. I liked to hear the author's perspective on why RESTful architectures are a good thing. A few years back I worked on a project that was implemented using Ruby on Rails and just recently we finished up a project using ASP.NET MVC framework. Both were very similar business applications ... they managed and provided a front-end to a bunch of data in a database (exciting I know!). Using this type of architecture seemed to be a natural fit and scaled extremely well.

One thing about the chapter that I am not sure I followed was the author's distaste for web services and issues with versioning. At the end of the day, web services may not be easiest beasts to tame, but can be useful.

ArchJava: Connecting Architecture to Implementation

ArchJava is an extension to Java that enforces communication integrity meaning that components only communicate with components that they are explicitly linked to in the architecture. This enforcement is a good thing. It turns out that as developers we aren't too good at abiding by the communication paths documented in a system architecture. Shocking I know! A framework like ArchJava forces the implementation to follow the communication paths outlined.

From a system design and documentation point of view, this is obviously good. But can tying the architecture to the implementation be too restricting? I don't think so. Can it take more time to code in this fashion? Probably. Is it worth it? I think so.

Making Memories (BA ch 4)

Hmm ... not really sure what to say about this chapter. Overall, I think the author laid out a clear picture of the development process of a software system to power a photography studio chain. The system consisted of components running in branch offices and corporate locations with data being shipped back and forth via DVDs. The system as a whole was a key requirement for the business to function. Without it, photographs could not be editted/uploaded, pictures could not be printed, customers could not take delivery of their orders, etc. But when I finished reading the chapter, I asked myself what did I actually learn? What were the key take-aways that should have sparked that Aha! moment? If someone has an opinion on this, please let me know! I guess there were some interesting points about the competing forces of business drivers and software development, some other good stuff about separating concerns (such as they didn't want any business logic in the UI for example).

One thing I was questioning though ... why go through all the trouble of building a whole subsystem for branch office clients/servers to exchange files? Why not just use thin clients as the end user terminals and have all software components run on the server? No more need for file transfers! Not to mention reduced support costs as you wouldn't have to administer/patch/update client PCs. Maybe you could argue that this would introduce more of a single point of failure, but if that is really a strong concern, add a second server and create a redundant cluster...

"4+1" View

Let's go back to my first day on the job after graduating from college:

Plunk! A book lands with a thud on my desk. "Hmm ... What's this?" I ask. "It's your training manual." says my boss. "Rational Unified Process? Interesting." I spend the next week pouring through the book trying to learn the correct way to build software. The "4+1" model was part of the documentation that I was asked to read.

I learned some things and ignored some things. I figured out early on that Rational Rose and Visual C++ were enemies. I also found out that as a consultant we were rarely called in to develop projects from the ground up. Usually we were called in to help out on the Messy Metropolis type projects of the world. Going back and creating documentation for an existing product (that had none) was rarely something that clients wanted to pay us for.

In all honestly, I like the "4+1" model. I think it is flexible and can be easily adapted to the type and size of the project being worked on. Clients appear to like it as well and seem to be able to understand the documentation that we produce. The fact that I have continued to use a loose variation of the model for the last ten years should be worth something. Right?

Architecting for Scale (BA ch 3)

Having read the chapter, it almost seemed to me that the author's were really trying to find a sort of "holy grail" of parallel computing. The thought of taking an application that has little or no knowledge of parallelism and being able to deploy it on a magical cluster that handles the concurrency and scheduling issues behind the scenes would be a huge feat. Just think of it ... none of us would even have to learn how to write parallel applications!

I question the application of this architecture for the MMO space as the authors intend. It seems that a major concern with these games is latency. The authors freely acknowledge that this system may be more prone to latency than other solutions in use today, but seem to brush off the importance. Are the authors out of touch with the requirements of their audience? Is the system doomed to fail from the start?

I would have also liked to see more details regarding performance. Yes, I get that there are no readily available benchmark suites that they can run to sort of gauge the performance of this architecture vs. existing architectures. However, I think the authors could have at least provided details regarding transactions per second for varying number of nodes or comparison of tasks per second for a single host cluster vs. 10, 20, 50, 100 ... node systems. Does the system scale linearly with the number of nodes or do additional nodes experience diminishing returns in regards to performance metrics? And is there an upper limit to how big this thing can scale?