As I wrote earlier, I’m really impressed with p&p‘s latest release – the Composite UI Application Block. I had to fly to Atlanta for a customer meeting last week and I spent most of my spare time (flying, in hotel, etc) digging thru CAB. Well, digging through CAB and reading State of Fear by Michael Crichton. IMO, it’s his best book in quite a while, perhaps second best he’s ever written after Jurassic Park.

Back to CAB. First off, I want more information about ObjectBuilder. p&p’s dependency injection framework is very impressive. However, with the exception of the code, the code reference in the help files, the unit tests, and a single article on how it was designed there just isn’t much info on it. For example, I know I can use it to inject a concrete type where a class is expecting an abstract type. But I couldn’t figure out how so I went and asked Peter and Brad. (Short answer – use TypeMappingPolicy). Do me a favor, go contact Peter and David and tell them you want more info on ObjectBuilder. Sample code especially. Go on, drop them a line right now while you’re thinking about it. I’ll wait.

Back already? Cool. One thing you can’t help but notice about CAB (and OB for that matter) is the heavy use of attributes, which I feel is an extremely elegant solution. Remember the first time you looked at NUnit? How sensible it seemed to use attributes like [TestFixture], [Test] and [ExpectedException] compared to what other xUnit frameworks provide? Get ready to experience that all over again when you look at OB and CAB. Now you’re looking at attributes like [CreateNew], [EventPublication] and [CommandHandler]. There’s a reason why Sun cloned attributes for J2SE 5.0 – it’s powerful (in the right hands). The attributes both drive human readability – when you’re looking at a property adorned with [CreateNew] or [Dependency] it’s obvious that these are injected – as well as the implementation. Win-win as far as I’m concerned.

CAB does a great job of codifying standard patterns in smart client design, such as events, commands and controllers, as well as implementing completely new ideas such as workspaces, work items and smart parts. And they’ve done it with an eye on the future. I love the isolation between the windows forms specific parts of CAB and the underlying infrastructure of CAB. Check out this picture of the layers of CAB. By isolating all the WinForms specific stuff in a separate assembly, they are well set up to support WPF while minimizing redundant effort. I can’t wait to see a Microsoft.Practices.CompositeUI.Avalon project (because Microsoft.Practices.CompositeUI.WindowsPresentationFoundation is just to long a namespace).

However, I can’t shake the feeling of how complex this stuff is. Yeah, you use CAB for solving complex problems, but there is a significant learning curve here. I imagine debugging a CAB app will be significantly non-trivial. Take a look at the final step of the walkthru app. Here’s the sequence that gets “hello world” painted on the screen:

1. Main entrypoint creates and runs the ShellApplication.
2. ShellApplication creates a ShellForm window, which in turn contains the tabWorkspace1 workspace.
3. ShellApplication dynamically loads MyModule because it’s listed in the ProfileCatalog.xml file.
4. CAB creates an instance of the MyModuleInit class from the MyModule assembly.
5. MyModuleInit creates and runs an instance of MyWorkItem.
6. MyWorkItem creates a MyView and MyPresenter.
7. MyWorkItem adds the MyView instance to the tabWorkspace1 workspace, hosted in the ShellForm
8. MyPresenter handles the MyView load event and sets the message property of MyView to “Hello, World”

Of course, the point of a demo app like the walkthru is comprehension. You would never use CAB to build this Hello World app. But I worry that the level of complexity will put CAB beyond the reach or inclination on many potential users. I imagine this single line of code will scare off many would-be CAB developers:

MyWorkItem myWorkItem = parentWorkItem.WorkItems.AddNew<MyWorkItem>();

Given that most people are used to writing new MyWorkItem(), the line above represents a significantly rise in complexity. Of course, CAB is trying to solve a complex problem. I’m sure CAB’s designers would rather the solution wasn’t so complex, but that’s the reality of the problem space their dealing with.

If you can’t lower the complexity of your framework, it’s time to raise the abstraction of your tools.

