edjez's WebLog : Smart Client

Release of CAB (Composite UI Application Block) !!

edjez — Wed, 07 Dec 2005 02:38:00 GMT

And so it releases. This has been a great project and team to work with. I feel privileged to have been able to work with all the folks who made it possible, and to have made such a step forward implementing a close customer connection throughout the project.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/cab.asp

So what is CAB? It's an application block that provides common infrastructure components and a programming model for smart client applications that are composed out of views and business logic that might come from different teams or need to evolve independently. It has been architected considering many a convergence of many patterns observed in large successful customer applications and whre the platform and tools are going in the future in this space.

It contains:

WorkItems: a programming abstraction to simplify encapsulating use cases into 'contexts' that have shared state and orchestrating logic and nested recursively
Plug-in infrastructure: providers for enumerating available modules and loading them into the environment, and orchestration of the application bootstrap
Shared shell abstractions: a set of interfaces that allow logic to 'share a shell' and to facilitate separation of concerns between UI-intensive shell development and business logic development
- Workspaces - a set of interfaces that specify how to show controls in an a given area or style - such as portal, tabbed, MDI windows, etc
- UI Extension sites - named 'slots' in a shell where you want to add controls such as menus or status bar panes
- Commands - a common way of hooking up multiple UI events to a specific callback inside your application
Composition infrastructure that helps objects find each other and communicate - such as the ability to share state, auto-wire-up of pub-sub of events
A service locator/lifetime container/dependency injection++ foundation
- Built on ObjectBuilder - which allows you to extend the architecture specifying what it means to 'contextualize' an object.
A reflective architecture that you can explore to see the current state of the application, and a visualization architecture that allows architects and troubleshooters have views that exploit this reflective nature and can show you the internals of the application structure and how it's running while it's live (see the sample visualization in a separate download).

This is a 'large' app block - you will probably want to do the hands-on-labs and see the webcasts to understand the key concepts in depth. But you can get going with little effort by looking at the quicktstarts and included how-to documentation.

When the time comes around, we'll be working on showing how WinFX technologies such as Windows Workflow and WPF (Avalon) can be used in CAB applications. As always, the goal of these p&p assets is to help you build your applications in that make the best use of the existing platform and sets you up for simplified adoption of the next generation.

I hope you enjoy it. To all the customers who participated in our expert advisory board, on-site visits, workshops, webcasts and gotDotNet community - THANK YOU.

//7-12 Updated to add link to Visualization download

Of EntLib 2.0, a local AOP Workshop, and the infamous TDD article

edjez — Tue, 06 Dec 2005 07:19:00 GMT

Quickie blog post, just to get jamming:

EntLib internals webcast. Yes, EntLib and CAB ship with ObjectBuilder, our common factory & dependency injection infrastructure ++. Answering the FAQs: Yes, we have one. Yes, it's this one. Yes, you can build something like Spring with it, if you wanted to. Yes, we want your feedback and you to do cool stuff with it. And Yes, I am hoping that folks implement a creation strategy that do a transparent proxying, see my next post why. Interested in ObjectBuilder and how we externalized the config interpretation and wiring to instrumentation out of each app block? See this:
So what's this Configuration Source thing meant to be? Why do you have so many kinds of factories? How can I reuse the instrumentation capabilities in my own app? What's different in the new Configuration Designtime?
Get the answers to these and many more questions at the Enterprise Library for .NET Framework 2.0: Core Architecture webcast. It's on this coming Thursday, December 8th at 10:00am US Pacific Time / 18:00 UTC. Register now to view the webcast live (this is best if you want to ask us questions), or as always it will be available on demand from the next day

By the way, shipping EntLib on ObjectBuilder was not an easy feat, congrats to the team for pulling it off and consolidating the EntLib and CAB factory and dependency injection approach...at one point in time I started wondering..."what have I done! Include a new component as part of the foundation of something that needs to ship ASAP for what some think is a hazy fluffy ivory-tower architectural benefit! I'll be lynched!". But our p&p devs + testers rock. (Guys - if you are reading this: If you don't pull these feats, nobody can. However, if I ever have to ship a full OS, I'll keep the learning in mind).
Aspect Oriented Programming Workshop We recently held a workshop around AOP here at MS. I was glad I finally got to meet Prof. Mehmet Aksit in person (from Twente, of Composition Filter fame). I hoped I would also see Christa Schwanninger from Siemens but she's having a baby (congrats Christa & Michael!). My conclusion? To better influence Microsoft the AOSD community should 'consolidate efforts' and express the commonalities that exist in approaches. I mean, there ain't that many e.g. in runtime you'll find 3 main flavors - assembly rewriting, using dynamic languages, or using transparent proxies. Only so many pointcut expressions cover a large % of advice types, and so on. I think it would be good to have a pattern language around AOSD. The AOP alliance has most of the material needed but sometimes I feel the discussions around problem space and solution space get mixed; or that the academic efforts focus on the uniqueness of each solution (which they should) instead of the commonality (which is a lousy strategy for a researcher - to write about what everyone understands!). Mehmet was going to try to get a AO on .NET wiki started somewhere to get this dialogue around commons going, when I find out that it materializes, I'll post.
- In the meantime, if anyone from the AO community wants to define a factory for proxying, please consider doing it via an ObjectBuilder strategy. It will help others use your solution, on stuff we've built e.g. CAB. And oh, if only I got a dollar for every time I meet a customer who could have benefited from richer interception on .NET. If you want it too ping a comment here, I'll print it nail it to doors on bldg 42.
- No, I don't have MS's official stand on AOSD, so please don't ask me- there's an old obscure BillG 2nd hand quote from an Australian interview where he allegedly said MS would be embracing it. Definitively the platform is embracing more and more requirements of separation of concerns throughout, which is good. Indigo looks great in this regard. I'd like to see more of a unified approach one day. But a lot of questions are unresolved yet (when you think about trust models around assemblies, for example, who is allowed to advice what?). So I don't know what the end solution would look like. Especially when I think about crosscutting concerns and concurrency, hm. We'll see.
The infamous TDD article gets pulled Unless you have been living in a tupperware, you know there was a fallout over some article about TDD deep in the tree of MSDN VSTS content. Yes, it got removed. Here's the link, anyways. It described TDD in terms of some steps that in my opinion was just..plain..wrong...and it irked folks in the TDD community. Anyways, here are my key points late in the game:
- Sorry Jimmy! I'm so late to this flame party it's not even funny... Jimmy Nilsson pings me for comment, I start writing a post in this web form and my machine runs out of battery...there goes my IE with all my text. It would have been a good post. To your question...no, what the article described is not what we do when we say we do TDD in patterns & practices. I respected Randy Miller's reaction a lot, even though he didn't get to blog about it. And I truly beleive in TDD as a design technique.
- To MS folks...how about some internal review cycles...there's agile and TDD lists... one... email... away.
- I'm glad the community responded so vigorously. Kudos to all who by nature or effort were able to articulate a response that did not evoke a Turret syndrome diagnosis.
- I would also like to see those passionate about the subject take advantage of the situation and engage with MS in a proactive way. I mean, it's good agile approaches will be getting more visibility. As the word gets spread, it may get mangled. That's just 2nd law of thermodynamics. MS and its tools channel is a huge megaphone for the agile message. I know, many people ask, "who needs a megaphone in this era of blogs & social web 2.0 long-tail software"? Well, not everyone is in-the-know of what Michael Feathers or Brian Button are saying, or has their RSS pointing at the community gurus..so influencing an ISV like MS to help spread the word in a way the respected leaders think it's right not only will help the overall industry, but also creates a market for those engaging in it. Consider this personal estimate: probably more Microsoft customer-devs relate OOP advice to Deborah Kurata than the GoF. So what about ganging up on MS and saying "we will publish books, training, etc and furnish you at a fee with agile-community-approved guidance that the masses can take a shot at without requiring going on a 4-month spiritual walkabout with Kent Beck on some rainy hill in Oregon". I think it could be a win.

