Thunderclap, the Newsletter of Rolling Thunder Computing

Volume 9, Number 1, Fall 2007

In this issue:

Public Training Class on Composite UI Application Block and Smart Client Software Factory in Reykjavik Iceland on Oct 9-12 and Salem MA on Oct 16-19

Feature Article: CAB and Acropolis, Evolution, and Comparison of Service Models

New Book from  David Platt: Why Software Sucks (and What You can Do About It)

ANOTHER New Book from  David Platt: Programming CAB and SCSF from Microsoft Press

Blatant Self-Promotion: New  in-house class on Composite UI Application Block and SCSF

Annabelle and Lucy's Latest

Subscription Information

Feature Article: CAB and Acropolis

Anyone who has done any serious work with CAB and SCSF in the last year or so has heard the term “Acropolis”, and gotten some sort of notion that it represented the next evolution of the CAB and SCSF architecture, to be unveiled sometime in the future. With all the work I’ve been doing in CAB and SCSF, and my book on the topic now out, many people are asking me what Acropolis actually is, when would it ship, how it would differ from CAB and SCSF, and what they should be doing about it today. This newsletter is my public answer to all of these questions.

The first CTP(Community Technology Preview, a preliminary trial balloon, not official like a beta release) of Acropolis was released and demonstrated at Tech Ed  in Orlando in June 2007. Many of the attendees took that to mean that its feature set was more or less complete, and that its shipment was imminent or at least scheduled, despite the Acropolis team’s repeated statements to the contrary.  Ward Bell’s blog article Acropolis: Between Elation and Despair describes their feelings vividly. He writes: "The newly released CTP1 is manifestly fragile. Every API is subject to change. There were no feature commitments. There were no architectural commitments. There was not even an inventory of project goals. 'These are our ‘thinkings’,' [the Acropolis team] said, 'we want to know what the community thinks about it.' "

The CTP was and to this day remains very much a first cut, a straw man for people to start poking at. That’s a good way to start a project, and the Acropolis team says that they’ve gotten great feedback from the developer community. (When I say something like that, I invariably mean that I’ve gotten my head handed to me and I have to make major changes in whatever I was working on, but let that pass.) But when you ask them when it’s going to be ready, they shy away from any commitment.  In the following excerpts from the postings of Microsoft employees on  Microsoft’s official Acropolis developer forum, you can see that it is quite a ways from release, or even completing the feature list.

On July 31, Kathy Kam wrote: “We will not decide which version of the .NET Framework we will be part of until we have gather enough feedback to understand what exactly we are shipping.”

On September 10, Alex Balanku wrote: “Acropolis is a preview technology and currently there is no release date or even officially approved plans to release Acropolis in its present shape.”

And on August 30, Kathy Kam wrote: “Please note that Acropolis is a Technology Preview only, and should not be used in live production. That said, we do encourage you to use and evaluate Acropolis and give us feedback on the technology. In the mean time, CAB/SCSF is the right technology to use if you are interested in building componentized application for live production”

That would seem pretty clear to me. Acropolis is in its earliest stages. The team would love to have your feedback as to what you like and don’t like about it, what you need that it doesn’t have, what it has that you don’t need, and so on. Now is a great time to get your requests in, and I’ve put in a few.

When is it coming out? No one in Microsoft will tell me. But my own wild-ass guess is as follows. First, remember that a)the feature list is still under development, b) they haven’t decided which edition of the .NET Framework to align it with, c) they haven’t made such major decisions as whether it will or won’t support web applications via Silverlight,. This means to me that they haven’t yet decided what they’re going to build. A straightforward port of CAB into WPF, XAML, and Visual Studio? A large amount of increased functionality? Second,  remember that Acropolis is to be an official product, not a “recommended practice” set of code the way CAB and SCSF are. Therefore the level of polish, the fit and finish if you  will, must be much higher, and the speed of iteration will have to be lower.  Finally, remember Platt’s First Law of the Universe, subtitled “Exponential Estimation Explosion.” It states simply that “Every software project takes three times as long as your best estimate, even if you apply this law to it.”  With all of these working on it, I predict that we won’t see the release of Acropolis in CY ’08. When I’m feeling generous, I’ll say first half of CY ’09, and when I’m feeling cranky, I’ll say second half.

So again, I’ll echo what Kathy Kam said in her August 30 posting. If you’re interested in building rich client applications using loosely coupled components, CAB and SCSF is today’s choice. And you can learn about it in the public classes that I’m running this October and January, or private classes that I teach in-house at your company.

 Meanwhile, what does this Acropolis thing look like and how does it work? It’s intended to solve the same problems that CAB did, so it should come as no surprise that it has great architectural similarities. The rest of this article will show you how the architecture of the service system is very similar between CAB and the current release (August CTP) of Acropolis.  While some of the syntax is significantly different, the architectural concepts are highly similar. Therefore, if you are considering Acropolis at some future time, you will see that starting with CAB today is the right approach.

