News Stay informed about the latest enterprise technology news and product updates.

Microsoft's Patterns & Practices Summit 2007: Development Day

Microsoft's Patterns & Practices Summit highlighted the best strategies for architecting .NET applications. This report focuses on the summit's day devoted to development.

REDMOND, WASH. -- Microsoft's Patterns & Practices Summit is lighter on code, and heavier on architectural diagrams, than most conferences. Hosted by the company's Patterns & Practices group, these sessions highlight what the group has deemed the best strategies for architecting .NET applications. Attendees, meanwhile, ask questions, offer feedback and have a bit of a hand in shaping the P&P group's future endeavors.

The latest Patterns & Practices Summit hit the conference center on the Microsoft campus. Each day had its own theme -- architecture, agile, development, software factories and applications. The report that follows focuses on the summit's development day.

Why Ruby?

John Lam kicked things off with a look at IronRuby, which is an open-source implementation of Ruby that runs .NET objects.

Lam identified three goals for IronRuby. The first is to be as compatible to Ruby as possible. The second is to peacefully coexist with the .NET Framework and, as a result, allow .NET to interoperate with the Mac, via Silverlight, and with Linux, via Mono. The third is to achieve acceptable performance -- that is, faster that it currently runs and with additional features.

Lam then demonstrated a bit of IronRuby's potential. In one scenario, he showed the audience how to build IronRuby class libraries. This involved adding classes and then marking constructor methods, which, like C# 3.0 extension methods, are static.

The Right Tools for the Right Job

"I don't know about you, but I feel utterly overwhelmed at the technology being thrown at us," Rockford Lhotka said at the beginning of his talk. "The only way I feel I can maintain any sort of sanity is to plug the new technology into an architectural framework."

At that, Lhotka launched a discussion of where and how it is best to use object-oriented design, service-oriented design or workflow design.

More from P&P from Microsoft
Patterns & Practices on MSDN

Patterns & Practices on CodePlex

Object-oriented design is essentially message-based communication between objects, he said. It tends not to fit within a distributed computing model without a bit of planning.

Service-oriented design, meanwhile, offers loosely coupled interactions between services that lack tiers. (Think of the basic tiers of an application -- the presentation, UI, business, data access and database layers.) This provides a nice, non-deterministic way to model how applications, and the world, tend to operate, and it is cross-platform and -language. On the other hand, Lhotka noted, both the concept and the tools are immature.

Workflow design, finally, represents an orchestration of ordered activities that are designed in terms of input and output. This is not a new concept per se -- remember poster-sized flowcharts? -- but mastering it requires architects to unlearn object-oriented and event-driven programming, Lhotka said.

Designing for Workflow

Picking up where Lhotka left off, Ted Neward offered some "proto-patterns and proto-practices" for workflow design -- so described because there is no critical mass rallying around Windows Workflow Foundation yet.

Neward first identified four goals of workflow design.

  • Capture long-running processes over which end users will want some control
  • Give so-called "knowledge workers" the capacity to edit the workflow
  • Keep workflows decoupled from their stored environment
  • Avoid tying a workflow to a single host environment, since that limits its usefulness

He then offered seven ruminations on the subject.

  • Don't ignore the prior art. Workflow Patterns, for example, outlines more than 100 patterns and practices.
  • Make sure any action outside the workflow is captured as a workflow service. Remember, you will never know who will want to interact with your workflow and how they will interact, Neward noted.
  • Decide whether architects or knowledge workers will be writing the workflow.
  • Use state-machine workflows for open-ended processes.
  • Look for hosting scenarios, from batch execution toWinForms to stored procedures, which stretch Windows through the rest of your enterprise.
  • Set timeout options for non-processing workflow activities. Otherwise -- if, say, a user wins the lottery and retires -- that task may never be completed, Neward said.
  • Keep in mind that workflows are hardware-independent and, therefore, can be persisted and restored in entirely different locations.

The Future of Model-Based Design

David Trowbridge and Suhail Dutta focused primarily on Microsoft's plans for the role of modeling in Rosario, the version of Visual Studio Team System coming out after VS 2008.

Rosario includes a logical class designer and a sequence designer, it supports Domain Specific Languages and those DSLs wrap around tool adaptors for a nice, loosely coupled interface. All this functionality can be used in standalone applications, Trowbridge said, or it can be used in a software factory.

The duo also demoed Progression, which is the code name for a tool that aims to bridge the gap between architecture and development -- the former focusing on requirements and models, the latter on refactoring, visualizing, filtering and analyzing code.

In Progression, architects can organize the components of a solution by namespaces and classes, links the references among all the classes and identify so-called "hubs," or important pieces of code on which numerous classes rely.

Dependency Injection Frameworks

Through dependency injection, objects that need to find each other, well, find each other. It works thanks to what Peter Provost described as the Hollywood Principle: "Don't call me. I'll call you."

More on P&P from the blogosphere
Travis Illig's thoughts on Patterns & Practices

Allen Mack's thoughts on Patterns & Practices

Dependencies can be provided several ways -- through an interface and a contract, via setter methods, via constructor parameters or through method injections. These processes promote flexible code that is easy to test, maintain and reuse, but, Provost noted, they do lend themselves to the creation of lots and lots of objects.

Enter ObjectBuilder. This runtime framework for building dependency injection systems will manage the way objects are built up. The Event Broker, for example, lets an object raise an event and then pass data along with it, while the Interceptor, as Scott Densmore put it, allows the Rebel Forces to get in the way of the Death Star's method call to destroy Alderaan.

Enterprise Library Devolved

Densmore returned to the dais to discuss the Enterprise Library, which is a collection of application blocks. The Enterprise Library Factory, meanwhile, is essentially a modified version of the dependency injection container and is used by all other factories.

Configuration of an application's plug-ins, Densmore said, boils down to the container in which they are found and not the library. This means configuration should be easy to do without changing code.

The Future of Design Patterns

Much more was said during this hour-long panel discussion than can be reported here. Stay tuned for a full-fledged, honest-to-goodness story on future of Microsoft's Patterns and Practices program in the next few days.

Dig Deeper on .NET Architecture Best Practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.