Ryan's Blog

ArchJava

What is it?

ArchJava is an Architecture Description Language that is implemented using Java (in a very Java like syntax). It's different than other ADLs in that it is directly linked with your code throughout the life-cycle of the application. You compile you Java program using the ArchJava compiler, binding the normal Java application with the Architecture Description Language. The idea is that the architect can write the architecture in the ArchJava ADL and then be assured that the resulting code does not violate their architecture. More information on it can be found in this paper and on their website.

Paranoia?

It seemed to me like this solution was a little overkill. The ArchJava compiler forces communication of the layers/components through the architecture's "connectors". I immediately thought that this would be a significant degradation in performance, but their website claims a 10% hit on performance for the worst case. I was wondering why it was necessary to enforce this architecture through all levels of the development cycle. Even when the program is running in production, ArchJava is in use. It's nice to have a programmatic solution, but if the architect's vision is clearly communicated and the architect is involved in the project, wouldn't they know when there were violations in their architecture? The one benefit that I can see is for a project over a longer term. Once the architect and original developers have moved on, with new developers and architects it's easy for the developers to muddy the architecture. The hope would be that the new architect would know enough about the system and be involved enough to be able to spot the violations. With that said, often times architects are not involved in the smaller projects after a piece of software is in production, so they could be bypassed completely. In this case it would be nice to have the sanity check.

Why not AOP?

Probably the biggest problem I have with ArchJava is requiring it to be running at all times. After reading the paper above I thought about how I might implement a similar solution that wouldn't have to run when the code was in production use. I thought Aspect Oriented Programming, Continuous Integration and some JUnit type tests could achieve the same results without having to put the code into production. So maybe there would be around advice for each of the method calls. It would determine where the request came from (which method/class/module) and what method/class/module it was attempting to call. It could then have some list of acceptable modules or classes for that particular caller. If a method was calling something that it shouldn't, it could throw an error that the build server would report.

Posted at 08:44PM Dec 05, 2006 by Ryan Senior in Architecture  |  Comments[1]

Architecture of the Linux Kernel

Linux Kernel at a High Level

A few days ago I read Conceptual Architecture of the Linux Kernel. It's a paper by Ivan Bowman on the high level organization of the Linux kernel. He discusses the kernel being organized into essentially 5 subsystems: the Process Scheduler, Memory Manager, Virtual File System, Network Interface and Inter-Process Communication. The paper then goes on to describe the areas of the kernel that are abstracted and generalized. For example, the kernel has an Architecture Independent Scheduler module that is the same across processor types. There's then another module that can swap out depending on the processor. Obviously this has worked out well. The kernel now supports 16+ processors! I would also be interested in seeing a comparison between the design of the Linux kernel with the design of the NetBSD kernel. NetBSD currently supports 50+ architectures. The author also points to similar approaches to the device drivers and file systems, which makes sense. I thought that this was pretty interesting because usually I'm seeing info on the design of Object Oriented systems. With the kernel, many of the Object Oriented philosophies are used (information hiding, abstraction etc) even though we're still talking C.

The Developers

What I thought was an interesting observation was that with the large number of people working on the kernel (at the time of the paper almost 200), few people worked on more than one module. This is obviously a credit to the design of Linux. This also encourages more people to work on it. It requires a significant amount of effort to know enough about a system to go in and start making changes. If developers can focus on just one subsystem, this will lessen the learning curve. I wonder if this still holds true today. There's obviously a lot more code now, and as of 2.6.11, there are 467 developers on the project.

An Updated Paper?

