Glenn Block

Firing generic events with EventAggregator

Glenn Block — Fri, 22 Aug 2008 10:08:00 GMT

It's been a while since i posted anything on Prism. When I left p&p, i said you would see more posts on Prism on my blog. I've been pretty immersed in MEF since leaving and haven't done any posts on Prism yet. Today, I got inspired (albeit late in the evening) based on a post on the forums to actually do that, so here I am :-). The post was from TSChaena about using EventAggregator to fire generic events similar to the way we did things with EventBroker in CAB. Using EventBroker allows you to dynamically define events in your application that are identified through a topic name rather than needing to define a strongly typed class as you do with the EventAggregator. There are several advantages to not using the approach in EB which I have identified in this post. However, there are times when you want to do a dynamic eventing system. The good news is that there actually is a solution for doing this with our EventAggreator though it is not exactly the same as the way we did it in EB.

CompositeWPFEvent

Before we look at the solution I came up with, lets talk quickly about CompositeWPFEvent. CompositeWPFEvent is a generic class that contains one type parameter TPayload. TPayload defines the payload that will be passed into the event when it is fired. The subscriber also uses the payload to provide filters for the subscription. For example if TPayload is a FundOrder as in the EventAggregator QuickStart, then you can supply a lambda such as fundOrder=>fundOrder.CustomeriD == customerID for example to filter on only events that are received for a specific customer. The common pattern you will see for defining such events is to create a class that inherits from CompositeWPFEvent for each event that is typed to the specific paramers. For example below is the definition for the FundOrderAdded event.

public class FundOrderAdded : CompositeWpfEvent<FundOrderAdded> {}

This event is then retrieved from the EventAggregator by calling the GetEvent method passing FundOrderAdded as the event. Now, although this is the common pattern, there is nothing about the EventAggregator that requires you to create a new event class for each event. CompositeWPFEvent is not an abstract class, so you can simply "use" it as you will, even in a generic case. For example you can do the following.

   1: public class ThrowsEvents {

   2:   public ThrowsEvents(IEventAggregator eventAgg) {

   3:     eventAgg.GetEvent<CompositeWPFEvent<string>>().Publish("SomethingEvent")

   4:     eventAgg.GetEvent<CompositeWPFEvent<string>>().Publish("SomethingElseEvent")

   5:   }

   6: }

