In the book "97 Things Every Software Architect Should Know" (O'Reilly, 2009) I wrote about the importance of design patterns as a useful means of communication between architects and developers. Equally important to patterns is an understanding of AntiPatterns - things that we repeatably do that produce negative results. AntiPatterns are used by developers, architects, and managers every day and are one of the main factors that prevent progress and success. In this session we will look at some of the more common and significant development and architecture antipatterns. Through coding and design examples, you will see how these antipatterns emerge, how to recognize when the antipattern is being used, and most importantly, how to avoid them. By attending this session, you will be part of a movement to reduce the AntiPattern catalog from hundreds of entries to only a few.

Agenda - What are anti-patterns? - Factors that cause anti-patterns - Common software and architecture anti-patterns

I have selected 7 of the most common anti-patterns I see continually in the industry and in my travels. We will be going into the details of each of these anti-patterns.

One way to stop a conversation dead while at a party or gathering is to mention you are a software architect. Why? Because it takes about an hour (complete with Powerpoint slides) to explain what you do for a living. By then the person you are talking to is so bored they would rather sit in a corner licking nine-volt batteries. The problem is that no one inside or outside our industry really knows what a software architect is or what they do. In this highly interactive (and slightly humorous) session we will take a deep dive into the role a software architect plays in the IT industry. We will explore the characteristics an architect needs to have, and the elements that make a good architect and a bad architect. Through amusing antidotes and real-world examples, we will see how to become an effective software architect and help shape the industry in terms of the role and title of software architect.

Agenda During the introduction we will talk about the roles an architect plays, architect certification, and the decisions an architect typically makes. We will then take a deep dive into the qualities of a software architect, including Leadership and Communications, Technical Knowledge and Breadth, Domain Knowledge, and Methodologies. Interspersed into the mix will be some amusing anecdotes of my experiences as an architect, with a few jokes and humor thrown in for good measure

In previous years I have given sessions related to my book "Java Transaction Design Strategies", where I have reviewed the basics of programmatic and declarative transactions and outlined the basic patterns described in the book. In this new session for 2009 I will focus on some of the pitfalls encountered while dealing with transactions and then how to develop an effective transaction strategy. I will start this session by describing and illustrating some of the common pitfalls I continue to see in both Spring and EJB. I will then describe four common transaction strategies you can use and implement, including a transaction strategy for high-speed transactions, a transaction strategy for client orchestration, a transaction strategy for use with API's, and finally a strategy for highly concurrent environments.

Note: This session assumes you know a little bit about transactions and have been using them in either Spring or EJB. It is not intended to be an introductory session on how transactions work. You can obtain a free PDF download of my transaction book at http://www.infoq.com/minibooks/JTDS to quickly come up to speed with transactions.

Agenda - Introduction - Common Transaction Pitfalls - API Transaction Strategy - Client Orchestration Transaction Strategy - High Concurrency Transaction Strategy - High Speed Transaction Strategy

There's no doubt about it - messaging is quickly becoming a standard part of most application architectures, particularly as more and more companies struggle to find ways to integrate heterogeneous environments due to mergers, acquisitions, or to streamline existing application portfolios. The Java Message Service (JMS) API allows Java applications to implement messaging using a standard API, therefore removing the dependency of any particular messaging provider. In this introductory session we will take a look at the basics of messaging and the JMS API. I will start by discussing the different messaging models, the structure of a basic JMS message, and the JMS API interfaces and how they interrelate. Then through interactive coding I will show the basics of sending and receiving messages using the point-to-point messaging model and how to do request/reply processing. NOTE: this session is meant to be an introduction to messaging and JMS - no prior JMS or messaging experience is needed for this session.

Agenda: - Messaging Introduction - JMS Message Types - Primary JMS Interfaces - Configuring Queues and Topics - Sending and Receiving Messages - Request/Reply Messaging

This session covers some of the more advanced features of JMS messaging, and is intended for those who are familiar with JMS and messaging in general. Some of the topics I will be covering in this session include message grouping (where I will demonstrate sending a large JPG image using messaging), transacted sessions, client-based acknowledgement, and some various messaging design considerations and things to watch out for from a design and coding perspective. I will be doing live coding demonstrations to illustrate the techniques described in this session. Although this session is entirely JMS provider agnostic, I will be using ActiveMQ, a popular open source JMS provider, during the live coding demonstrations.

Agenda - Details behind the acknowledgement modes - Message grouping / sending images and documents - Transacted sessions - JMS Design Considerations - Common Messaging Pitfalls

Ever wonder how to accurately calculate high availability and continuous availability? Ever wonder the real difference between clustered and active/active topologies? Ever wonder why the extraordinary cost and effort to put a CA environment in place rarely yields the expected results? Ever wonder how to make CA work without having to sit through vendor presentations or demos? Ever wonder why businesses not needing the "6 nines" of availability commonly found with CA environments are still pursuing CA? Ever wonder if there's more to CA than numbers, calculations, and topologies? Ever wonder what the future holds for continuous availability computing?

While some industries such as Telecommunications have solved the continuous availability issue, other industries such as banking, insurance, and financial markets still find continuous availability a challenging and complex task. These industries typically have a complex and heterogeneous assortment of technologies, platforms, and architecture layers which make designing and implementing continuous availability particularly challenging. Introduce Service Oriented Architecture into the mix, and the issue becomes even more complex.

Come to this vendor-agnostic session to see some of the answers to the mysteries surrounding the black art of continuous availability; all is not what it seems....

While the technical solutions to implement continuous availability are widely known and generally understood, the limitations and constraints of continuous availability generally are not. Just because the technical architecture supports continuous availability does not mean that the applications and systems using that infrastructure can leverage it. In fact, as you will see in this session, application architecture ends up playing an important part of a holistic continuous availability solution.

In this session I will focus on the challenges faced by the financial services industry with designing continuous availability in the application and services layer and how those challenges are addressed. I will start by discussing the use cases and rationale surrounding continuous availability in the financial services industry, then move on to discussing the limitations and challenges faced when designing and implementing continuous availability, both from the technical and application architecture perspective. I will then discuss the vendor-agnostic techniques for resolving the issues and challenges discussed. To bring a real-world focus to this session I will meld into the discussion my experiences of how one of the world's largest banks resolved the issue of continuous availability in a large-scale Service Oriented Architecture environment.