What's the news? CAB shipping, EntLib shipping, and we are off to a great start with patterns & practices in 2006 and starting to plan the wave of stuff for WinFX+ timeframe technologies.... Avalon...Indigo...Workflow...LinQ This is my 5th year in this group. Any one year is never similar to the previous one. Hope you are finding the existence of p&p as helpful as I enjoy working here.

Namasté! no, wait, that's Soma, not me. Thank you!

CAB - October 2005 CTP out!

edjez — Sat, 08 Oct 2005 04:00:00 GMT

This is the last community release before our final release - the purpose of this release is to allow you to see the changes we've been doing into the API based on your feedback, to let you start building apps on what is closer to the final drop.

There are a couple of significant things about this release.

The foremost significant thing in my mind is that the whole foundation of CAB has changed to relying on an internal component we've named ObjectBuilder. ObjectBuilder has all the elements you need to build a typical Inversion Of Control / Dependency Injection framework, and also allows you to extend it to do more specific things than hooking objects up together. This is a great improvement from relying on a lot of extensions to System.ComponentModel, and has drastically reduced our code size. We haven't documented it yet as a standalone Application Block, since it's not relevant for -users- of CAB as much as people extending CAB in interesting ways. EntLib will also use ObjectBuilder internally. If you want to learn about common flavors of Inversion Of Control patterns, look at Martin's classic article on the subject. But keep in mind that ObjectBuilder takes dependency injection as just an example of overall inversion of control.We'll have to post more about this in the future, I'm sure.

There has also been a thorough polish of the whole application startup sequence and WorkItems. This makes it way simpler to make small, starter apps and start getting your feet wet with CAB. I sometimes felt like I was drowning when doing a one-module, one-form, one-workitem app. Not anymore.

In addition, to the war cry of 'simplify!', we have cleaned up a lot of other areas - UI Elements (no more URIs and a simpler conceptual model) - Commands (simple model, just a normal component with adapters that bridge to different UI control intances that can fire them.

http://www.gotdotnet.com/codegallery/releases/viewuploads.aspx?id=22f72167-af95-44ce-a6ca-f2eafbf2653c

I am feeling very good about this release. It will require a little bit of work to migrate from our last community preview, but the overall productivity you should get out of the new one should compensate it.

Backwards Compatibility and Enterprise Library and all patterns & practices assets -What's the deal?

edjez — Sat, 06 Aug 2005 05:18:00 GMT

Hello. How are you? Enterprise Library for VS.NET 2005 will have API and configuration changes compared to the latest versions (January/June). So will other blocks and a lot of the rest of the guidance....and you should expect this.

er...Is that a roar I hear approaching?

Why can't patterns & practices guarantee back compatibility in guidance, especially APIs of our assets? We want to! but from intent to guarantee is a long shot. That said, we do not change APIs and recommended designs without a reason. And we do try hard to make the changes affect the business logic less than the infrastructure and customizations & extensions. The components with the logic of your apps are your investment, your hard-earned jewels, and we want to preseve it more than anything.

I was asking around about this a lot during the last months - Feedback I've gotten during the field summit at TechReady and from customers coming to the building 20 lab devlabs to do early adoption of VS.NET 2005 is:

1) We need to be better at explaining WHY we broke compatibility
2) We need to give you early heads-up warnings on as soon as we think we'll change something - even if we don't know precisely into what yet
3) p&p should help you deal with the unavoidable changes in two main scenarios:
a) Forward-compatibility issues when putting old binaries on new platforms,
b) Migration guidance to move and recompile the code away from old assets to newer assets and the platform features

So... 1) Why do we break compatibility? Of course the precise answer goes by asset, but in general:

- We want to set you up better for the future The patterns & practices deliverables provide guidance 'aligned' (in the general direction) of the MS platform. When you are on your own, you have many options in the way you can design your code today. At the same time, there are many teams inside MS defining what the next wave of frameworks and apis will be like. Part of our mission is to 'align' your designs in the general sense of the platform, for two reasons. First, you don't want your application design to be a dead-end architecture wise when having the option to move to a new MS product. Customers consistently tell me this would worse than an API change. Makes sense to me. Second, the feedback and input you provide on the p&p assets gets channeled to and reviewed by the MS product groups. By making our deliverables increasingly closer to the platform we make your input relevant to affect the long term product so it gets closer to your emergent needs.

- We need to help you make the most of the platform targeted by the guidance . Would it make sense if patterns & practices assets, say, lost 10% performance so they could maintain API equality with a version built for a different platform? That doesn't smell like a good practice. It would be a short-time gain.