7:

   8: public class HandlesEvents {

   9:   public HandlesEvents(IEventAggregator eventAgg) {

  10:     CompositeWPFEvent genericEvent = eventAgg.GetEvent<CompositeWPFEvent<string>>();

  11:     genericEvent.Subscribe(action=>Console.WriteLine("SomethingEvent fired", ThreadOption.UIThread,

  12:       false, e=>e == "SomethingEvent");

  13:     genericEvent.Subscribe(action=>Console.WriteLine("SomethingElseEvent fired", ThreadOption.UIThread,

  14:       false, e=>e == "SomethingElseEvent");

  15:   }

  16: }

If you look at the above code, you'll notice that we are using CompositeWPFEvent event directly, rather than creating a specific inheritor. When we call for the event from the aggregator, we are passing in a param of type string which represents the EventName / Topic. I am then using our event subscription mechanism to subscribe two different handlers to the same "event" by using the eventName as the filter. So here we have the basics of doing generic event publication and subscription. However, we are missing something important....that payload :). To handle this, you could instead create your own custom class that carries two parameters, EventName, and Value. With that approach, you can pass both the event name and the value, still filter on the event, and you can pass a value along. For example the above code passing a value would look like the following.

   1: public class SomeEventParams {

   2:   public SomeEventParams(string eventName, object value) {

   3:     EventName = eventName;

   4:     Value = value;

   5:   }

6:

   7:   public string EventName {get;private set;}

   8:   public object Value {get; private set;}

   9: }

10:

11:

  12: public class ThrowsEvents {

13:

  14:   public ThrowsEvents(IEventAggregator eventAgg) {

  15:     eventAgg.GetEvent<CompositeWPFEvent<SomeEventParams>>().Publish(new SomeEventParams("SomethingEvent","SomeValue"));

  16:     eventAgg.GetEvent<CompositeWPFEvent<SomeEventParams>>().Publish(new SomeEventParams("SomethingElseEvent", "SomeOtherValue"));

  17:   }

  18: }

19:

  20: public class HandlesEvents {

  21:   public HandlesEvents(IEventAggregator eventAgg) {

  22:     CompositeWPFEvent genericEvent = eventAgg.GetEvent<CompositeWPFEvent<string>>();

  23:     genericEvent.Subscribe(action=>Console.WriteLine("SomethingEvent fired" + action.Value, ThreadOption.UIThread,

  24:       false, e=>e.EventName == "SomethingEvent");

  25:     genericEvent.Subscribe(action=>Console.WriteLine("SomethingElseEvent fired" + action.Value, ThreadOption.UIThread,

  26:       false, e=>e.EventName == "SomethingElseEvent");

  27:   }

  28: }

That's OK, except now the parameters are simply object. That means we are losing the type safety that the EventAgg was built for in the first place! Now you can further refactor and make SomeEventParams a generic type that accepts a type param for the value. The only downside of this, is the code will get much more verbose and harder to read. For example retrieving the event to publish will now look like...

eventAgg.GetEvent<CompositeWPFEvent<SomeEventParams<string>>().Publish...

Suboptimal. I bet your thinking you could refactor this a bit more..yes, you can. This is what led me to a GenericEvent.

GenericEvent

If we keep refactoring, we can get rid of alot of the DRY behavior, by creating an inheritor of CompositeWPFEvent, GenericEvent. The event and associated parameters class looks like this

public class EventParameters<TValue>

  public string Topic { get; private set; }

  public TValue Value { get; private set; }

  public EventParameters(string topic, TValue value)

    Topic = topic;

    Value = value;

public class GenericEvent<TValue> : CompositeWpfEvent<EventParameters<TValue>> {}

Subscribing and publishing is now easier as well. The previous GetEvent code now looks like

eventAgg.GetEvent<GenericEvent<string>().Publish...

Because I have strongly typed my Value, I know have back my strongly typed filters and delegates.

Putting the rubber to the road with the EventAggregation QuickStart.

In order to test this out, I took a copy of the EventAggregaton QuickStart that is included with the Prism bits, and I modified it to use the new GenericEvent. I also added a Remove button to the QS in order to demonstrate using more than one event. The new Quickstart looks like the following.

In the new version of the Quickstart, the FundOrderAddedEvent is removed. Instead, I have added two constants to define the different events.

public class Events

  public const string FundAdded = "FundAdded";

  public const string FundRemoved = "FundRemoved";

I added a RemoveFund method to the AddFundPresenter as well as refactored the AddFund method as follows.

void RemoveFund(object sender, EventArgs e)

    FundOrder fundOrder = new FundOrder();

    fundOrder.CustomerId = View.Customer;

    fundOrder.TickerSymbol = View.Fund;

    if (!string.IsNullOrEmpty(fundOrder.CustomerId) && !string.IsNullOrEmpty(fundOrder.TickerSymbol))

        eventAggregator.GetEvent<GenericEvent<FundOrder>>().

          Publish(new EventParameters<FundOrder>(Events.FundRemoved, fundOrder));

void AddFund(object sender, EventArgs e)

    FundOrder fundOrder = new FundOrder();

    fundOrder.CustomerId = View.Customer;

    fundOrder.TickerSymbol = View.Fund;

    if (!string.IsNullOrEmpty(fundOrder.CustomerId) && !string.IsNullOrEmpty(fundOrder.TickerSymbol))

        eventAggregator.GetEvent<GenericEvent<FundOrder>>().

          Publish(new EventParameters<FundOrder>(Events.FundAdded, fundOrder));

Finally, I refactored the ActivityPresenter in a similar fashion

public string CustomerId

    get { return _customerId; }

set

        _customerId = value;

        GenericEvent<FundOrder> fundOrderEvent = eventAggregator.GetEvent<GenericEvent<FundOrder>>();

        if (fundAddedSubscriptionToken != null)

            fundOrderEvent.Unsubscribe(fundAddedSubscriptionToken);

            fundOrderEvent.Unsubscribe(fundRemovedSubscriptionToken);

        fundAddedSubscriptionToken = fundOrderEvent.Subscribe(FundAddedEventHandler, ThreadOption.UIThread, false,

                                                     parms => parms.Topic == Events.FundAdded && parms.Value.CustomerId == _customerId);

        fundRemovedSubscriptionToken = fundOrderEvent.Subscribe(FundRemovedEventHandler, ThreadOption.UIThread, false,

                                                     parms => parms.Topic == Events.FundRemoved && parms.Value.CustomerId == _customerId);

        View.Title = string.Format(CultureInfo.CurrentCulture, Resources.ActivityTitle, CustomerId);

Notice how in the subscription I am now filteirng on the event Topic in addition to the value. This is the result of moving to a generic event.

Wrapping Up

Using the approach show in this post, we've seen how you can utilize the existing EventAggregator infrastructure to do generic eventing similar to the way EventBroker in CAB functions.

Personally I think using strongly typed specific events is more maintainable. The reasoning is because the event payload type is intrinsically defined to the event wheras in this model they are not. For example with generic events I might have an event that publishes passing a customer, but on the receiving side I have defined it as a string. This event will never get handled, because the susbscriber and publisher don't match. If you use strongly typed events that is not the case, as the type is the match ;) However there are scenarios where it may make sense to have something more dynamic, for example if you have a metadata driven system that needs to do dynamic wiring.

Attached, you'll find the code for my modified version of the QuickStart. Let me know if this works for you. Now time to get some sleep :)

ForEach, a simple but very useful extension method

Glenn Block — Tue, 19 Aug 2008 07:46:00 GMT

This evening I was writing some code (Yay!) for an Xml based MEF catalog I am prototyping. I came across the need to invoke a set of methods on an IEnumerable<T> that was returned from a LINQ to XML query. Unfortunately no such animal exists on IEnumerable.

It took me < 5 mins to write this

   1: public static class IEnumerableUtils

   2: {

   3:       public static void ForEach<T>(this IEnumerable<T> collection, Action<T> action)

   4:       {

   5:         foreach(T item in collection)

   6:           action(item);

   7:       }

   8: }

Any questions?

Prism, MEF and DI oh my

Glenn Block — Tue, 19 Aug 2008 06:43:53 GMT

A few weeks ago I had a chance to chance to chat with the gang over at Herding Code on all of the above. I was in a particularly talkative mood after coming from a full day of presenting at Tech-Ready, so I'll warn you that there might be some rambling. As a result the podcast was split into two parts. In the first part we discuss Prism and DI in general. In the second part we delve into the specifics of MEF, and whether or not it is the one true DI container to unite them all ;) The best part is at the end when I get to turn the tables and put them in the hot seat :)

I had a great time hanging out with those guys, well virtually at least. I really like the open round table style format of the podcast. Check it out below.

Episode 11: Glenn Block on Prism, Unity, and MEF (part 1)

Episode 12: Glenn Block on Prism, Unity, and MEF (part 2)

Composite Application Guidance Talk at Tech-Ed

Glenn Block — Fri, 08 Aug 2008 22:09:00 GMT

Several months ago, Brian Noyes and I delivered a talk on Composite App Guidance AKA Prism at Tech-Ed USA. In the talk we discuss the essentials of Prism and do a bunch of demonstrations (well Brian did) of how to use it's various components. The talk went really well and the feedback we got was people really like what they were seeing. Brian also rocked the stage with his demo magic. If you attended Tech-Ed you can see it live on the Tech-Ed Virtual DVD site by following these simple (and convoluted) steps. You will need to install the latest version of Silverlight to see the video.

Click this link
Log in using your conference site credentials
Click the Tech-Ed Online DVD - Dev link on the left
Click View Sessions along the top
Enter win306 in the keywords

If you are not able to log-in, then you can download the slides from the talk below.

http://cid-92d0758f33773822.skydrive.live.com/self.aspx/Tech-Ed/Composite%20Application%20Guidance.pptx

Me + MEF = A new beginning

Glenn Block — Wed, 16 Jul 2008 17:44:00 GMT

About three months ago, we were on the heels of shipping Prism (Composite Application Guidance). At that time, I went to Don Smith my then manager ecstatically and said "Man I just love being in p&p, this is amazing". What I meant is that I love the work we are doing, I love the way we listen to customers, I love our ability to shift our direction based on what we are hearing and I love the environment we operate in to make it happen. Prism was a prime example of that in that we changed a lot of the way we do things, and incorporated a lot of new concepts that were resonating with the community. In many ways we got back to basics. When I made that statement to Don, I imagined I'd be in p&p for years to come.

Lo and behold about two weeks after that conversation, I get an email from Brad Abrams saying we should have lunch and chat about the work going in the MEF team, and how it might be a good place for me. Initially I thought to myself, no way. It had nothing to do with MEF, but there was absolutely NO reason for me to leave, and on top of that I had a fantastic year in p&p. However, because it was Brad asking, I said I need to at least go and hear what this is about. Over the past 18 months, I had worked with Brad on many occasions and have deep respect for him.

Lunch changed everything :) As Brad described MEF, it became very clear to me that the challenges MEF is solving in many was is a framework answer to problems we've addressing in p&p. Here was an opportunity to take those experiences and the work with the community, and bring it to the platform. Coming to MEF raised several concerns. Can I continue being who I am? Can I continue pushing to try new approaches? Can I keep engaging with the community including our friends from the OSS community? Can I keep being open? Oh and can I keep being Test-Driven?

The answers Brad gave were all YES except to the test-driven part, at least not yet :) Basically he said keep doing what your doing, only do it as a member of the .NET Framework team......Too good to resist. At that moment I decided YES this is right. My wife on the other hand though I was completely nuts. She said, "You are so happy, why leave". I said "honey, you don't understand...THIS IS THE FRAMEWORK! THIS IS SCOTT GU's org." I tried to also explain to her the significance of working with luminaries like Krzysztof, Brad and Blake. Her response "Whatever, I hope you know what you are doing"

So after several informal chats with the team, followed by an interview loop, here I am as a new PM on the MEF team, and have been for the last two weeks. Originally I wasn't planning to post yet, however yesterday I saw Hammett let the cat out of the bag about his joining us, so I thought I shouldn't wait :)

It's been a great start. This is a space I know pretty well and it is a terrific team. Because of both, the ramp up has been smooth. I've been pushing on several areas since joining. One of which is how to get more visibility in what we are doing with the community. I am happy to say that as a team we've agreed to push our source to CodePlex and join our friends over in MVC land. We've got buy in on the team, now we just need to clear it with the lawyers :-) Regardless, you'll here much more in the near feature on the work we were doing and how you can help us.