I wonder what CAB specific tooling would look like? At a minimum, it would like built in support for the primary concepts in CAB – WorkItem, SmartPart, Workspace and Service to name a few. Another opportunity would be to move from embedded strings, used to identify events, commands, UIExtensionSites and the like to true variable-style names that could be validated at compile time, sort of like how LINQ is extending C# to get rid of embedded database query commands. There’s lots of possibilities and the more I work w/ CAB the better idea I’ll have about them.

Wikipedia has two definitions of mashup:

• Mashup (music): a musical genre consisting of the combination of the parts of more than one song
• Mashup (web application hybrid): a website or web application that combines content from more than one source

I was originally introduced to the term mashup in the musical sense by Daily Source Code. In this usage, mashup implies mixing songs together. Given that songs are typically stand along entities designed to be enjoyed as is, mashup means (to me anyway) combining stuff that was never meant to be combined in the first place. Even Wikipedia includes musical mashup under the general heading of Bastard Pop.

So given that, by definition, mashups combine stuff that wasn’t designed to be combined, I don’t understand why an application like Zvents or Virtual Places is considered a mashup. Apps like these use browser based components (Scoble calls them Internet Connected Components) that are well defined, have public APIs and are designed to be used together. Not exactly “bastard pop” now is it?

In reality, a site like Zvents could have used a server side mapping component and provided a similar experience. Of course, a client side mapping solution is both sexier and more practical (no need for dedicated map data files or assemblies on your own machines) but semantically they provide the same information. Same thing goes for Virtual Places, except that Virtual Places is also pulling both functionality (i.e. the mapping component) as well as data (i.e. blogs and photos) from other sites across the Internet. Could that be done on the server side? You betcha. Would it be as cool or functional? No. Does that make it a completely different type of application that deserves a new name. IMO, no. These are component based apps – they just use the browser as the platform and the components are coming across the web (as you would expect when you use the browser as a platform).

The higher order bit for me is who controls the experience. For apps like Zvents and VirtualPlaces, it’s the application developer. For something like Live.com, it’s me. I decide what to put on my Live page. Not that one is more important than the other or that they aren’t compatible experiences – I could easily imagine a Zvents gadget that lived in Live.com. Or consuming the RSS feed from Zvents in Live.com. Or a generic iCal gadget that could consume a Zvents iCal feed. But the point is that there are large differences between browser component based application like Zvents and a user managed composite browser application like Live.com.

To me, composite apps like Live.com fit better to the original definition of mashup than something like Zvents or Virtual Places. They both have their place and their value, but I like to call things that are different by different names in order to reduce confusion.

Of course, composite apps aren’t limited to the browser. p&p just shipped their Composite UI Application Block last week. I dug into it a bit last week and it’s awesome. More on that later.

First, Amigo Grady Booch admits to throwing away models. Now, Amigo Ivar Jacobson has signed on as a VSIP partner:

Microsoft has tapped Ivar Jacobson, known as one of the fathers of the popular Rational Unified Process (RUP), to lead an effort to deliver a lightweight unified process to the Microsoft Solutions Framework.

<snip>

Jacobson said the first fruits of his company’s relationship with Microsoft will be through the delivery of the Essential Unified Process (Essential UP), which is based on the Microsoft Solutions Framework and integrated with VSTS.

In short, Essential UP is a simplified or lighter-weight alternative to RUP, Jacobson said. Essential UP is an evolution of the unified process Jacobson helped create more than 10 years ago that forms the foundation of RUP, he said.

<snip>

“We need more lightweight processes,” Jacobson said, noting that RUP has become too heavyweight and cumbersome. “We have competition from India, China and the former Soviet Union,” he said. “It is not enough to be agile.”

Indeed, Microsoft has done a good job with its Microsoft Solutions Framework, and “their process agility is a clear differentiator for them,” Jacobson said.

“Essential UP stands on all the experience we have from RUP, but also offers us a chance to have a fresh start,” Jacobson said. “We start in a new way because we’ve learned what works and what doesn’t work.”

<snip>

“RUP has a lot of good stuff, but it needs a correction,” [Jacobson] said.

<snip>

However, among the primary problems Jacobson said he has with RUP is that it is “heavyweight.”

