Category Archives: Blog

We are announcing a 10% discount for early registration that goes to September 15th.  Register before August 31, and you’ll receive 10% off the price.

You can also receive a volume discount for sending 3 or more people to the training (10%).

Sign up while the tickets are hot!

Advanced Distributed Systems Design using SOA & DDD with Udi Dahan, The Software Simplist

Monday, October 13, 2008 at 08:00 AM – Friday, October 17, 2008 at 05:00 PM (CT)

Austin, TX   

Introduction
Designing large-scale distributed systems is hard. New technologies make it easier to comply with today’s communications and security standards, but don’t auto-magically give you a robust and scalable system. Join Udi for a course packed with the wisdom of companies like SUN, Amazon, and EBay.

Tried-and-true theories and fallacies will be shown, keeping you from making those same costly mistakes today. Communications patterns like publish/subscribe and correlated one-way request/response will be used in conjunction with advanced object-oriented state management practices for long-running workflows. If you enjoy deep architectural discussion, if you are in charge of building a large-scale distributed system, if you want to know more about how the big guys run their systems, this is for you.

About Udi
Udi Dahan is The Software Simplist, recognized by Microsoft Corporation with the coveted Most Valuable Professional award for Solutions Architecture now 4 years running. Udi is a Connected Technologies Advisor working with Microsoft on WCF, WF, and Oslo. He also serves as a member of the Patterns & Practices Advisory Board for the CAB and Prism. He provides clients all over the world with training, mentoring and high-end architecture consulting services, specializing in Service-Oriented, scalable and secure .NET architecture design.

Udi is a member of the European Speakers Bureau of the International .NET Association, an author and trainer for the International Association of Software Architects and a founding member of its Architect Training Committee. He is also a Dr. Dobb’s sponsored expert on Web Services, SOA, & XML.

Presenting at international conferences like TechEd USA, SD Best Practices, DevTeach Canada, Prio Germany, Oredev Sweden, TechEd Barcelona, QCon London, and TechEd Israel – Udi covers in-depth mission-critical topics like durable services, persistent domain models, and multi-threaded occasionally connected clients.

Audience
This workshop is targeted at team leads, application and solutions architects, as well as technologists who are involved in making decisions about the overall system design of software products and projects.

Course Topics

Module 1: Distributed Systems Theory
Decades of distributed systems development have taught us many lessons. In this module we’ll cover many historical mistakes as well as proven best practices for scalable and robust design. Topics include:
  • 8 fallacies of distributed systems
  • Transactions

Module 2: Coupling: Platform, Temporal, & Spatial
Loose coupling has become the watchword of complex systems development, yet few understand its multiple dimensions. In the module we’ll be covering the three different dimensions of coupling as well as patterns for dealing with them.
  • Platform Coupling – XML/SOAP
  • Temporal Coupling – Synchronous/Asynchronous
  • Spatial Coupling – Endpoints/Topics

Module 3: Asynchronous Messaging Patterns
Although scalability is achieved through the use of asynchronous message passing, more advanced message exchange patterns are required to handle today’s complex integration scenarios. This module will cover the most commonly used patterns:
  • One way
  • Correlated Request/Response
  • Publish/Subscribe

Module 4: Bus & Broker Architectural Styles
Enterprise Service Buses are all the rage these days. In this module we’ll be covering what’s the difference between the Bus architectural style, and the more well-known Broker, found commonly in many EAI projects. Topics will include:
  • Architectural advantages and disadvantages
  • Technological advantages and disadvantages

Module 5: SOA Building Blocks
One of the goals of SOA is to develop systems which are more closely aligned with Business. In this module we’ll be covering an analysis methodology from moving from the business domain to executable systems that comply with all the principles of loose-coupling.
  • Business Services
  • Business Components
  • Autonomous components & Queues

Module 6: Scalability and Flexibility
In order to enable agility, services must be able to scale up, out, and down quickly. In this module we’ll see how autonomous components can be configured including transactional and durable aspects of message handling.
  • Configuring autonomous components
  • Scaling up and out

Module 7: Long running processes
The distributed communications patterns wouldn’t be complete without a discussion on orchestration. In this module we’ll see how to manage the state of long-running distributed communication flows as well as:
  • Encapsulating process logic
  • Advantages & disadvantages of orchestration

Module 8: Service / Autonomous Component Solutions
As developers go to implement autonomous components, guidance is required as to which concepts need to implemented in which project, what dependencies are there between projects, and how to bridge the worlds of messaging, business logic, and reporting. Topics include:
  • Messages + Handlers
  • Databases