As to p&p there will always be a place in my heart. I really have had an amazing experience working with folks there. Forgetting the amazing projects we worked on, it's the people. I can't name all, so I won't name any. All I can say that it's been a great wild ride :) They haven't seen the last of me, the very fact that I am working on MEF means we'll be traveling together for a long time :)

Composite Application Guidance is Live

Glenn Block — Thu, 03 Jul 2008 06:19:00 GMT

Before I go any further, we shipped! :-)

Links:

What's in the box

Here's an overview of what you'll find

At the core is the Stock Trader Reference Implementation.

This app is a composite application built in WPF. In it you'll find design patterns, concepts and techniques you can add to your arsenal.

Supporting the RI, you'll find a library which aids in implementing the patterns. The library is light, really light and that's deliberate. We harvested it out of the RI rather than building it first and throwing an app on top. We built it to work with your existing infrastructure rather than you having to build from scratch on top of it. We built it to work 100% with WPF rather than retrofitting WinForm concepts into a WPF world.

Around the RI, you'll find comprehensive documentation (see the diagram above) in which you'll see the major design concepts and patterns are for building composites such as the RI. You can use this knowledge to build your own implementations if you decide that ours is not right for you. You'll also learn how we've decided to implement those patterns and concepts and why. You'll see how to use the pieces separately, or put them together in a coherent fashion to form the baseline architecture you see below.

