Events

Every year a lot of interesting conferences and events on software engineering take place world-wide, especially on Object-Oriented Programming and related topics. Unfortunately, there are too many events. It is impossible to attend even the most exciting ones. The big ones like JAX, OOP, OOPSLA or JAOO are cool because they offer conference programmes where everyone should be able to find her or his favourite topics covered by some superb experts. And, you can meet so many people there. Definitely, a good opportunity to strengthen your social network. On the other hand, big conferences tend to be more formalized, organized, and commercialized. In the last few years, I increasingly enjoy attending that small events which offer excellent topics and speakers, somewhere in small places. That's one of the reasons why I am really sorry that the TOOLS conferences have been cancelled a few years ago. These events organized by Bertrand Meyer were absolute highlights. Fortunately, there are other small events that I would recommend. One of them is coming really soon and I will be personally involved as a speaker. It is the EXPO-C conference in Karlskrona, Sweden, to be more concrete. I will give a full day tutorial on Software Architecture and also speak on SOA. But that's not the reason why I am blogging about this event. They really got exciting speakers, talking about things such as Ruby, C#, Haskell, Software Architecture. This is more an event on languages in a broad sense, as the organizers explain. And of course, it is an event in Sweden. I have never been there, but I guess you'll meet the same friendly and smart people there as in Denmark, Norway, or Finland. If you got curious, here is your chance. You should definitely take a look at:

http://www.expo-c.se

Send all Market Analysts to a lonely Island!

This time, I like to discuss something absolutely different. A few weeks ago one of those famous market research companies - I won't tell you the name - announced that they have investigated interesting facts on the relevance of Podcasts. The result was amazing: only some weird techies are listening to Podcasts, while the vast majority of people is not interested in this Podcast thing. As a consequence, there is no business opportunity in this area according to the infinite wisdom of market analysts. A few days later, a more serious analysis found out that the the irrelevance of Podcasts was absolutely untrue. In the US alone millions of people are frequently enjoying Podcasting. I would have surely guessed that, as Podcasts are a kind offline radio and cover as many topics as one could propably think of. This reminds me of an Ovum report several years ago where they compared all these cool Remoting Middleware technologies (RMI, DCOM, CORBA). They forecasted that DCOM will be the dominant technology in the future, which is ... now. BTW, can you remember this DCOM technology ? DCOM propably stands for Dead COM. Can you remember the prediction that .NET and Java will both share 50% of the market. And all these predictions that SOA will make everything else obsolete? All of this could be quite entertaining. Unfortunately, in software development projects I constantly get pointers from managers that refer to these market analysis reports. Even software developers and architects believe in this crap. I understand that people are searching for help when faced with uncertainty. In market and technology reports you can find all these technology evaluations, product comparisons, and market forecasts. And, even worse, for almost all predictions in these reports you are able to discover additional reports, that tell exactly the opposite, at least, if you are digging long enough. Reminds me of Winston Churchill who once mentioned that he only believes his own wrong statistics. Sometimes I ask myself, if someone in this universe has ever tried to investigate the value of market reports. How many predictions turned out to be true or at least almost true? The problem of all future forecasts is that you can only base your statements on a small amount of facts and a large amount of opinions. Opinions are just that. They contain personal preferences, try to project past developments to the future, and use linear models. The reality, unfortunately, is often disruptive and non-linear. New technology developments appear, some of these developments become hypes, while others disappear and may re-appear some years later. What can be done in a stage of uncertainty? Base all your architecture and technology decisions on two things, the facts you know and the risks you must address. If necessary, hide technologies which might be subject to change, using adapters or other means. Everything is better than gambling. And, even if it sounds over critical, using marekt and technology reports is like gambling. Why do you think, these guys have become market analysts and not software engineers?

SOA is NOT about Web Services

Recently, I have been involved in a couple of discussions where people complained about the SOA Hype and all those enthusiastic XML Web services celebrations. I wrote an article on SOA for the IEEE Software Issue on Future Trends of Software Architecture which you might read on my web site. Here are my two cents.

• XML Web services define a kind of meta middleware dedicated to integration problems. If you need to communicate between a Java EE application and a .NET application then XML Web services represent one possible option. There are other alternatives in this scenario such as CORBA or RMI adapters. However, in most situations when you have to cope with heterogeneous systems without control which applications will have to be integrated, then XML Web services are the clear choice.
• Service-Oriented Architecture as the name implies is not dependent on a specific implementation technology such as XML Web services. Likewise, Object-Oriented Programming is not dependent on Java. Instead, I consider SOA as a set of architectural principles that emphasize loose coupling. I will explain this point in the remainder of this posting.

A typical example for a SOA-compliant technology is regular e-mail. I'd like to present some of the properties of SOA systems using this simple show case.