Would you move to the product? Of course, you would want to adopt to the MS product that provides similar functionality to a deprecated p&p asset for a multitude of reasons (backwards compatibility, better polish and tool integration, loads of documentation, long-term support with QFE and SLAs etc...it's the PRODUCT! not guidance on how to use a previous product...). Not to mention that you would not find a p&p asset competing with a MS product on the same set of requirements, because we just wouldn't do it. Updater application block and ClickOnce is a great example. If you are using VS.NET 2005 you use ClickOnce, not the UAB. Of course, you may have really specific requirements on the way a client does updates that you may decide to do something different than use ClickOnce- including reuse of chunks of the VS.NET 2003-based UAB, but I would seriously think twice about why your requirements are so special. You should also not expect an Updater bock for that matter. Of course, if we see 80% of folks tweaking / extending ClickOnce in similar ways, we'll continue the dialogue with the team who built it to determine which guidance to give around those needs. But let's get on with the topic du jour, breaking compat:

2) We need to give you early heads-up warnings on AS SOON as we THINK we'll change it

We can't eliminate the fact that thins will change, but if we give early warning of where, and more or less how, it will change lets you make your own tradeoffs and plan your investments. You need to understand the tradeoff here - if you want to know what will change before we actually know what it changes into, we're talking probabilities. Feedback I get is that you'd rather know our forecasts and that we revise them frequently than we keep them in the dark until we have the final precise answer. How do you get early warnings? if you don't see clear roadmaps push myself, our product managers (Tom Hollander, Eugenio Pace and Don Smith) and anyone from our team you can get a hold of (e.g. EntLib über dev Scott Densmore).

3) p&p should help you deal with change: in two main cases: forward compat and migration to newer assets and platform
a) Forward-compatibility issues when putting old binaries on new platforms,

This happens when you put an application, with your own unchanged binaries and binaries based on our code, to run on a new platform. You should know the CLR team application comaptibility test team runs all p&p application blocks as Tier-1 (high impact) code, so a .NET breaking change that affects these is a 'big deal'. Of course there is no way to predict where breaking changes will happen with 100% certainty, but the .NET team has put together a set of guidelines of things that are considered breaking change as they vary between versions, versus what is not, and we'll be part of that loop moving forward. While 0% is impossible, we can push the chances of issues happening to be quite low.

b) More migration guidance to move and recompile the code away from old assets to newer assets and the platform

We haven't done much of this yet but feel free to push us to do more. In my opinion this is a very dynamic body of knowledge, and something we should probably iterate on fast as the pitfalls and techniques are discovered. I would like to have this in a wiki somewhere.

Do these 3 points resonate with you?

Here is the tradeoff we need to navigate - and your input will help inform it. We (customers, partners, product groups, patterns & practices teams) all want the areas touched by common blocks and patterns that stream out of p&p to be part of MS product capability ASAP. But to be able to prove your need (i.e. prove the topics we touch are important to you), to release these things in a faster cycle (e.g. not the year after next), to align you better with future platforms (that undergo periodic redefinements themselves), to be best practices (on what you use today), and to inform the shiny new products with your feedback (so they are smack-on with your needs when they ship), we need to change our deliverables every once in a while. Considering this, let us and the community know how we can help you deal with this change. I've set up a wiki page in Channel 9 so candid thoughts can pile up.

Since the very beginning of the existence of our group, the p&p user community has helped us bring more value each year by giving relentless feedback and keeping us honest. As we deal with this platform change, please be as relentless and as much a partner in figuring out the solution as you have always been. Engage in a constructive dialogue, and we will be able to help you out in better ways.

The result will be better MS products, more focused on your needs, and smoother transitions for you between assets, as we continue to evolve this faster release vehicle to help you make the most out of Microsoft products.

p&p Community Process 2.0 is out!

edjez — Sat, 09 Jul 2005 05:57:00 GMT

We have relased the p&p Community Process to 2.0, incorporating feedback we got from customers, partners and field on the 1.0 version.

This one includes:

- A more realistic relationship between the internal process and externally visible process. In the 2.0 version now we open up the information about the project to the broad community as early as possible but still making sure we will actually have a project to ship :)
- More explanation around the options available for 'deeper' engagement - how to become an Expert Advisor and week-at-p&p, for example. This was done in an ad-hoc way before

Here's the URL. Please send us feedback if you have ideas on how we can work in a way that suits you better, or if you think having more visibility into specific aspects of our business would be valuable for you

http://practices.gotdotnet.com/releases/checkfordownload.aspx?id=60dd1bb9-0d1e-45e0-975a-a7f398697344&ReleaseId=cc9f9070-7133-4729-93dd-b088bd9a2e30

5 years of guidance groups at Microsoft! - What's your story?

edjez — Fri, 01 Jul 2005 08:02:00 GMT

5 years ago Microsoft executives approved the existence of a group focused on guidance - understanding enterprise customer scenarios, creating a dedicated engineering team to producing guidance in the form of code,patterns, frameworks and guides, and consolidating the authoritative content that enterprises would use under an identity. This team, called PAG internally, eventually became patterns & practices.

Some of us in the team put together some wiki pages with the motivations and approaches of our group, sprinkled with candid and colorful comments about how we got here, what it's like to be outside the normal product group hierarchy at Microsoft,and other interesting facts.

This is not just about explaining p&p - It's about having a 2-way dialogue with YOU -a conversation about why we exist, and areas for growth. We put it in a wiki so you can go and tell us your perspective and your own anecdotes.

The pages include things like:
- why did p&p get created, where does it live in the MS organization, and what's it like to be there?
- How do we explain internally and externally the difference between product stuff and p&p stuff?
- What are some of the things currently going on inside of our group? What tools and methodologies do we use?
- What are the observed trends and directions of our group?

http://channel9.msdn.com/wiki/default.aspx/Channel9.PatternsAndPracticesInsideOut

(We didn't have the time to make it to short but it's light reading)

I'm thrilled to work in this group and this paper is part of our commitment to be transparent and more effective at learning how to be your -our customers'- ambassador.

CAB Released...almost..any...second...now

edjez — Fri, 01 Jul 2005 05:55:00 GMT

The release day is the final battle with entropy. It's when the work of months seems to be put at risk and "die the death of a thousand paper cuts"...Xenon's paradox kicks in and every little task breaks up into some smaller tasks and it suddenly feels there is more work to do today than the rest of the year.. and there's always STUFF that happens... the version number changes...the MSI signature appliation does not work to someone's machine...links need to be reset to avoid 404s..someone needs surgery... no matter how much planning happens, the release day is a frantic, reactive, and a fun day no matter how much planning goes into it. My approach is to take it with a zen attitude of Expect the Unexpected, and go with the flow