Finally you'll find a set of quickstarts and how-tos to help you get ramped up on the concepts.

A little history

If you'd have asked me 12 months ago, I would have said this day would have never come. Around that time we had just announced that we had no further plans to do anything in the CAB space. Instead our goal was to lead everyone toward a mythical creature called Acropolis. With Acropolis on the way it didn't make sense for us to continue. Then by some strange twist of fate, Acropolis was folded into future versions of the framework. This opened the door for us to address building Composite applications for WPF. Once we had the green light to go ahead, we had a tough decision to make, take CAB forward to WPF or start over. We chose to start over. 8 months later, we've incorporated tons of community feedback, built a new set of guidance specifically for building Composite applications in WPF. As it goes out the door, we're very happy we stuck to our guns on that decision.

The Team

We couldn't have done it alone. In addition to a fantastic, and extremely focused team including Brian Noyes from IDesign, Adam Calderon from Interknowlogy, Southworks and Infosys we had a large set of advisors. Across Microsoft, we had help from several product teams including WPF (Henry Hahn,Ivo Manlov,John Gossman,Mike Hillberg,Rob Relyea), UIFX (Brad Abrams and David Hill), DPE (Jaime Rodriguez, Karsten Junszewski, Jared Bienz, Mark Feinholz), and App Dev Consulting's Josh Twist. Combine this with an amazing committed group of partners (Infragistics), industry experts and advisors including David Platt,Jeremy Miller, Ohad Israeli,Oren Eini, Rob Eisenberg, Szymon Kobalczyk,Udi Dahan, and Ward Bell. This is just a sampling, the full list is below