Module 9: Service Layer – Domain Model Interaction
Logic-rich services require the use of advanced techniques for logic componentization. The Domain Model Pattern enforces a high level of Separation of Concerns, yet it must eventually be connected with Service Layer code that supports many concurrent users. In this module, the topics covered will include:
  • Domain Model introduction
  • Testing Domain Models
  • Optimistic, Pessimistic, and Realistic Concurrency Models

Module 10: Creating High-Performance Domain Models
The strong separation between the Domain Model and the database which stores and retrieves its data may enable a high level of testability, yet often causes performance problems. In this module, we’ll see the various aspects impacting the performance of persistence:
  • Transactions and Isolation Levels
  • Lazy Loading, Eager Fetching
  • Databases Tips & Tricks

Module 11: Web Services and User Interfaces
The ease of interacting with users over the web drives the need for service to UI interactions. Also, many integrations require exposing synchronous web services to customers. In this module, we’ll see what is required in both cases:
  • ASP.NET 2.0 Asynchronous Tasks
  • Rich Internet Applications and Services
  • Web Services for integration

Module 12: Smart Client / Service Interaction
The publish/subscribe semantics with which services communicate require smart clients to perform a great deal of background work. Also, certain service contracts lead to more performant clients. In this module, we’ll cover the first part of these interactions:
  • Multi-threaded client challenges
  • Client-friendly Service Contracts
  • Service Agents and Client Repositories

Module 13: Notifications & Smart Clients
After Message Handlers in the Service Layer create or update the relevant Model objects in the client Repository, Supervising Controllers are in charge of getting Views to show the updated data. In this module, we’ll describe the parts and interactions of these flows:
  • Client-side Model Objects
  • Supervising Controllers
  • Views and their Interfaces

Module 14: Commands & Smart Clients
Capturing user intent and synchronization between views are at the core of smart clients. After describing solutions that use Events on the View Interfaces, the Command Pattern will be introduced to further decrease coupling between Supervising Controllers. In this module, we’ll describe the parts and interactions of these flows:
  • View Interfaces, and how Entity Cloning affects them
  • Supervising Controllers and clone reconciliation
  • Commands, and Event-Based programming

The Tarantino project is a collection of libraries and tools to facilitate change management and development

The Tarantino project contains a number of useful components for:

• Database change management
• Application deployment
• NHibernate
• Configuration
• Scheduling
• Caching
• Web Farm management

Tarantino is currently being developed and extended.  If you would like to contribute, the most welcome patch would be Oracle support for the database migrations.  Currenlty, only SQL Server is supported.

Headspring Systems is proud to host Udi Dahan in Austin, TX as he teaches his Advanced Distributed Systems Design using SOA & DDD course.  It will be a full week of advanced SOA goodness.  Go to the course page for all the details as well as the curriculum outline.

eventbrite_event = “158018638”;
eventbrite_view = “tickets”;
eventbrite_width = “600”;
eventbrite_height = “300”;
http://www.eventbrite.com/static/js/events.js

Many times, I’ve heard that the best thing about IoC is that it enables testability.  When dependencies are injected into a class, it’s easy to test that class.  Testability is a side-effect of good design.  The lack of testability signifies a bad design, but the enable to test a class does not, by itself, signify a good design.  The causality is one-way.

Let’s take a look at an example:

public class MissileLauncher{
    private INavigator _navigator;
    public MissileLauncher(){
        _navigator = new MissileNavigator();
    }
    public void Launch(){
        //get direction guidance from _navigator and launch a missile
    }
}

This can be a good design or bad design depending on your needs.  We are coupling to an interface, INavigator, but we are also coupling to a specific implementation class, MissileNavigator.

If MissileLauncher can’t do its job without MissileNavigator, then this coupling makes sense, and the class should be tested together with MissileNavigator.  Other examples are operations on domain objects:  The logic makes no sense without the Customer object, specifically, so the operation should be tested with the real Customer, and not a mock object.

If, however, MissileLauncher is a concept orthogonal to MissileNavigator, then INavigator adequately illustrates the necessary interaction.  In this case, coupling to MissileNavigator is detrimental to our design if the MissileLauncher only depends on the operation exposed by INavigator.

We would change this class to the following:

public class MissileLauncher{
    private INavigator _navigator;
    public MissileLauncher(INavigator navigator){
        _navigator = navigator;
    }
    public void Launch(){
        //get direction guidance from _navigator and launch a missile
    }
}

Here, we have inverted the control over locating or creating the dependency.  Now MissileLauncher does not care about the actual class, just that it receives an instance of the interface.  With the interface it can do its job.  This is a better design if you have determined MissileLauncher’s behavior is orthogonal to the actual MissleNavigator class.  Again, you have to make many hard decisions about design.  Do you couple. . . or not. 