To the CAB team: I consider it a privilege to have been part of this team.Thanks

To the rest of the world - get it via the MSDN page here once it goes live. The download link is already active, detective points go to those who find it on their own.

Read my previous posts to know what this is and what it contains

CAB - Code Drop 2 on its way

edjez — Fri, 10 Jun 2005 06:16:00 GMT

Hello all -
Its been great to see the community interest in CAB. Thanks for your support! (Join us here: http://workspaces.gotdotnet.com/cab)

We have 1000 users before our 2nd community drop!!!

As you know we are working hard to have an important release of CAB in July. This will be potentially the largest "pre-RTM" drop of CAB before VS 2005 releases, later on in the year. At that time we will refresh CAB to include feedback and additional features, work with Visual Studio 2005 .

For this release, we made a set of tradeoffs, and I wanted to share them.
1) We wanted to give you a high-quality and stable release early even if it meant additional incremental features would have to be added later on. We want to get your feedback on the fundamental elements of CAB and the development experience, especially as we plan the tooling for it.
2) We are holding ourselves to production-quality code standards & testing and we are building the best documentation experience we can within time constraints.

What does this mean in terms of what you'll get?
1) There's going to slightly less scope than you might have seen in slides and webcasts. The scope we have cut however is mostly "incremental" (can be added on later) or "invisible" (should not change the public API design or basic app architecture). Specifically we had to scale back on the following:

UIP. This is an incremental feature we plan on releasing to the community and integrating by the RTM date. It'll also give more time to the UIP community to react and give feedback to our candidate design.
Narrator. We understand that large applications built with CAB can benefit from a "visualization" tool that would assist understanding the runtime relationships between components. We have a lot of APIs (but no GUI) to help you see your application. Building this is important to let you undertsand, iterate, and communicate your runtime architecture, and thus helps you reach an application design faster.
UIElement Plugins: UI Elements are the way the Shell exposes shared UI thingies. We will include the fundamental architecture and 3 plugins for toolstrips, menu strips and status strips. Other useful UI elements (notification area icons & "balloons", splash screens, keystrokes, based on fancy 3rd party controls or ... clippy!) can be built following the same design.

As a matter of fact, I'm not too bummed out at having to postpone the UIP feature. The implication is significant. It means it's incremental. This is architecturally important and a result of our usage patterns of the container / component model "backbone" that holds CAB up internally. It means also that it doesn't affect your existing app at all (just like users of previous versions of UIP told us we really got in the way of how you built your UI layers. We solemnly promise to avoid the XML hell as well).

We are getting the test signoff emails on the preview as I type this, so as soon as Eugenio does the hand waving to get this on GotDotNet, you can get it yourself.

How Community Feedback is changing the CAB

edjez — Tue, 03 May 2005 03:58:00 GMT

I love how the CAB project is working with our community process. Not only does the transaprency give us a chance to ge great input from field, customers, partners and even folks at MS product groups; but it also is a nice forcing function to keep our house in order continoususly.

We started CAB iteration 7 on Monday. As we prep for our first code drop later this week, i was reminiscing about what feature areas we have changed so far based on our Expert Advisor team input, and on the customer developer team that flew in to sit physically with us and prototype their applications while giving us continous feedback on our CAB effort.

This list is too long to be exhaustive but here are some examples:

Adding more attention to shell-agnsotic modules and their architectures. I had originally envisioned that modules that built to be agnostic to the shell they are targeting would be the exception rather than the norm, and the ability to do shell-agnostic code was almost a pleasant side-effect of the initial design we had of CAB. Well, thanks to customer input this is getting a bit more attention now. CAB doesn't push you one way or the other, but we are placing a more focus on the shell-agnostic scenarios than we originally planned to.
Startup sequence: the initial architecture had the three main services CAB uses (Authentication, CatalogReader and ModuleLoader) as plug ins - now the bootstrap sequence itself is a plug-point as well after working with one customer who needed to inject work between loading the solution profile and actually loading the relevant modules. Now, if you put no config, "it just works" and of you start adding config you can just change the plugin implementations, or directly declare a type of your own to run the bootstrap (for advanced cases).
Renaming Contexts to WorkItems. It was hard for us to find a good name (Context? UseCase? Task? WorkArea? ApplicationController?) Thanks for all of those who chimed in. Again, context is such a powerful concept and metaphor, that the word can easily be misused/abused.
WorkItems accessing parent and children workItems now you can do (in a WorkItem class) this.WorkItems["xyz"]
Event Broker: The use of URIs to identify event topics and the automatic background thread attribute

This is just a sample list. We are currently working on Enterprise Library for VS.NET 2005 and we'll conduct our engineering process in a much more transparent way than what we did with EntLib v1, so hopefully that will let you plan around it (and influence our engineering) more and more often.

Today Tuesday I'm in the -other- bullpen, the EntLib one. Brad and Fernando are there, and Scott will be in any minute now. Today is our iteration planning, I have to give an entlib intro talk (I try not to do too many talks but Ron and the devs all had to bail out last minute) and then I'm off to Seattle downtown to work with Avanade on a process by which we can have shared engineering and planning. This process is to let redistributors of p&p assets understand how to partner themselves in with our own teams work, to help them extract the most value out of our effort.

CAB -Event Broker: Pub-Sub for your components

edjez — Thu, 21 Apr 2005 04:34:00 GMT

Yesterday we finished some cleanup refactorings around the EventBroker feature of CAB. I'm happy with the result, because it's conceptually simple, it's easy to use, and it isn't much code, yet it helps a lot. I expect some things to be added before release but here is pretty much the core of it as it is right now.

The Challenge

A lot of the CAB features revolve around integrating components in complex, "smart client" apps. A good pattern to integrate components and notifications is to use Pub-Sub (publisher-subscriber) mechanisms between the services.

Forces
These are some factors influencing the design:

Notifications & events one-way are necessary in UI design between visual and non-visual components
Publishers & subscribers don’t know about each other
You may have sources without handlers and viceversa

CAB Solution

CAB has the following concepts around pub-sub:

Publishers are components that want to raise events, subscribers are components that have methods that are called when events get fired.

Events have an Event Topic. An event topic is the identifier of the event, like "event://Business/Customers/CustomerAdded". The event topic actually also holds a list of WeakReferences to the publisher and subscriber instances, to make sure the event subscription is not the reason why they won't get GC'd.

Events publishers and subscribers may fire off events within a bounded Scope. The scopes CAB allows for are WorkItem-Wide (only components within the WorkItem , and the WorkItem class itself, can get the event) and Global (the default - any component or service anywhere under the Host will get it). Scopes allows you to fire events with the same topic to only interested parties. We evaluated other design options (e.g. get that scope info into the event URI) but they complicated the usage + implemenentation a lot, so we stayed away from that.

Event Subscriptions can be made specifing it for Background so that the subscriber method will be called in a BackgroundWorker thread. This allows you to easily add multithreading into your application without having the caller have explicit knowledge of it. You would use this to access backend web services or work like that, but you wouldn't affect the UI from these other threads. Of course, you need to undestand since this is a one-way pub-sub mechanism, it doesn't make sense to pass the BacgroundWorker to the subscriber since there's no one to flag completion or report progress to (a basic intro to BackgroundWorker here).

Finally, event publications and subscriptions can specify a Strong-typed argument to be passed around. The effect is similar to you using the Whidbey EventHandler<T> feature.

