Friday, August 21, 2009

More on Software Architecture – Architectural Styles

Our domain of software architecture is improving constantly and gets specified in more detail. This is not bad thing because it helps to avoid misconceptions about their place in software development. Architectural styles are one building block of the process in striving for the best fitting solution. Looking for analogies, ‘real architecture’ in terms of brick and mortar has a long history in architectural styles like Gothic, Tudor, Art Nouveau, or Postmodern. These styles are influenced by social, political, cultural and other trends. Of course, technical factors like material, technologies, infrastructure and appliances play an additional role (and money, of course). In software architecture, these factors are predominant. But trends and hypes play their role as well. SOA is a good example to illustrate this. In general, architectural styles can be clustered based on the part of the system they describe like structure [Component, Layered], deployment [Client-Server, n-Tier, Peer-to-Peer], communication patterns [Message Bus], and others. Sometimes it is hard to assign a style properly to cluster. Styles to handle user interaction [MVC] might be a part of the structure or could be seen as a separate cluster. But this is not important. More relevant is the process of combining styles in order to achieve the best solution. Some styles might be determined by the requirements directly. Hardware, integration of legacy system and other infrastructure related preconditions might limit the choice. Moreover, the skill set of the team is another factor. In general, functional and non-functional requirements should influence the architectural styles and their combination used to build the system (hypes should not btw.). If this is done properly, the benefits are proven patterns, a common understanding, interoperability and reuse. In other words, the combination of the best fitting architectural styles is a key success criterions in the process of building a software system.

Tuesday, August 04, 2009

Software based Transactional Memory

This is interesting news for C# developer. MSDN DevLabs offers the STM.NET as an extension to the .NET framework 4.0 (Beta 1) for experimental purposes. STM stands for Software Transactional Memory and provides support for concurrency in order to use the multi-core architecture efficiently. STM does not provide a lock framework. It comes with an approach to isolate shared state which is the real issue when it comes to concurrency (because of dead locks and/or race conditions). Based on the ‘transaction pattern’ used in other areas of computer science, code (and memory) is handled isolated to enable an atomic execution. Code sections are demarcated accordingly. It will be interesting to check on this, especially pertaining to performance implications. But anyhow, it might be a promising step, at least for the C# folks.