In order to do anything useful in software, you must couple.  You must couple to something. 

The coupling determines how you will test.  If you couple to a concrete class, you will test the code together with that class.  If you only couple to an interface, you can test the class with only the interface.

Testability is a by-product of inversion of control, and design is the driving factor to invert the control or retain it.  Don’t invert all control just so each class can be tested independently of all other classes.  You must decide where coupling is appropriate and where it is not.

Last night I spoke in Austin, TX at the Austin .Net User Group, which is the user group I’ve been leading since 2005.  It was the first of 4 user group talks this week.  I’m taking one of my Tech Ed 2008 talks out on an INETA tour.  I’m representing the INETA speakers bureau and visiting Austin, Wisconsin, North Carolina, and Arkansas.

My topic is as follows. If you are in any of these cities, come on out to the local .Net User Group.

TDD, DI, and SoC with ASP.NET MVC

Spelled out, it is test-driven development, dependency injection, and separation of concerns with Active Server Pages .Net Model View Controller. This talk will dive into how to design a presentation layer using ASP.NET MVC. In today’s industry, TDD, DI, and SoC are proven concepts that lead to more maintainable applications. Along with demonstrating how to use these techniques with ASP.NET MVC, we will discuss just what concerns should be separated. This talk provides a unique perspective on separation of concerns and uses TDD and DI to make it happen. MvcContrib is used in all the demos.

About Jeffrey Palermo
Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Subscribe to Jeffrey’s blog feed here: http://feeds.jeffreypalermo.com/jeffreypalermo

South by Southwest (SXSW) is set for March 13-17, 2009 in Austin, TX.  From the website:

” The SXSW INTERACTIVE FESTIVAL celebrates the creativity and passion behind the coolest new media technologies. In addition to panel sessions that cover everything from web design to bootstrapping to social networks, attendees make new business connections at the three-day Trade Show & Exhibition. The newest element of the event is ScreenBurn, which adds specific gaming industry programming as well as a three-day Arcade to the mix.”

Voting has begun for the sessions that have been submitted for the conference.  I submitted a session entitled Managing High-Performing Agile Teams.  SXSW has a community voting process, so you can go online and vote for the sessions you would like to see at the conference.

I am hiring for the following position.  This person will report directly to me and work on a team that I am coaching.  If interested, you are applying to be on an extreme programming team.  We are very heavy into automation and frictionless development and deployments. 

—————————————–

Headspring Systems is looking for a talented and exceptional Agile Software Tester. Ideal experience should include extensive test automation and experience with extreme programming (XP).  Browser testing such as Watir or Selenium is desired.

Job Responsibilities

• Work face-to-face in Austin, TX on a high-speed agile engineering team using one-week iterations.
• Participate in all activities of development including user story definition, estimation, automated testing, and deployment.
• Enhance existing automated processes to streamline unit testing, integration testing, database change management, and application deployment.

Job Requirements

• Bachelor’s in Computer Science or equivalent working experience
• Minimum of 2 years experience in Microsoft technologies
• Minimum 1 agile project completed or extensive personal study.
• Strong ability to analyze business requirements, formulate multiple testing options, and effectively communicate these options to clients
• Self-motivated – able to work cohesively in a team environment and motivate the team
• Continuous learner that constantly seeks to improve by such means as reading books and blogs and participating in the development community

Headspring Culture
Our work environment is a relaxed one. Our office is open so it gets a little noisy at times but we like the energy this creates. We like to have fun, but we also work hard, we like to have a balanced work life. Excellent medical benefits are also offered. To learn more about our organization, please visit us at www.headspringsystems.com

To apply:
Please send your resume via email: jobs@headspringsystems.com

In your cover, please include your high/low salary requirements and please explain why this role seems like a good match for you.

I started trying out Twitter in March, and I’ve been a very light user.  Now, however, I find myself posting more messages.   Because I’m firmly in software consulting, that’s what I think about all day, so my tweets tend to be about how to create quality software or how to lead software projects.

You can find me at @jeffreypalermo

Part 1 – Part 2 – This is part 3. part 4. – My RSS feed

In my previous installments, I described what has become my approach to defining the architecture for an application.  Based on feedback, I’ve modified my diagrams a bit to reduce ambiguity and emphasize key points.  The goal of part 3 of this series is to compare and contrast the Onion Architecture with traditional layered architecture.  I will flatten the Onion Architecture to see what it looks like compared to traditional layered architecture, and I will force the layered architecture into an onion.  Whereas the shape can be either, the structure of the actual application is radically different from what is commonly known and accepted.  I’ll define four tenets of Onion Architecture at the end.