//a publisher class
public class AppleTree
{
   [EventPublication(“event://FallingApples”, EventScope.Global)] 
   event EventHandler<int> ApplesFalling; 
   
   public void MakeApplesFall()
   {
    … 
      //fire the event as a normal event
      if (ApplesFalling!= null) 
      {
         ApplesFalling(this, 4 ) ;
      } 
   }
}

 //some subscriber class in the same or some other assembly
public class MySubscriber
{
   [EventSubscription(“event://FallingApples”, EventScope.Global )] 
   public void ApplesFalling(object sender, int numberOfApples )
   {
      if (numberOfApples > 2 ) 
      { 
         //start picking them up
      } 
   }   
}
 
 
//another subscriber class in the same or some other assembly  
public class OtherSubscriber
{
   [EventSubscription(“event://FallingApples”,EventScope.Global, isBackground=true )] 
   public void ThingsOnTheGround(object sender, int numberOfApples )
   {
      //turn on the oven to do an apple pie
      //...this will run in a different thread than the activity 
      //that fired the event
   }   
}

In CAB we have an API style that lets you do everything programatically - good API design and a healthy side-effect of using TDD. The attributes are there for simplifying the dev experience - they get processed whenever an instance of the class that has them gets added to a WorkItem or the Host in CAB. More about WorkItems later.

Related Patterns

Remember my last post - patterns for integrating on the client are conceptually the same you use to integrate multiple services - So here is the pub-sub pattern described by Gregor Hohpe http://patternshare.org/default.aspx/Home.PP.PublishSubscribe, given disclaimers, same concepts apply. Our event broker in this case is a list-based pub-sub (it's not content-based, which would be another way of identifying events - instead of by "topic" and implying type, by type of data being exchanged only). The Mediator [GoF] in this case is the EventTopic object, and we have a Registry [Fowler] that holds the list of these Event Topics.

Those belonging to the Expert Advisor Board for the CAB project of the will be able to see this in action in the next iteration conference call. We are currently working on our packaging of the first drop and you'll see this code if you download it from our GotDotnet workspace, once it's available.

Feedback? ideas? post here or join the new workspace at GotDotNet

CAB - Composite UI Application Block Ready to Kick Off!

edjez — Tue, 19 Apr 2005 04:20:00 GMT

Great piece of news - today in the patterns & practices group we went through our M0 milestone for an exciting asset to assist with Smart Client development.

We are calling it the CAB - which stands for Composite UI Application Block. It is not a great name, because it doesn't tell you much about it either directly or metaphorically (yes, if you have suggestions let us know). Here are other names you could give it:

- Smart Client Portal
- Extensible Shell
- That-Which-Includes-The-Functionality-Of-UIP-Windows-and-More

We will be publishing more about it pretty soon. Here is just a 20.000 feet AGL view.

CAB 101

Complex smart client applications have a growing need to be built and deployed as separate packages, packages that may contain visual and non-visual components that need to collaborate (AKA find, and communicate with) other components to perform the work. Patterns to tackle the ensuing challenges exist and the CAB helps you implement these patterns by providing infrastructure code you'll need.

The main areas the CAB helps with are:
a) Apps built of "modules" or plug-ins. In this scenario, typically a general-purpose shell is built by a "shell development team" or the dev team with a "shell development" hat on and business logic gets deployed as add-ins. Here you'll need common infrastructure like a catalog of plug-ins, a plug-in loader and an interface for your plug-ins with events such as ApplicationStart, BeforeApplicationClose and so on. CAB has an implementation of this that is extensible.

b) Component Collaboration Patterns: Apps may integrate many components visually and non-visually to fulfill a use case. There are many patterns that help here like MVC, Application Controller, BlackBoard, Memento, Service Locator and so on. CAB will have common infrastructure to help with these patterns.

here are some teaser snippets that we are building to - these are either part of our codebase already or will be soon. These are mostly about non-visual component interaction - we'll deal with the visual part in a future post (and that'll give us the team a chance at stabilizing the designs a bit more :) )

Example 1: Simplify finding and connecting to events across components, even with your own eventArgs

public class AAA 
{

    [EventHandler("event://MyApp/UpdatesAvailable")]
    public void UpdatesAvailable(object o, UpdatesAvailableEventArgs)  
    {

      ...

    }  




}

public class BBB
{

    [EventSource("event://MyApp/UpdatesAvailable")]
    public event EventHandler<UpdatesAvailableEventArgs> UpdatesAvailable;  





}

Example 2: Reuse of use cases encpasulated as a class for a modal interaction:

FindCustomerContext fcx = new FindCustomerContext();
myId = fcx.FindCustomer("WA");

Example 3: Referencing a Controller frm a View (e.g. for MVC), injection style (shown on a field for simplicity):

public class SomeView
{

    [Controller]
    public CustomerUpdatesController myController;





}

Example 4: Finding infrastructure services, again injection style:

public class AnyComponentYouBuild
{

    [ServiceDependency]
    public IMyLogggingService logger;

    
    public void DoSomething()
    {   
        //use logger .... 
    }





}

 Example 5: Adding UIP, or use cases with a strong "process control" need, using UIP whatever-process-style-you-like (e.g. petri nets for the fans out there). This area is not implemented yet but here is a teaser nevertheless:
 
 
 
public class MyProcessDrivenContext  : Context
{

    [Navigator("My Navgraph")]
    public MyNavigator navigator;

    
    public void DoSomething()
    {   
        navigator.DoTransition("AddOrderItem");
         //or a strong typed flavor, since you've taken the work to build your own Navigator:
        navigator.DoAddOrderItem()
        
    }





}

CAB Plans

Explaining CAB Plans is better left for eugeniop (our product manager), all I'll say for the moment is that we want to have a technical preview hopefully before august, based on VS.NET 2005 Beta 2 so you can play with it.

/other/etc

A little bit of introspection on CAB...

There's many things I like about this project, from the team, technical and architectural perspective.

Team: Peter Provost is our Dev Lead, with Daniel Cazzulino, Juan Carlos Elichirigoity & John Luif as devs, Rohit Sharma as our test lead, RoAnn and Lin Joyner as our UX arm. Bill Loeffler is keeping us all on track as the PM and Eugenio is the product manager. The team is full of brilliant people and I've enjoyed working on it from day 1. This project has also strong legacy from David Hill and his team - he and Brenton Webster have been working with customers in this scenario for a long time and they help us "mine" the patterns that customers face.

Process: We are following our Smart Client community process. One thing we learnt is that it's good idea to have a staged approach with regards to the announcements of patterns & practices deliverables. So we have modified the process to first have a set of conference calls with the expert advisors only, and expand to include the world in the community by M0. This means that we have had already (3 or 4) roundtable sessions with product group, partners, field and customers to discuss CAB concepts and design. Internally we are doing a TDD, agile, everyone-in-the-same-room-as-much-as-they-can 2 week iteration approach (emphasis on as-much-as-we-can). We are switching to 1-week iterations as of today. We keep all our spec as part of the public documentation in an internal wiki, and a build-per-checkin rythm for continuous integration. So far it's worked out great.

Architecture stuff: One of the things that strike me the most however may even be called predictable. The principles that drive the integration patterns that exist across organizations and SOA-style services somehow get expressed in mostly similar patterns, at a smaller scale within a client application process. Computing and complexity of applications is growing and the patterns we have used to integrate large systems are making their way inside our applications.

Take some inter-system integration things for example - Communication tenets and state ownership best practices to general patterns like event brokering, and process control, are all driven off a basic set of principles that are scale-invariant. Especially as the CPUs applications are built with become capable of more parallelism (HT, multi-core, and so on), we will have to build components that can run concurrently and share information with predictable rules - and it will demand for capabilities that go beyond the lock, mutex and sempahore style that we are used to today. Those things don't scale to share state at the enterprise level (of course, that's not what they are for, but I'm trying to make a point) but in some time in the future they may stop being good ideas as ways of having multiple activities work with data even in the same process on a client.

Would you like to "grade" patterns & practices projects based on project execution?

edjez — Fri, 01 Apr 2005 16:38:00 GMT

In the Smart Client Program we have been working in a way that involves community in building p&p guidance, especially the application blocks, and lets expert advisors and community members influence the project execution, all the way to allowing the community to vote on our go/no-go process. We had a first try of the process with the Updater v2 block. I'd say that the CAB (Composite UI Application Block) project that's about to go public is a showcase example of this.

The Smart Client process is in many ways a "pilot" of the way we want to work with community. Working in this way has 3 main goals, driven by your feedback: Increase the trasnparency of our project execution and prioritization, increase the traceability of requirements to features and help adoption by making sure the scope, documentations and quickstarts have had extensive early input before shipping.

The question I have is - if you feel that a p&p project has surprised you (suddenly come out and not letting you plan around that event, or building it in an opaque way and not letting you see early drops) or you would have liked to have more involvement during planning or development, send feedback around that to devfdbck@microsoft.com as well.

Hopefully we could get to the point where you can "rate" us on the end deliverable but also on "how" we got there. Like we might get a "7 out of 9" on the block itself, but "5 out of 9" on the way we managed the process. Until we get there, please rave and rant and suggest to that email.

Thanks!

My Performance Review Document - Are these the right things to be working on?

edjez — Thu, 24 Mar 2005 04:05:00 GMT

I had a conversation with Ward today where he was asking me if it was common for folks in MS to share their goals (what you go against when you do performance appraisal) as a way of communicating to others what they are working on.

It led me to think about a lot of things, but especially:

1) How the performance and review process works at Microsoft. As with any measurment system that takes a zillion technical and human factors and bangs it into a scalar value, it has a lot of issues. However, I noticed one thing: How I (and many others I admire) give a flying (d)uck about the score, especially if the perception is that there is a tradeoff between getting a better score or doing what's right for the team and business. Regardless of the score, MS tends to be a place where doing the Right Thing tends to get rewarded one way or the other in the end. Kudos to the leadership on that.

2) How I share my goals with anyone internally on the asking, yet haven't shared it externally. As one of the architects in the patterns & practices business, and the architect of the p&p EntLib and Smart Client Program and VB6 migration and what not, what I focus on has an impact on what you see. So, I think I owe it to you to all to share what I get measured on -

My Review Document

So, always your humble servant, here is my list of "commitments" for this year at MS. Am I focusing on the right things? Any disappointments? Anything glaringly obvious that is missing? Are our priorities right? Some things need translation from the "lingo" it seems to be written in, I'll happily clarify rather than masage it too much before posting and loosing the candor of it.