Bil Simser, Brad Abrams (Microsoft Corporation), Chad Myers, David S Platt (Rolling Thunder Computing, Inc.), Derek Greer, Ian Ellison-Taylor (Microsoft Corporation), Ivo Manolov (Microsoft Corporation), Jamie Rodriguez (Microsoft Corporation), Jeremy D. Miller (Dovetail Software), Josh Twist (Microsoft Corporation), Matt Smith (AltiMotion Corporation), Mark Tucker (JDA Software Group, Inc.), Michael D. Brown (Software Engineering Professionals, Inc.), Michael Kenyon (IHS, Inc.), Michael Sparks (RDA Corp), Ohad Israeli (Hewlett-Packard), Oren Eini (aka Ayende Rahien), Peter Lindes (The Church of Jesus Christ of Latter-day Saints), Rob Eisenberg (Blue Spire Consulting, Inc.), Shanku Niyogi (Microsoft Corporation), Scott Bellware, Szymon Kobalczyk (InterKnowlogy), Udi Dahan (The Software Simplist), Varghese John (UBS), Ward Bell (IdeaBlade)

Final thoughts

For me, this has been an incredible journey. I've had the pleasure of working with the most talented individuals inside and outside of Microsoft than I have to date. It just doesn't get any better than this! Thank you to everyone who has made this possible!

As Soma likes to say Namaste!

Composite Application Guidance - What is it?

Glenn Block — Wed, 02 Jul 2008 00:22:15 GMT