I must stress again:  I am not claiming any breakthroughs in technology or technique.  I have learned from other industry thought leaders like Martin Fowler, Ward Cunningham, Kent Beck, Michael Feathers and others (especially those I’ve had the privilege to work with here in Austin, TX).  I’m putting forth the Onion Architecture as an architectural pattern by which we can communicate this radically different architectural approach.  Not "radically different as in new".  Different as in not mainstream.

Let’s review.  Traditional layered architecture can look somewhat like the diagram depicted on the right.  Each layer communicates with the layer below it.  The UI talks to business logic, but it does not talk directly to data access, WCF, etc.  The layering approach does call out the need to keep certain categories of code out of the UI.  The big downfall is that business logic ends up coupled to infrastructure concerns.  Data Access, I/O, and Web Services are all infrastructure.  Infrastructure is any code that is a commodity and does not give your application a competitive advantage.  This code is most likely to change frequently as the application goes through years of maintenance.  Web services are still fairly new, and the first version in .Net, ASMX, is already deprecated in favor of WCF.  We can be assured that WCF’s days are numbered as well, so it is foolish to tightly couple the business logic to WCF.  Data access changes every two years or so, so we definitely don’t want to be tightly coupled to it.  For long-life, we would want our business logic to be independent of these infrastructure concerns so that as infrastructure changes, the business logic doesn’t have to.

Let’s review Onion Architecture.  The object model is in the center with supporting business logic around it.  The direction of coupling is toward the center.  The big difference is that any outer layer can directly call any inner layer.   With traditionally layered architecture, a layer can only call the layer directly beneath it.  This is one of the key points that makes Onion Architecture different from traditional layered architecture.  Infrastructure is pushed out to the edges where no business logic code couples to it.  The code that interacts with the database will implement interfaces in the application core.  The application core is coupled to those interfaces but not the actual data access code.  In this way, we can change code in any outer layer without affecting the application core.  We include tests because any long-lived application needs tests.  Tests sit at the outskirts because the application core doesn’t couple to them, but the tests are coupled to the application core.  We could also have another layer of tests around the entire outside when we test the UI and infrastructure code.

This approach to application architecture ensures that the application core doesn’t have to change as:  the UI changes, data access changes, web service and messaging infrastructure changes, I/O techniques change.

To the right, I have created a diagram which attempts to show what Onion Architecture would look like when represented as a traditionally layered architecture.  The big difference is that Data Access is a top layer along with UI, I/O, etc.  Another key difference is that the layers above can use any layer beneath them, not just the layer immediately beneath.  Also, business logic is coupled to the object model but not to infrastructure.

To the left here I have attempted to represent traditionally layered architecture using concentric circles.  I have used black lines around the layers to denote that each outer layer only talks to the layer immediately toward the center.  The big kicker here is that we clearly see the application is built around data access and other infrastructure.  Because the application has this coupling, when data access, web services, etc. change, the business logic layer will have to change.  The world view difference is how to handle infrastructure.  Traditional layered architecture couples directly to it.  Onion Architecture pushes it off to the side and defines abstractions (interfaces) to depend on.  Then the infrastructure code also depends on these abstractions (interfaces).  Depending on abstractions is an old principle, but the Onion Architecture puts that concepts right up front. 

Key tenets of Onion Architecture:

• The application is built around an independent object model
• Inner layers define interfaces.  Outer layers implement interfaces
• Direction of coupling is toward the center
• All application core code can be compiled and run separate from infrastructure

I encourage you to use the term "Onion Architecture" when speaking about architectures that adhere to the above four tenets.  I believe that this approach to architecture leads to long-lived systems that are easy to maintain.  Also, in my experience, this architecture yields dividends soon after a project starts since it makes the code a breeze to change.

Although I don’t call out an IoC container as a key tenet, when using a mainstream language like Java or C#, an IoC container makes the code fit together very easily.  Some languages have IoC features built-in, so this is not always necessary.  If you are using C#, I highly recommend using Castle Windsor or StructureMap.

As I’ve posted earlier, Kevin Hurwitz has started blogging.  Kevin lives in Austin and is active in the local developer community (AgileAustin, Austin .Net User Group, AgileATX).

He has just posted: “The Holy Grail – Application Development without Developers“

It’s hilarious and sobering.  Here’s an excerpt:

“Over the course of my career, I’ve seen attempts on various projects to eliminate the need for ongoing developer involvement in system maintenance. The argument goes something like this: If we could just build a flexible business rules engine, we wouldn’t have to call the developers every time we need to update our FILL IN THE BLANK.”

You should subscribe to his feed right away!