A service, in the loosely coupled architecture sense of that highly overloaded term, is a singleton object that provides functionality in a loosely coupled way to disparate parts of the application, which obtain references to the service and access it through the service’s interface. In this way, the consumers of the service do not have to know the exact implementation of that service, so it can be developed independently of them. A good example of a service is a timestamp, which ensures that all of the loosely coupled modules in a CAB/Acropolis application use the same mechanism for figuring out what time it is and therefore agree on the times at which their various operations take place.

You remember that in CAB, services were implemented by means of their interfaces. The provider of the service designs an interface, thus:

public interface ITime
{
    DateTime GetTime();
}

 and provides an implantation, thus

public class TimeService : ITime
{
     public DateTime GetTime()
     {
         return DateTime.Now ;
     }
}

Somehow this service needs to be placed into the CAB application framework and indexed by means of its interface, so that its consumers can find it. You can do this declaratively by making entries in the app.config  file,  thus:

<services>
  <add serviceType="CommonTypes.Interface.ITime, CommonTypes.Interface"
   instanceType="TimeServiceImplementation.TimeService, TimeServiceImplementation"/>
</services>

 or programmatically by writing code in the Application base class, thus:

protected override void AddServices()
{
    // delegate to the base class

    base.AddServices();

    // Now add our own service programmatically

    this.RootWorkItem.Services.AddNew <TimeService, ITime>();

}

The consumer of the service could request the service declaratively by injection, thus:

ITime m_TimeService;

[ServiceDependency (Type=typeof(ITime))]
public ITime TimeServiceInjectionSite
{
    set { m_TimeService = value ;}
}

or programmatically by  querying  the WorkItem to which it belongs, thus:  

 // Fetch the time service from our local work item,
// which searches up the chain if it doesn't find it there

ITime it = this.WorkItem.Services.Get<ITime>();

The consumer  would use the service, thus:

// Get the time from our service

DateTime dt = it.GetTime();

Acropolis works in exactly the same conceptual manner:  a singleton object that provides useful functionality in a loosely coupled way, and which consumers request by its interface. The provider creates it and makes it available in a conceptually identical manner, and the consumer obtains and uses it in a conceptually identical manner as well

The interface definition is the same as above. The implementation of the service is slightly different. You must mark the implementation class with an attribute that designates the interface that it provides (this was optional in CAB). You must also derive your implementation from the ServiceBase class to obtain some functionality that the framework uses for keeping track of the service. I wouldn’t be surprised to see this change to implementing an interface, so that services could derive from other existing classes. Thus:

[ServiceProduction (typeof (ITimeService))]
public class TimeServiceImplementation: ServiceBase, ITimeService
{

public DateTime GetTime()
{
    return DateTime.Now;
}

}

The provider of the service places it into the application declaratively using  XAML instead of the app.config, thus:,

<AcropolisApplication.Services>
 <my:TimeServiceImplementation Name="TimeServiceImplementation1" xmlns:my="clr-namespace:AcropolisApp1" />
</AcropolisApplication.Services>

 It can also be done programmatically, as one would expect. The syntax is a teeny bit ugly, but we wouldn’t expect it to be polished just yet.

public Application()
{
    InitializeComponent();

    // Load up time service

    InstanceMoniker moniker = ComponentPropertySystem.RegisterInstanceMoniker(
        ComponentPropertySystem.GetTypeMoniker(typeof(TimeServiceImplementation)));

    DependencyRegistry.RegisterGlobalService(typeof(ITimeService), moniker);

}

The consumer of the service can ask for it to be injected via XAML, thus:  

<AcropolisComponent.ServiceDependencies>
   <ServiceDependency Name="TimeService1" ServiceType="{x:Type my:ITimeService}" />
</AcropolisComponent.ServiceDependencies>

In which case it will appear as a member variable TimeService1, thus:

protected override void OnInitialized()
{
    base.OnInitialized();

    if (this.TimeService1 == null)
    {
        MessageBox.Show("Time Service is Null");
    }
    else
    {
        MessageBox.Show  ("Time is now " + this.TimeService1.GetTime ()) ;
    }
}

If you prefer, you can query for the service programmatically by querying the service registry, thus:

ITimeService its =  DependencyRegistry.GetService<ITimeService>();

So you see, the current implementation of Acropolis uses exactly the same architectural concepts as does CAB, for exactly the same reasons. The syntax the we use to get them is somewhat different. But if you architect your app properly, for example, figuring out which pieces of functionality ought to reside in these loosely coupled services, and what the contracts ought to be,  that’s the major portion of the work. Placing it in the CAB or Acropolis syntax takes very little time one way or the other.

Anyone who wants the benefits of loose coupling should be developing applications today with CAB and SCSF. Converting them to Acropolis, whenever it comes, will likely be easy. If you'd like to learn more about CAB and SCSF, I'm teaching a public classes on it in October and January. Or I can teach it in-house at your company, which you'd probably find cost-effective if you had five or more attendees. Information on both is online at this link,

