InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Pattern Oriented Software Architecture Volumes 4 and 5 released

Posted by Niclas Nilsson on Aug 24, 2007

Sections
Architecture & Design,
Enterprise Architecture
Topics
Architecture ,
Design ,
Enterprise Architecture
Tags
Book ,
Design Patterns ,
Patterns

Volume 4 and volume 5 in the Pattern-Oriented Software Architecture book series has been released. Volume 4 is about a pattern language for distributed computing and volume 5 is an “in-depth look of what patterns are, what they are not, and how to use them successfully”.

InfoQ spoke to  Kevlin Henney, one of the authors of the latest, and seemingly last two books in the POSA-series. We asked Kevlin how come both books were released at approximately the same time?

The original vision was to have a single book that followed the vision for POSA5. The idea was, having introduced the concepts, principles and techniques for writing and organising patterns, we would demonstrate them in action on a large example: a pattern language for distributed computing, along with a pattern story that illustrated its application in practice.

As you might guess, this would make for a very large book!

POSA4 is about distributed systems - what kinds of distributed systems does the book focus on?

…we have tried to document the broad range of architectural concepts that can be found in classic RPC-style systems, contemporary Web applications, message-based systems, mobile computing, classic N-tier systems, and so on. We focus specifically on architectures and architectural knowledge that are based on proven practice....We cover both application and middleware architecture, with an interest in both the development of new systems and the continued development of existing systems.

The style of the book is different from the earlier volumes. POSA4 describes 114 patterns, whereas the three earlier volumes contained 44 patterns altogether. The previous volumes dived deep into each pattern, but since most patterns in POSA4 have been published before in other works, details of the patterns were left out in exchange for exploration of the relationship between them.

By contrast, POSA4 is intended to offer architects and developers a broader, big-picture view of the patterns involved in contemporary distributed computing architecture. The emphasis is on how the patterns relate, where one pattern fulfils the detail of another or provides an alternative to another, so this means that the connections are emphasised and the detail of each pattern is reduced.

However, the lesser level of detail does not necessarily mean that the core idea of each pattern becomes fuzzier:

The patterns are no less accurate for their brevity — and in some cases their descriptions are also more precise — but they are summarised and much of the plumbing detail is omitted.

In order to keep the description of each pattern compact, the book uses diagrammed sketches and pseudocode instead of UML-diagrams and fully blown C++ or Java examples. References are given for readers who wants to dive deeper into a particular pattern.

We asked Kevlin if there were any particular patterns that he felt had been lost or misunderstood, that they were particularly pleased to bring forward in the book?

There are a couple of patterns that are quite humble but have some significant and very influential consequences in modern design approaches.

The first is what we have termed Explicit Interface, which in essence is the notion of factoring out a separate interface, decoupling it fully from its implementation. The approach is appropriate for declared type systems and has existed since RPCs, and we find it commonly in modern statically typed languages, namely the ‘interface’ construct. However, the point of the Explicit Interface pattern is the design sensibility behind using such mechanisms and focusing on a separation of concerns. In spite of an increase in interface-based programming in recent years, many programmers still use pure interfaces — whether in the form of the ‘interface’ construct or in terms of fully abstract classes — in a more coupled fashion than necessary, if at all.

The second is the idea of a Context Object. Like the idea of interfaces, the idea of context objects has been around for a long time (it’s present in Scheme’s eval procedure and can be found lurking in the Gang-of-Four Interpreter pattern), but it has only recently been documented and reasoned about as a pattern in its own right. The write up in POSA4 is just the latest in a line of many different write ups, which includes one by me and a separate one by Doug! A context object allows an object, component or whole subsystem to be parameterized with execution details, such as configuration, credentials, lookup services, etc, independently of other parts of the system. This isolation promotes independence between components, simplifies testing and eliminates a class of problems and/or performance bottlenecks that might otherwise be introduced in a multi-threaded environment. It is often seen as an antidote for many of the problems that using Singleton brings in its wake (and, as an aside, Singleton was one pattern we did _not_ include in the book :->).

The fifth and last book in the series is a book about patterns and pattern languages. It shows how to document, organize and use patterns; how to build relationships between patterns and how to turn those relationships into a pattern language.

Before POSA5 the conceptual discussion of patterns was scattered across numerous works and the heads of various individuals, both within and outside the patterns community. Each book, paper or presentation that presents a set of patterns introduces the pattern concept with a different slant, one that may differ from others anywhere from slightly to radically. Different sources place different emphasis on different aspects, such as the context in which a pattern occurs, the use of pattern languages, the role of forces in a pattern, the social or technical goal of patterns, and so on.

Kevlin concludes:

POSA5 […] is for practitioners who are interested in exploring the pattern concept further. In other words, this book is targeted at software practitioners who have already had exposure to patterns in some form — whether GoF, POSA, Core J2EE, etc — and want to know more about patterns.

No comments

Watch Thread Reply

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.