I liked this paper because it didn't have too many details. I can get a high level idea at the organization of the kernel by this paper and I learned what I wanted to. I do have some gripes. I would have liked to have learned more about the kernel modules. He kind of glosses over them some, but doesn't discuss much on how they do it. Also I'd be interested in seeing an updated version of this. He said that he was using the 2.0.27 version of Linux, and there's been 3 major revisions to the kernel (I'm writing this blog entry from 2.6.17)

Posted at 05:47PM Nov 28, 2006 by Ryan Senior in Architecture  |  Comments[0]

Principled Design of the Modern Web Architecture

I recently read Roy T. Fielding and Richard N. Taylor's Principled Design of the Modern Web Architecture. The article discusses the architecture of the web. It explains some of the reasoning behind the decisions that made the web what it is today. I thought that probably most readers would already be pretty familiar with a lot of the concepts that are mentioned in the paper, but the one thing that I did think was interesting was the rationale and other options for the architectural decisions that were made.

Forgetting the Fundamentals

In reading this paper, there wasn't a lot of new information for me. Reading information about the web protocol choices, flexibility of the web architecture, "connectors" (such as web browsers, caching servers, DNS etc) were pretty familiar. The web has become so common-place that I've never really stopped to think that at some point someone made a conscious architectural decision to use these technologies.

REST Architectural Style

I had what I thought was a basic understanding of the REST architecture before reading this paper. Early in the paper, I realized that I didn't know much about it at all. I always thought that REST was a fairly abstract concept and was ultimately just a hodge podge of technologies. Usually I have heard it in contrast with SOAP. My thinking from what I had read in the past was SOAP - "overly structured, too much overhead" and REST - "too loose on restrictions, not enough structure". In the paper, the authors point to the web as an implementation of REST. Obviously I didn't have a firm grasp of REST before!

Hypermedia vs. REST

One point that I thought was interesting was something that is very simple and fundamental to the web, the resource, and how those resources are retrieved. In the paper, it details the previous ways that hypermedia systems have implemented resources. It lists the below three choices:

• render the data where it is located and send a fixed-format image to the recipient
• encapsulate the data with a rendering engine and send both to the recipient
• send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine

Having the web architecture so ingrained in my daily life, obviously I would think about the whole concept of links and linking to resources, using HTML and a browser to render the page etc. In existing hypermedia systems, this wasn't common. That's where REST came in. The authors point out that the REST architecture is kind of a hybrid of the above approaches, with the client/server model in retrieving the data, the rendering engine being on the client machine and then the HTML as the raw data/metadata.

Stateless vs. Non-stateless

The paper discusses the web being stateless and that it was intended to be as such. It then points out the idea of a cookie that was an "inappropriate extension" to the protocol. I thought that this was interesting because web developers spend so much of their time dealing with the "stateless" feature of the web. Obviously we need state, we can't put everything on one page. Cookies were one way that developers could grapple with the big beast that is managing state in a stateless protocol. The authors in about the middle of the paper begin to talk about good aspects (from an architectural viewpoint) of being stateless. One thing that specifically caught my eye was that REST being stateless "forces all of the information that might factor into the reusability of a cached response to be present in each request". I would say that in the real world, this is not the case. Nowhere is this more evident then when organizations are trying to introduce load balancing by introducing a second instance of an application. In order to handle this stateless nature, data needs to be stored on the server side for each user. Obviously there's problems if the first three requests go to server 1 and then the fourth one goes to server 2. I thought that the authors should have mentioned some of the rationale (good and bad) that went in to making all operations stateless. It may have made things easier architecturally, but there's certainly negative impacts to being stateless.

Posted at 11:17PM Nov 15, 2006 by Ryan Senior in Architecture  |  Comments[0]

Big Ball of Mud

I recently read the Big Ball of Mud pattern. When I started reading it, I immediately disagreed with their term pattern for this. I thought that obviously they forgot the anti on the front of it, but as I read on, I agreed.

It's a pattern???

In reading the pattern, the point is made that if the Big Ball of Mud pattern is so terrible, why is it the most prevalent? The typical definition of a pattern is that it is a "solution to a problem in a context". To add that, it's a solution that has certain desirable characteristics, usually flexibility, reuse, adaptability, separation of concerns etc. In reading the paper, I realized that the Big Ball of Mud pattern also has "desirable" characteristics. Mainly time to market and up front cost. With all of the books, courses, patterns and effort that has been put into software architecture and design, it's unfortunate that our most prevalent architecture is still the Big Ball of Mud.

Is Free/Open Source Software the Answer?

Is there any way to combat such a barbaric software tactic? I think that the prevalence of open source frameworks can help decrease the muddiness of architecture. My experience is mainly in the Java/J2EE world, which has an abundance of high quality, free and open source frameworks and tools. We have MVC frameworks like JSF, Struts and SpringMVC. For utility code we have the Jakarta Commons project. For database access we have Hibernate. For loosely coupled designs we have Spring. These frameworks are free (low up-front cost) and are often faster than homegrown solutions (low time to market). Can you imagine going back to writing your own HTML generation code and processing form elements directly in a Servlet after using Struts/JSF/etc? These sort of frameworks promote good designs and can lead to a much faster time to market. Does this eliminate the big ball of mud? Unfortunately no. Those project managers and project sponsors are crafty. If they learn that we can implement things faster using framework X, our deadline for delivery is even shorter, putting us right back in the same mess we were in before. Also using good design with frameworks means that the developer needs to have knowledge of the framework and likely will need experience with it. Although frameworks like some of the Jakarta Commons ones can be used with a pretty small learning curve, Hibernate and other more complicated ones, cannot.

Big Ball of Mud Pattern

I liked how the pattern was written. I thought that it was pretty reflective of the real-world causes of the big ball of mud, how it continues and how it can be changed/fixed. One particularly good point I thought was around prevention. Some of the tactics mentioned were code reviews and pair programming. Getting code out in the open (they refer to it as expose code to daylight). It keeps developers honest. I always approach code reviews as if I am going to have to support that code a month from now. It makes you look at things closely "do I really understand what's going on in this method? If not, why not?" Such code review procedures have to be set in stone to be effective. Often when deadlines get close, the code review is the first thing that is forgotten or ignored. Those systems are usually the big balls of mud! Is it ironic that the systems that don't have time for a code review are usually the ones that need it the most? I thought that it was interesting that one of the solutions to the problem was having developers with more domain knowledge, which is also something extensively discussed by Eric Evans in Domain Driven Design. I also think it can be a tremendous help when the manager(s) of the team(s) working on the project value high quality code. I don't necessarily mean bug free, but one that understands the value of well designed and implemented code. Maybe they have had to maintain a Big Ball of Mud and realize that it can be a very negative experience for their employees. A manager that values code quality is also in a position to make sure that their employees also value it and can enforce and participate in activities that will help prevent the Big Ball of Mud.

Posted at 09:04PM Nov 02, 2006 by Ryan Senior in Architecture  |  Comments[0]

Large-Scale Domain Driven Design

Large Scale Domain Driven Design

In chapter 16 of Domain Driven Design, Eric discusses some of the difficulties that a model driven design will face on large projects. He discusses several approaches to fixing these problems. One of the approaches he discusses is to add Responsibility Layers. This is adding a layered architecture to your model, making each layer adhere to some specific set of conditions. One example he gives is creating an Operation layer of the system for carrying out the tasks that the system must perform to serve it's purpose. Another is creating a supporting layer called Potential. The idea he presents is that the customer isn't really part of the functioning system, but more of an initiator of an Operation. So the customer object would go into the Potential layer. What I thought was good about this chapter was that he gave some of the downsides and restrictions that imposing a structure like this causes. He even tries to talk the reader out of using it unless the situation requires it. He also included some more agile-like generic patterns such as Evolving Order (constantly changing model) and a System Metaphor.

Objects are specialists; developers are generalists

The above is a heading from the chapter 17 that I thought was pretty good. The point he was making was that often software processes, project managers and rigid organization structure can hinder a strategic domain driven design. He makes the point that often it's a goal to make it so that architects and designers don't need to know the business side so that they can focus on "techincal stuff". He also points out that often projects are treated more like objects in that they are designed to limit the communication and interaction with other teams. This is obviously not good for a project using model driven design (or any design). He also points out that designers, architects and developers should all contribute to the code and be actively involved in the business side of the application as well. If the architect and designer are in there, working with the developers, they will see the need to evolve various aspects of the design and will result in a better product.

Conclusion

I think Domain Driven Design is a well written book and I would recommend it. I think that even if the organization you're developing code for is not interested in letting you pursue Model Driven Design, there is still a lot to be gained by reading the book. I think the first few chapters would be good even for non-developers that were involved in software projects.

Posted at 10:06PM Oct 19, 2006 by Ryan Senior in Architecture  |  Comments[0]

SAIP Components Chapter and Conclusion

Components

The second to last chapter of the book I think was pretty uninteresting. A good portion of what the chapter had to say was common sense. It discussed techniques for insulating yourself from component changes and how to connect components together, which I think was the high point of the chapter. I thought that the case study was a bit odd. I don't know that I really think of a database as an "off the shelf component". In this case it was considering Microsoft Access a software component. I guess at a fundamental level it is. It's a piece of software that your software communicates with via a well defined syntax (SQL). On the other hand, I have never heard anyone said "my system is based on components because it uses a database". What I thought was strange about the case study was that it seemed to be a pretty small (trivial?) system. It was discussing originally using Access on the back end, but then they switched to using Java and servlets since their original prototype didn't work out. Also, hopefully they were joking when they said the following about switching to Java: "...business and database logic was moved to the servlets and Java Beans".

Conclusion/Review of SAIP

I thought this book was average. Not great, but not bad. I liked certain sections of it (designing architectures I thought was pretty good, along with ATAM and CBAM). I thought that the book really glossed over the architectural patterns. It said that we should evaluate an architectural pattern to use. Sounds good, but where can I find architectural patterns to use. There may not be a catalog of them, but are there papers out there that have some, maybe a website with a few?

I think that this book should have assumed a basic understanding of development and software development process. Very often the book took entirely too long to explain a very basic software development practice. I think that a significant portion of the book could be cut out if they eliminated some of that fluff. I also thought it strange how weak their examples were. The first two examples of the book (the aircraft software and the air traffic control) never hit production and the last one seemed like it was a pretty small/trivial system. I think that the first case study was pretty ground breaking in terms of "information hiding" and OO-like development, but is it a good architectural example? The second case study said that the architecture wasn't used because the customer went with a "simpler, less ambitious" solution. Is this second case study sending the message to readers that often good architecture is too expensive and ambitious? I certainly hope not! If I am reading a book on Software Architecture, and one of it's goals is for me to take extra time and effort to really plan out the Architecture, I want to see some success stories! Ones that I can think "wow, I'd like a system that I designed to be so reusable!". Good success stores would inspire people to put in the extra time to do things right.

I'll definitely keep the book around and could see myself referencing it.

Posted at 08:03PM Sep 28, 2006 by Ryan Senior in Architecture  |  Comments[0]

J2EE Architecture

SAIP Chapter 16 - J2EE Architecture

Chapter 16 of the Software Architecture in Practice goes over the J2EE architecture at a high level, specifically focusing on EJBs. I found that what the book says to be accurate in an academic sense. There are several things that the book kind of glosses over around EJBs and specifically around the portability of the beans and the performance issues surrounding EJBs. I think that J2EE architecture and EJBs are good architectures to study because they are theoretically very sound and very well designed. I think that they have failed to live up to their performance goals. They have suffered the fate of specification complexity, too many XML configuration files, they're difficult to test and have somewhat limited portability due to the large difference between EJB container vendors (and the constant desire to wander from the spec and into the special EJB vendor specific features). I think that a lot of these gripes are supposed to be addressed in EJB 3, however it remains to be seen whether or not EJBs will be able to recover from their initial bad name.

I have very little experience working with EJBs. I've been working with J2E software for about 2 1/2 years and have managed to avoid it. I've worked quite a bit with JSPs, servlets, JMS, and some of the other areas of the J2EE specification. Rather than EJBs, the organizations I have worked at/for have opted for the POJO route, using Toplink or Hibernate. I've also been working with Spring recently for some J2EE-like features. Most developers I have talked with have a pretty negative attitude about EJBs either having been burned by it themselves or through word of mouth horror stories.

Luther Architecture

The Luther architecture is an architectural case study in the application of J2EE/EJB technologies to wearable computers. The solution involved basically three layers of architecture. There was a database with EJBs back end that they referred to as components. An "application" middle layer and the the view layer. The idea was that the application middle layer would handle all of the business logic along with component communication and then there would be numerous views (to coincide with the various web based browsers, PDAs, PocketPCs and other devices). The benefit of this architecture was that since they knew there were going to be many different interfaces for this software program, they gained significant benefit by putting as much logic in the back end as possible and keeping the view layer thin.

I think their solution made sense for what they were doing. They were using the stateful session beans to help manage the complexity of their session information. This is nice to have on the back end, since there would be many different UIs, leading to solution sprawl. One part of their architecture was that they communicated to the "application" layer of the architecture via XML. In my experience, sometimes this can be problematic. XML works fine for small volumes and lighter loads, however as soon as the XMLs get large and face heavy volumes, performance degrades very quickly. Parsing XML in Java is not free, it consumes a lot of heap space and is often ugly to design/code.

Posted at 10:25PM Sep 25, 2006 by Ryan Senior in Architecture  |  Comments[1]