In the development of the Composite Application Guidance one area that we have labored intensely was around documentation. Documentation was so high on our priority list, that we deliberately reduced the number of bells and whistles in order to allow us to properly document what we had. As part of this we put in a significant effort to provide overview level information. We heard a lot of feedback from customers on the need for us to provide much more of the "Why" rather than the "What". Our hope when you see the documentation is that you feel we have provided enough background to understand what the guidance is and what problems it is solving. We equally want you to understand why we did what we did, how it benefits you, and when you should consider discarding out particular implementation.

Below is our overview topic on the guidance pulled straight from out docs. (Forgive the crappy formatting, I tried :) )

The goal of this topic is to provide you with a high-level overview of the Microsoft patterns & practices Composite Application Guidance for WPF (Windows Presentation Foundation) and the development challenges it addresses.

This topic describes some of the problems you might encounter when building complex WPF client applications, how the Composite Application Guidance helps you to address those problems, and how the Composite Application Guidance compares to alternative approaches.

Application Development Challenges

Typically, developers of client applications face a number of challenges. Most enterprise applications are sufficiently complex that they require more than one developer, maybe even a large team of developers that includes user interface (UI) designers and localizers in addition to developers. It can be a significant challenge to decide how to design the application so that multiple developers or sub-teams can work effectively on different pieces of the application independently, yet ensuring that the pieces come together seamlessly when integrated into the application.

In addition, application requirements can change over time. New business opportunities and challenges may present themselves, new technologies may become available, or even ongoing customer feedback during the development cycle may significantly affect the requirements of the application. Therefore, it is important to build the application so that it is flexible and can be easily modified or extended over time. Designing for maintainability can be hard to accomplish. It requires an architecture that allows individual parts of the application to be independently developed and tested and that can be modified or updated later, in isolation, without affecting the rest of the application.

Designing and building applications in a monolithic style can lead to an application that is very difficult and inefficient to maintain. In this case, "monolithic" refers to an application in which the components are very tightly coupled and there is no clear separation between them. Typically, applications designed and built this way suffer from a number of problems that make the developer's life hard. It is difficult to add new features to the system or replace existing features, it is difficult to resolve bugs without breaking other portions of the system, and it is difficult to test and deploy. Also, it impacts the ability of developers and designers to work efficiently together.

The Composite Approach

An effective remedy for these challenges is to partition the application into a number of discrete, loosely coupled, semi-independent components that can then be easily integrated together into an application "shell" to form a coherent solution. Applications designed and built this way are named composite applications.

Composite applications provide many benefits, including the following:

· They allow modules to be individually developed, tested, and deployed by different individuals or sub-teams, allows them to be modified or extended with new functionality more easily, thereby allowing the application to be more easily extended and maintained.

· They provide a common shell composed of UI components contributed from various modules that interact in a loosely coupled fashion. This reduces the contention that arises from multiple developers adding new functionality to the UI, and it promotes a common look and feel.

· They promote re-use and a clean separation of concerns between the application's horizontal capabilities, such as logging and authentication, and the vertical capabilities, such as business functionality that is specific to your application.

· They help maintain a separation of roles by allowing different individuals or sub-teams to focus on a specific task or piece of functionality according to their focus or expertise. In particular, it provides a cleaner separation between the user interface and the business logic of the application—this means the UI designer can focus on creating a richer user experience.

Composite applications are highly suited to a range of client application scenarios. For example, a composite application is ideal for creating a rich end-user experience over a number of disparate back-end systems. Figure 1 shows an example of this type of a composite application.

Figure 1

Composite application with multiple back-end systems

In this type of application, the user can be presented with a rich and flexible user experience that provides a task-oriented focus over functionality that spans multiple back-end systems, services, and data stores, where each is represented by one or more dedicated modules. The clean separation between the application logic and the user interface allows the application to provide a consistent and differentiated look and feel across all constituent modules.