SOA requires explicit, role-based interfaces for services. Clients do only see interfaces and never implementations. As the bridge pattern is applied, client and server interfaces are implementation-agnostic with respect to each other. Communication between client and interface is provided by standardized protocols.

Applied to e-mail: Mail clients communicate with mail servers using POP3, IMAP or SMTP. As there are no implementation dependencies, a mail client does not need to care about the implementation of the mail server, and vice versa. Thus, you are completely free to use any mail client and mail server if your communication peers abide to the standard protocols and standard interfaces. e-mail is a little bit special in that the services and their semantics are predefined.

SOA communication relies on asynchronous message exchange albeit there might be transparency layers on top providing remote method invocation based communication. Messages are in general dynamically routed, possibly passing through indirection layers.

Applied to e-mail: mails are passed as messages from their origin (client's outbox) to their destination (recipient's inbox) passing different intermediate layers. That means for example that you are not blocked even if your communication peer hasn't yet received your mail.

SOA messages denote standardized documents with different sections such as body or headers. Multiple messages may be used to transmit data in chunks, if necessary. The header usually contains data related to cross-cutting concerns such as routing, attachments, security. The body content may be predefined between the communicating peers or be totally applications-specific.

Applied to e-mail: mails are sent using mail header and mail body. All content must comply with MIME types. That is the only constraint but is not really a constraint in fact.

SOA message exchange patterns relate different messages with each other to introduce additional communication styles such as request/response or oneway. Another example is the return of fault messages upon error situations.

Applied to e-mail: requiring a receiver to send an acknowledgement is the typical example. And what about failure scenarios? When a receiver is not recognized an error message is returned to the sender.

In SOA systems business processes are first class entities. Business processes introduce domain specific languages to combine distributed services to whole workflows. Note that business processes are not just sequential invocations of services. Instead, properties might be applied to complete workflows such as transaction contexts or other kinds of coordination.

Applied to e-mail: this is not directly supported. Instead, such workflows are implemented by applications or human interaction.

This concludes my discussion on e-mail as a SOA implementation example. Another example for a SOA based implementation technology is Messaging middleware such as MSMQ or MQSeries.

Loose coupling is the central mantra of all SOA architecture principles. Don't let vendors or press media fool you. SOA is NOT about XML Web services. Instead, it denotes an architectural paradigm for distributed computing that can be implemented using different technology options. Does it solve all problems? Ideally, it is applicable to all problem domains with inherent loose coupling of distributed entities. But it is counterproductive to apply the SOA paradigm in problem contexts where tight coupling is mandatory such as in several embedded or realtime systems. One could argue that in the end every distribution middleware relies in its bottom layers on SOA based communication such as TCP/IP. But that argument resembles the argumentation that we could implement all our software systems using machine code.

Bottom line: Always use the abstraction layer that helps building your system effectively and efficiently. Don't accept software development projects to be influenced by inadequate personal technology preferences or political decisions.

Architect's Book Corner

A software architect as mentioned in one of my previous posts should keep herself/himself knowledgeable about all important topics in this area. One way is to attend courses, conferences, and trainings. But often can we afford to spend a couple of days for attending such an event? Another way is to read relevant books. The problem with the latter approach is that there are so many books on software architecture. So, which ones should we read? Here are some recommendations, a list of my favorites. Please, keep in mind that this list is subjective and incomplete. And, I have constrained myself on english literature. So, you might definitely ask some other architects for their book recommendations.

General books on software architecture:

