The .NET/Java Architect Training Program: Part II

In a previous post on the subject, I promised to expand on suggested content for a "Distributed Systems Architectures Workshop". So here is a short drill-down:

Even though most of the time should be spent on working, designing, and evaluating architectures, there's probably a little room for theory.

Module 1: The Basics (probably not more than half a day)

• What's software architecture
• The software architect role
• Activities
• Scenario based architectural design
• (documenting software architectures)
• Agile SDLC and architects

Module 2: Distributed Systems Background

Understanding the Fallacies of Distributed Computing Distributed architectures styles. It is important to understand the different architectural styles that can be used to implement distributed system. Within this, topics like clustering, computation and data grids, messaging , publish subscribe, etc should also be discussed.

• Client-server. The most basic distributed architectural style. It is based on the N=1 premise and isn't fit for most of today's challenges. However, it is still an option for some types of projects.
• Pipe and Filters . Not necessarily a distributed style, but it can be applied in distributed space.
• N-Tier. That's actually a moniker to anything where N>2 but usually it pertains to 3-tier architecture (front-end, server, database) or the Internet 4-tier version (client, webserver, application server, database).
• Event Driven Architecture
• Service Oriented Architecture
• REST
• Space-based architectures. Like JavaSpaces and its implementations such as Blitz (open source) and Gigaspaces (commercial).
• Peer-to-Peer. You know that's what all those file sharing tools use.

Distributed Consensus

• 2-phase commit, used by XA and COM+ distributed transactions.
  
• 3-phase commit, considered a non-blocking protocol (vs. 2-phase commit which is a blocking protocol).
  
• Paxos commits
  
• Sagas
  
• Eventually consistent (BASE) -- Basically Available Scalable/Soft state Eventually Consistent. An alternative to distributed transactions used by a lot of Internet-scale companies (see a post I made on eBay's architecture )
  

Module 3: Workshop. Most of the days should be focused on actually working to design architectures.

I would think that this would be handles best by working in groups. e.g. having each group focus on one architecture style.

The groups would be given a scenario which covers some architectural concern (integrity, performance, scalability, availability etc.) and would try to design strategies to handle the scenarios within the constraints of the architectural style. Present that to the other groups and then have a facilitated discussion on the
pros/cons of each strategy. The scenarios should be based on a large enough story to allow meaningful architectures to emerge (e.g. you can see the 10 Scenarios in my SOA Patterns Presentation)

Any comments or other ideas for what's needed for this kind of a workshop are welcomed.

Posted by Arnon Rotem-Gal-Oz at 09:54 AM  Permalink