Until next time,  as Red Green  would say, "Keep your stick on the ice."

Another New Book from David S Platt

Programming CAB and SCSF

ISBN 0-735-62414-3

Click here to order from Amazon.com

To complement my course offerings in CAB and SCSF, I've compiled my notes and sample code into a book, published by Microsoft Press. Get hands-on guidance for developing smart client applications using Windows Forms with the Composite UI Application Block (CAB) and the Smart Client Software Factory.  This book details a simple, approachable method for building these applications. With just your fundamental Visual Basic or Visual C# skills, this guide will help you understand the prefabricated classes of CAB and the proven patterns that the Smart Client Software Factory provides. This book offers classroom-tested guidance, hands-on instruction, and a proven building-block approach. Through eight modular lessons, developers of moderate experience with learn how to create functional, robust smart client applications.

Chapter List:

New Book from David S Platt

Why Software Sucks (and What You Can Do About It)

ISBN 0-321-46675-6

Sample Chapter Online at www.whysoftwaresucks.com

It's finally out! Anyone whose spoken with me in the last couple of years probably got an earful about the latest bee in my bonnet, the book entitled Why Software Sucks. I’m sure that I’ve inflicted sample chapters on just about everyone I know.

It's gotten a storm of publicity, primarily from a Reuters wire service article that ran during the first week of the new year. It was picked up in the electronic editions of such publications as the such as the New York Times (http://www.nytimes.com/reuters/technology/tech-software-platt.html) , Fox News, (http://www.foxnews.com/story/0,2933,241578,00.html), and PC Magazine (http://www.pcmag.com/article2/0,1759,2078820,00.asp).

I've started a new blog based on it, at www.suckbusters.com . It's dedicated to the notion that software shouldn't suck. Instead, software should Just Work.

The title was originally my idea, but I also love the subtitle, suggested by my editor at A-W. I’ve always thought that the right subtitle can really make a book. Like the 60’s bestseller Everything You Always Wanted to Know About Sex (But Were Afraid to Ask). Or Werner von Braun’s autobiography, entitled I Aim for the Stars. Humorist Mort Sahl suggested that its subtitle ought to be, But Sometimes I Hit London. (If you don’t get that last one, go look up von Braun online. As Tom Lehrer famously sang about him in the sixties:  “ … A man whose allegiance is ruled by expedience … ‘Once the rockets are up, who cares where they come down? That’s not my department,’ says Werner von Braun.”) 

This is my first book aimed at end users, not programmers. Early returns from this market are highly positive. My barber, the librarian at my local public (dead tree edition) library, and the contractor who built my house, all report that early chapters are informative, entertaining, and easy to read.

I’m still working on the “what you can do about it,” piece. If you have any thought as to how ordinary users can make their voices heard, I’d like to hear them. Use the contact info link of this web site, if you don’t already have my email. Thanx.

Blatant Self Promotion: Would you buy a used car from this guy?

4-day In-House Training Class on Composite UI Application Block. Available In-House, or to the Public in Salem MA,  Oct 16-19, and Reykjavik Iceland Oct 9-12

The CAB that I describe above is useful, but has a steeper learning curve than other parts of .NET. My in-house training class on it will get you up and spinning in no time. See the online syllabus here, then call me to schedule yours.

5-day In-House Training Class on .NET or .NET for Insurance

.NET is here, and it's hot. It changes everything in the software business, and you can't afford to be without it. Rolling Thunder Computing now offers in-house training classes on .NET, using my book as the text.  See the syllabi online here, then call to schedule yours. 

ACORD XML for Insurance In Depth, Including Web Services 

Insurance carriers, learn ACORD XML from David Platt. This 5-day class will give you everything you need to know to jump-start your application development. Learn about security and plug-and-play, and combining ACORD XML with XML Web Services. See the syllabus online here. It can be customized to your needs. 

 Annabelle And Lucy's Latest

And now, the moment for which I know you've all been waiting -- the pictures of my two girls. Lucy is now 4 1/2, going on 5. She's in Yellow Rose Kindergarten at  Cape Ann Waldorf School, actually RUNS onto the playground when we drop her off. Annabelle turned 7 in June. She's in first grade at Cape Ann Waldorf. And believe it or not, her teacher is a burned-out computer geek, who used to work for Powersoft, remember them? Small world, ain't it? .

Here Lucy holds her friend Shifty the Ferret (owned by her baby sitter Tamera) at Annabelle's Hawaiian-themed 7th birthday party.

Here are both girls after performing a cowgirl dance at their dance class recital. Pink roses courtesy of dear old Dad.

And here's Annabelle herself, after her Penny Lane jazz dance at a different recital. Yellow roses ditto.  

Subscription Information

Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list, though occasionally we use it for our own promotions. To subscribe, jump to the Rolling Thunder Web site and fill in the subscription form.

Legal Notices

Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.

Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.

This newsletter is Copyright © 2005 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.

Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.