Additionally, a composite application can be useful when there are independently evolving components in the UI that heavily integrate with each other and that are often maintained by separate teams. Figure 2 shows a screen shot of this type of application. Each of the areas highlighted represent independent components that are composed into the UI.

Figure 2

Stock Trader Reference Implementation composite application

In this case, the composite allows the application's user interface to be dynamic composed. This delivers a flexible user experience. For example, it can allow new functionality to be dynamically added to the application at run time, which enables rich end-user customization and extensibility.

Architectural Goals and Principles

The following table shows the architectural principles that have been prioritized by the Composite Application Guidance team's customer advisory board. These principles determine how guidance is developed and what the focus areas are.

Quality	Definition
Subsetability	This is the ability to adopt a portion of the Composite Application Library. You can choose only certain capabilities, incrementally adopt capabilities, and enable or disable features.
Learnability	This is the ability to quickly learn how to build WPF composite applications using the Composite Application Library. With small digestible and independent capabilities, you get started faster.
Extensibility	This is the ability to enhance, extend, or replace pieces of the framework without requiring you to redesign the framework or your application.
Compatibility	This means you can adopt the Composite Application Library for an existing application and you can use it with other existing infrastructure. Core services are swappable.
Simplicity	This means the Composite Application Library is designed in a minimalist way to reduce the amount of complexity. The Composite Application Library has just enough simplicity to get the job done.
Testability	The reference implementation in the Composite Application Guidance provides an implementation for Separated Presentation patterns. These patterns allow UI logic to be tested.
Performance	The Composite Application Library minimizes overhead while the application is running.
Scalability	The application can scale to support increased load.
Upgradeability	Existing WPF applications can be upgraded to use the Composite Application Library.

Adoption Experience

The Composite Application Guidance has an explicit goal to provide a good adoption experience. To deliver on this goal, the Composite Application Guidance provides the following:

· You can "opt in" and "opt out" of the Composite Application Library capabilities. For example, you can consume the only services you need.

· You can incrementally add the Composite Application Library capabilities to your existing WPF applications.

· It is non-invasive because of the following:

◦ It limits the Composite Application Library footprint in the code.

◦ It limits reliance on custom Composite Application Library attributes. You can integrate existing libraries with the Composite Application Library through a design that favors composition over inheritance (this avoids forcing you to inherit from the classes in the Composite Application Library).

Concerns Not Addressed by the Composite Application Guidance

Please note that the Composite Application Guidance does not directly address the following:

· Occasional connectivity

· Messaging infrastructure, including the following:

◦ Client/server communication

◦ Asynchronous communication

◦ Encryption

· Application performance

· Authentication and authorization

· Handling thread-safety from background updates, including the following:

◦ Data races

◦ Data synchronization

◦ Handling UI updates from multiple threads (the Composite Application Library addresses some aspects of this)

· Versioning

· Error handling and fault tolerance

For more information about these topics, see the following resources:

· Smart Client Architecture and Design Guide

· Occasionally Connected Systems Architecture: The Client

· Occasionally Connected Systems Architecture: Concurrency

Considerations for Choosing the Composite Application Guidance

The Composite Application Guidance is for designing complex WPF applications. The scenarios where you should consider using the Composite Application Guidance include the following:

· You are building a composite application that presents information from multiple sources through an integrated user interface.

· You are developing, testing, and deploying modules independently of the other modules.

· Your application is being developed by multiple collaborating teams.

If your applications do not require one or more of these scenarios, the Composite Application Guidance may not be right for you. The Composite Application Guidance requires you to have hands-on experience with WPF. If you need general information about WPF, see the following sources:

· Windows Presentation Foundation on MSDN

· Sells, Chris and Ian Griffiths. Programming WPF: Building Windows UI with Windows Presentation Foundation. Second Edition. O’Reilly Media, Inc., 2007.

· Nathan, Adam. Windows Presentation Foundation Unleashed. Indianapolis, IN: Sams Publishing, 2006.