Also, “the process architecture needs to be refactored,” Jacobson said. “It is very difficult to add new practices because it will force a big change in the base. For instance, adding in a streamlined way practices such as EA [Enterprise Architect], SOA [service-oriented architecture], ABD [asset-based development], re-engineering legacy systems and commercial off-the-shelf software would be very difficult, if at all possible. So I believe in starting all over fresh but not throwing away anything that is good.”

<snip>

“Having an industry luminary build the next version of his tool for our platform is huge for us,” [VSTS General Manager Rick] LaPlante said.

[From Microsoft Taps Former Rational Heavyweight to Lend Credence to Enterprise Tools Play, eWeek]

I’d like to nominate Rick’s comment for understatement of the year awards. It also gets me wondering what Amigo Jim Rumbaugh is up to these days.

David Hayden shows off the Export Templates Wizard from VS05. Very cool. Frankly, I like GAT for most of this type of template work, but this really fits nicely from a “simplest thing that could possibly work” perspective.

If you haven’t had a chance to check out the most recent issue of The Architecture Journal, I highly recommend it. In particular, I liked Metropolis and SOA Governance by Richard Veryard and Philip Boxer as well as Value Driven Architecture by Charlie Alfred.

Richard and Philip dive deep on governance, leveraging Chris Alexander’s Nature of Order and Pat Helland’s Metropolis. In particular, I liked the section on the structural implications of service orientation. As per Alexander, large complex systems can’t be designed in the traditional manner – they evolve over time. This leads Richard and Philip to discuss the highly fascinating concept of asymmetric demand. To quote the article: “Asymmetry means that the forms of demand are increasingly specific to the context in which they arise.” I can’t do the concept justice – just go read the article – but my takeaway is that what you sell isn’t necessarily what people are buying. Take SQL Server for example – you know, one of those products that launched a new version yesterday. Amazing product, but nobody buys SQL Server on its own. It’s always bought in the context of a larger solution. SQL is extremely flexible, so the number of contexts in which it’s appropriate is extremely high. But still, how many business people have ever said “We need to buy a database”. I’m guessing zero. Business people say things like “We need to keep better track of our shipments/inventory/customers/orders/etc” or “we need to better insight into business trends” or “we need to be able to demonstrate our compliance with <insert government regulation here>”. These business problems all need a database like SQL Server, but they need more than SQL Server alone. That’s the asymmetry. Microsoft sells SQL Server (among other things of course, but let’s focus for a second), but customers are buying a solution to their business problem.

On the topic of business problems, Charlie’s article on value modeling flat out states that traditional requirements based design is ineffective. Charlie’s agrees with Jack and Keith that requirements define a system, not the problem the system is intended to address. As such, often critical design decisions are made while defining requirements that have drastic impact on the development of the system down the road. As a somewhat silly example, if I define requirements for a software system, I am precluding any non-software system solution to the problem. What if the best solution for a problem isn’t software? Because of mistaken assumptions I’ve made in the requirements gathering process, I’ve eliminated the best solution to the problem. Woops.

And Charlie has this great quote about the requirements gathering process:

Traditional approaches, like use case scenarios or business/marketing requirements, start by focusing on the types of actors with which the system interacts. This approach has several major limitations:

• It focuses more on what things the actors do, and less on why they do them.

• It tends to stereotype actors into categories, where all individuals of a type are essentially the same (traders, portfolio managers, or system administrators, for example).

• It tends to ignore differences in limiting factors (for example: Is an equity trader in New York the same as one in London? Is trading at market open the same as trading during the day?).

• It is based on binary outcomes: the requirement is met or it isn’t. The use case completes successfully or it doesn’t.

There is a very logical, practical reason why this approach is popular. It uses sequential and classification-based reasoning, so it is easy to teach and explain, and it can produce a set of objectives that are easy to verify. Of course, if simplicity were the only goal that counted, we’d all still be walking or riding horses to get from one place to another.

I love the point about simplicity. Often, we do things in IT that are simple for IT but that are more complex (and thus bad) for the business. For example, a web app may be the easiest to deploy for IT, but if I have a mobile workforce that web application will cause more business headaches than it solves in IT.

In other Architecture Journal related news, you can sign up for a free subscription, so what are you waiting for?