• Software Architecture in Practice ( http://tinyurl.com/qm2dl ) by Bass, Clements, Kazman introduces software architecture and also reveals in-depth perspectives. A must-read if you ask me.
• Beyond Software Architecture: Creating and Sustaining Winning Solutions (http://tinyurl.com/r3ls5 ) by Luke Hohmann does not focus on software architecture technology but also on related issues that influence software architecture.
• Product-Line Engineering has become an important topic for software engineers: Jan Bosch is my personal guru on this subject: Design and Use of Software Architectures (http://tinyurl.com/mffo8 ).

Patterns

• Design Patterns: Elements of Reusable Object-Oriented Software (http://tinyurl.com/nq8yq ) is the seminal book on design patterns by Gamma, Helm, Johnson, Vlissides. For me the content of the book comprised mandatory knowledge for every software architect.
• Our own POSA series extended the GoF book by architecture patterns, added a new documentation form, and also covered software architecture in more detail. Volume 1 (http://tinyurl.com/qk87n ) focuses on general patterns. One comment: I don't like when people call volume 1 the Buschmann book as all authors were contributing equally. The order of author names is structured lexicographically. For instance, I wrote more patterns than anyone else. Thus, call it the POSA 1 book to respect the "et al" in "Buschmann et al" :-). Volume 2 (http://tinyurl.com/rge3o ) concentrates on patterns for concurrent and networked systems. Volume 3 (http://tinyurl.com/qcvgv ) covers resource management. Expect more to come in the near future.
• In Remoting patterns (http://tinyurl.com/prnnz ) and Server Component Patterns (http://tinyurl.com/q9a52 ) you'll find some basic ingredients for remoting middleware and application servers.
• For messaging middleware the book you should read is Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions. By Gregor Hohpe and Bobby Woolfe. (http://tinyurl.com/q2xea ).
• Analysis patterns are more on the domain-level. Another excellent book by Martin Fowler (http://tinyurl.com/m2nfm ).
• For Java EE developers the Core J2EE Patterns book provides essential best ptactices for daily work (http://tinyurl.com/mvtbn ).
• .NET programmers can obtain similar books through http://tinyurl.com/rfyw9 .

Model-Based and Aspect-Oriented Software Development:

• As soon as Markus' book on MDSD is available in english I can wholeheartedly recommend to read it (as I've read the german edition): http://tinyurl.com/q9a52 .
• Software factories extend MDSD by mapping industrial production paradigms to software engineering. Written by some prominent people such as Jack Greenfield the book on software factories is excellent: http://tinyurl.com/ntec6 .
• Generative Programming: Methods, Tools, and Applications was written by Uli Eisenecker and Krzysztof Czarnecki, two friends of mine. Excellent book on generative programming but contains very complex C++-based stuff (http://tinyurl.com/obxqn ).
• In Aspect-Oriented Analysis and Design AOP is considered from a more architectural approach (http://tinyurl.com/o3o2v ).

Process-related issues are important for a software architect. Here are some books on my list:

• Martin Fowler wrote THE book on refactoring which was entitled Refactoring: Improving the Design of Existing Code (http://tinyurl.com/r6s5z )
• An new one is Joshua Kerievsky's Refactoring to Patterns which introduces pattern-based refactoring (http://tinyurl.com/qam9h ).
• Test-Driven Development was introduced by Kent Beck whom all of you might know as the "father" of eXtreme Programming (http://tinyurl.com/ot8k3 ).

Modelling and Engineering Process:

• UML 2.0 in a Nutshell is compact and nonetheless offers a complete overview.(http://tinyurl.com/pasyk ).
• You need a lightweight overview of the Unified Process. Here is the way to go (http://tinyurl.com/q7xul ).
• Extreme Programming Explained : Embrace Change (2nd Edition) by Kent Beck is the source for learning eXtreme Programming (http://tinyurl.com/rwcmn ).
• Ken Schwaber and Mike Beedle in Agile Software Development with SCRUM tell you all to know about SCRUM (http://tinyurl.com/o7cer ).
• Agile development in general was perfectly described by Alistair Cockburn in Agile Software Development (http://tinyurl.com/raghe ).
• Requirements Engineering is often treated with unsufficient care. Thus, read the book Requirements Engineering (http://tinyurl.com/qeald ).
• The bible of writing good use cases? No question. This is definitely Alistair Cockburn's Writing Effective Use Cases (http://tinyurl.com/m5tq2 ).
• CMMI is widely desribed and explained in CMMI : Guidelines for Process Integration and Product Improvement (http://tinyurl.com/p9xsm ).

Domain Driven Design could also be placed into the category of pattern books. I think, it should stand alone as it introduces the new idea of domain languages in an outstanding way

• (http://tinyurl.com/rycko ).

OO and more

• The magic of components. Clemens wrote the seminal book on this topic. Some years old but still worth reading: Component Software: Beyond Object-Oriented Programming (http://tinyurl.com/pyo4u ).
• Effective Java by Joshua Bloch is also a good lecture for C# gurus: http://tinyurl.com/pyo4u .
• One of my favorites on Concurrent Programming: Doug Lea's Concurrent Programming in Java(TM): Design Principles and Patterns (http://tinyurl.com/ok4nd ) .
• On Service-Oriebted Software Architecture there are no really ubiquitous books. Read my articles on this subject (http://www.stal.de). As an intro I recommend Thomas Erl: Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services (http://tinyurl.com/n5oxw ).
• Interested in all these lightweight containers? Read the book by the fathers of Spring, Expert One-on-One J2EE Development without EJB (http://tinyurl.com/lrvne ).
• They have published widely accepted books on Ruby and Programming. But all their other books are also worth reading. The Pragmatic Programmers is a source for excellent and pragmatic books: http://www.pragmaticprogrammer.com/.

Miscellaneous

• Last but not least. It should be mandatory for computer science students to read authors like: Scott Adams (Dilbert), Douglas Adams (Hitchhiker's Guide to the Galaxy), Tom Demarco, and Terry Pratchett (Discworld). Not to forget Stanislaw Lem who recently died. I also consider Star Trek as a foundation which implies you should also read the literature on physics (such as Feynman). But let me stop here :-)

All these books are books I've read in the last years. I recommend them personally. No, I won't get any fees from the publishers or authors. If you like to add some of your personal favorites, please, do so using the possibility to write comments.