Commitments	Execution Plan	Accountabilities
p&p Community Process	Initiate in Smart Client and evolve to 2.0 status Define scenarios in terms of baseline architectures as composition of patterns implemented via tools and block libraries	• Expose roadmaps for programs quarterly • Proactively engage in the dialogue w the community as a key resource during the p&p lifecycle w other PAG resources, like feedback and priorities around scenarios, technical challenges, requirements, design options, features, and structured feedback of the asset during the phases Define baseline architectures for key scenarios (Smart Client) and expose to community and luminaries. • Identify and promote MVPs and re-usable asset opportunities • provide and review site requirements, features and roadmap • define p&p asset/guidance lifecycle
Quality Reach: Develop a compelling library of patterns & practices deliverables that are deeply integrated with Microsoft web, events, marketing campaigns, community and partner programs that drive a 20% improvement in awareness and usage of patterns & practices with the professional developer audience.	LOB Enablement · Enterprise Library V1 and V2 Integration · SOA Reference Implementation built on EntLib Smart Client · SC Reference Implementation	* Develop architectural roadmaps for programs including relationships between projects and with other programs, updated quarterly based on PdM + community input * Provide gap analysis between customer scenarios related to p&p programs and current/future product features. * Develop a technical strategy that aligns current and future products * Develop roadmap of assets per program including relationships between projects and other programs * Technical contribution to product group review, signoff, endorsement of deliverables incl industry / luminary reviews and endorsements * Review and feedback on priorities, prototypes, technical specification (e.g. high level design), tests and development guidelines (including NFRs), test plans and end deliverables
Product Group imitating p&p SDLC for assets	Prerequisite: Roll out community process Assist PG in establishing their own Expert Board	1 product group led p&p project "Place" in p&p frame for such project
EntLib Whidbey	Plan and build team around EntLib Whidbey, provide technical direction and relationships with PG	PG signoff on EntLib-Whidbey P&p members signoff on p&p Whidbey Smart client initiative can build on EntLib-Whidbey Align EntLib w the directions of MBF and get a technology roadmap in place for PAG and MBF
Patterns & Blocks	Establish & expose 2 way relationships between patterns and EntLib app design	Patterns shipping in EntLib, Implementation-level patterns for EntLib. Expressing LOB scenarios as pattern composition
IPE	Ship working Everett or Whidbey code generation / recipe / transformation mechanism	CodeGen present in EntLib, Smart Client, or some other deliverable
PG Feedback	Design shared schema for arch reviews w prioritized aggregated data PdM sign-in to deliver	2 Arch reviews by FY end + 1 exec review * Contribution and review of the scenarios. * Participate in product group reviews
R&D – Emergent	Identify PGs relevant to AOSD Expose thinking from experts to relevant folks	PG Feedback on AOSD 1 PG relevant member in external AOSD community
P&p Architecture transparency	TBD, scoped to projects & programs allocated to me.	Publish an architecture review checklist by end of Q1 for Reference apps, patterns, and blocks • Perform architecture reviews prior to M1 and prior to release for all pag deliverables and publish results and signoff on all pag deliverables. • Develop architecture roadmap to ensure the technical integrity across pag deliverables by Q2 • Provide vision for roadmap and product types. • Develop and maintain templates for design/artifact specs by product type by Q2
Library	Inclusion of assets in library/ies w integration between and across p&p assets Adoption of the block spec – are there other specs that should be created and adopted	One MSIT, customer or partner asset built to asset spec Delivery of asset specification as key feedback to WhiteHorse / Software Factory initiative

Some things I won't be able to get to do, obviously, by the end of the fiscal year (June 30) so I'm blowing my own cover. :)

Note this is a copy and paste from the core of doc I submit to my manager and to the HR system that then gets reviewed stack-ranked (yeah I know it could be more humane) and all that stuff. Salary, bonus, etc if any gets worked out from this. If you give me feedback I'll consider it and as appropriate put it into next year's goals. And if you have feedback such as "Where does it say app blocks will get simpler?!" "I don't see any consideration of using emergent patterns such as IoC" or "I'd like to see something saying you'll put all p&p documentation in a public wiki" just please suggest it with a way of measuring and evaluating that the result was reached.

I consider this an experiment.

Thanks.

Hook up to your GPS with .NET

edjez — Mon, 21 Feb 2005 06:58:00 GMT

Looking for the killer CAB demo...
This week we spent a considerable amount of time working on the CAB - Composite UI Application Block ..aka Smart Client Portal. Part of the value it provides is simplifying how visual components (SmartParts - think WebParts for windows) find, share data with, and control each other.
One of the good things about this composable apprach is that it lets different teams with different expertise independently build and deploy SmartParts and support services that the end user will see in his UI . So I was thinking of a killer demo of how value can be added for incrementally to apps, that highlighted the smart client benefits. I thought of some options - such as displaying a clock (big deal..), a regional weather report (better, but dèja vu thanks to Thunderbird..), and wasn't convinced of the options I was coming up with.

Enter the nifty GPS gizmo...
So it happened that I was at the Microsoft Employee store and found a good deal for the Microsoft Streets & Trips 2005 with GPS Locator. At $60 with discounts, I could get a reasonable GPS, even with WAAS compatibility (WAAS is a GPS feature that gives extra horizontal and vertical precision, increasingly used by airplane pilots. Without going too much into it, augmented GPS could eventually phase out other precision approach techniques for landing airplanes such as ILS, and it caught my eye a 5cm x 5cm x 1.5 cm GPS receiver had it). I connected it to my computer and after installing the USB Serial Port driver I had my Streets and Trips displaying my location with a car icon on a map:

Note that my house was moving slowly (1 mph) at the time of the screenshot. I blame it on GPS inaccuracy and not giving it enough time to average out my position, but then again, the terrain is quite slanted and I could be drifitng, study laptop and all, into the lake as I write this....

Doh! Cool demo idea: Physical Location & GPS display
OK, not everyone has a GPS and not every conference room has good GPS reception but what the heck - I decided to code a little LocationService and associated SmartParts to display stuff. If the Streets & Trips team did it, so can I..Well after a little rumagging I figured out my computer was seeing my GPS (connected via a USB cable) as a serial port. If I could hook into the communication stream, I would be able to process the data and have my service tell any smart client app built with the CAB the position, speed and other GPS trivia.

Hooking into the GPS stream:
First step was to figure out what type of communication went on between the GPS and the computer. Knowing it was a COM port, I opened HyperTerminal and hooked up to the COM port as in the old dial-up days. Not knowing the nature of the protocol and with a slight reminiscence of my telco days, hooked up and started seeing what I could do. Surprisingly (whew!) the protocol was just an incoming stream with nicely-formatted data and sentence delimiters.

This is what it looks like. Note that with very little squinting patterns and obvious data points start appearing:

The documentation with Streets & Trips about the physical GPS was very little (granted, I'm not the typical audience, but..) and had to look around before finding that the protocol was part of a standard called NMEA (duhh..it was printed on the box). A couple of google searches afterwards, I was in posession of a good document with the full protocol state machine and enough parsing info to get me started. The GPS supports NMEA 2.0 but apparently it hasn't changed much in the basics.

The Visual GPS guys did a great job of explaining the protocol - Thanks Monte Variakojis for the NMEA Parser Design paper & the permission to blink. I'll let you know when I post the code & good luck with your IXMLDOMDocument issues.

Reading COM ports from .NET
The next step was hooking into the COM port stream using .NET. I knew COM ports are treated by Windows as file handles, so it was a matter of writing up some tests for initialize, read and close functions and doing a simple helper to fullfill them (no, there won't be a SerialPortAccess App Block). Here www.pinvoke.net was of invaluable help. I love Wikis, and hopefully my edits left it a little bit more complete than I found it, especially the DCB structure.

Once I had my serial helper up and running, I hooked it up to a simple window and tada! I had my GPS data streaming in and dumping to a textbox. Notice the occasional screwed up sentences. Fortunately the protocol is very robust - i.e. I can ignore bad sentences and move on to the next one.

Parsing the NMEA protocol
The NMEA protocol is quite simple - essentially the data streaming in is in a series of sentences clearly delimited by $GPxxx and \r\n. It has a couple of checksum characters at the end, and all the data in between is comma-delimited in the 1252 code page. My NMEA protocol parser just walks the bytes checking for full sentences and verifying the checksum - once a full sentence is found and verified it is a matter of passing the string over to a specific function that knows how to parse the sentence type. Different sentences have different information - e.g GPGGA has stuff about your location, GPGSV has information about the GPS satellites, and so on.

After passing basic unit tests, and trying out example sentences, the code was ready to parse real data.

Here is my example window with a simple disply of the GPGGA sentences, with my latitude, longitude, altitude and zulu time:

<Digression topic="Model-Driven-testing">
Protocol parsers are a great place to use Model-Driven-Testing, but I lacked the tools or the intent to try it out with this excercise. Model-driven-testing is an approach where you use a model (e.g. a state machine representation) as a verfication tool. You could then write tests against the model, or the model itself can then be used to generate tests. I think there may be promise in the future in this type of tools - you keep the inductive, TDD approach to development, but you use advanced tools to create better tests with better coverage of common and edge conditions.
</Digression>

Displaying Satellite Locations

I set my end-goal to be able to show which GPS satellites are hovering on my head and where - fortunately this is part of the information provided by the device. With elevation (degrees from the horizon) and azimuth (bearing degrees from true north) info I could build this nifty display of the information:

The dots represent satellites - the closer they are to the center, the closer they are to being "right on top" of the receiver. In the picture, the satellite on the top of the outer circle was then very close to the horizon, looking northward from my study.

Integrating it into CAB

Next steps will be integrating this with my own CAB SmartPart as a utility SmartPart. I imagined I could have a SmartPart based on the Streets & Trips control that displays a location provided by a CAB event, and directions from the current latitude and longitude, courtesy of my PhysicalLocation service. But Doh! I left my VPC with my Whidbey + CAB stuff on the external disk @ the office. I guess I'll post the code to GotDotNet or something once I've cleaned it up.

I wouldn't use this code as part of an airplane autopilot :) but if you are interested in this or the CAB just post here. Enjoy!

Links & Resources
MS GPS & Streets+Trips product with the GPS Locator: http://www.microsoft.com/streets/ProductDetails.aspx?pid=001
The not-so-helpful KB article on accessing COM ports: http://support.microsoft.com/default.aspx?scid=kb;en-us;823179&Product=vb6
Essential interop resource - http://www.pinvoke.net/
The best NMEA 0813 description I could find: http://www.visualgps.net/papers/nmeaparser/NMEA%20Parser%20Design.htm

VB6 --> VB.NET Guidance

edjez — Tue, 08 Feb 2005 09:35:00 GMT

This is not about EntLib and not about Smart Client specifically, but we expose some plans soon around working on VB6 --> .NET guidance focused on Enterprise customers' LOB apps.

Part of the challenge with this guide will be finding and keeping to the line that exists between:

The 6 tomes of 8000 tips & tricks (which would be ludicrous for PAG to attempt building, rather we'd work with the community to work on this in a way that is consumable by different audiences, so the expertise, the credit, and the liveliness of the data is all driven by current demand)
Fluffy guidance - The high-level blurbage of "VB.NET is good for you there's tools 'here' (link to some tool) and articles 'here' (link to some article)"

We want neither of these - In the end, good guidance will have to include:

Some process guidelines (deciding, planning, preparing, implementing, verifying, etc)
Some app structure guidance guidance (vertical & horizontal partitions, interop and migration, implementation, design & architecture tradeoffs, etc)

Some of the characteristics we want to make sure 'percolate' the work is:

Explicitly tackle 'Choose your own migration strategy' - helping you identify where you're currently at, and what is the right destination against your goals
- maybe all you can afford, or need, is a plain line-by-line move. On the other hand, you might want to do something about those 4000 lines of code in Button23_Click, and move them into some other class to have a better design, so this is the perfect opportunity for you. No, this is not about re-architecting for SOA, but just about eliminating sources of cost down the line (and most importantly, letting you choose what plan makes sense for you)
Focus on app scenarios - identify the shape of the app you start with and want to end with as a way of making the technical content more relevant (app scenarios include Windows-COM+-SQL, ASP-COM-SQL Windows-SOAP Toolkit-ASP page etc... example use-case scenarios include reporting, CRUD, transactions, office addins, you get it)
Highlight learnings from the collective experience - what are the common pitfalls, patterns, and antipatterns, in this type of effort.
Make the content usable - provide checklists, how-tos, etc.
Make the content 'extensible' - we're still looking into how this will happen but I'd oh so much like a wiki focused around this topic to exist out there. Otherwise we'll have to look into creating one, I guess. Hint hint nudge nudge.
...ah other things but it's too late right now and you get the jist of it. We'll be working with many community folks on this and we'll be presenting them pretty soon.

A good friend of mine, and someone I trust for foresight and insight, referred me to the "I've saved a nickel" Windows 2003 commercial. (If anyone has a video capture of it pls let me know) The point is, the economies of scale you could get out of just squeezing some savings from the VB6 app as it moves to .NET are huge. AGH, you see? That sounded like a marketing dude. ... Looking forward to this project.