edjez's WebLog

Something new, something different, and I am moving my blog - http://edjez.instedd.org

2008-03-07T03:50:00Z

This is a strange post in many ways. First, I didn't post for a looong time at p&p. Second, I moved on and went to a group where it was too early to blog about what we were dong. And third, now I'm not even a Microsoft employee.

My new blog address is http://edjez.instedd.org.

I left patterns & practices in 2007. After having started its .NET efforts, started and grew the "bluebricks" program that allowed us to ship all the 'guidance' (what a fluffy word!) as source code you could take into production, which eventually evolved into the Application Blocks, EntLib, GAT/GAX, Software Factories, etc... Of course it went many iterations in the very able hands of the amazing people that are at, or passed through, patterns & practices. The people that worked at p&p and the user communities with which we built close ties are the fondest memories of that time.

When I left p&p I went to an internal group near Ray Ozzie, doing prototyping and putting together approaches for 'innovation' at Microsoft. You won't see much about it yet but I hope they eventually get an external identity, because it was the coolest thing to hit Microsoft in my almost 9 years there. There's just random tidbits leaked over the web, and I couldn't blog at all about what was going on, but even like that it was worth it. It was a dynamic and energetic team led by people who know what they are doing but also crazy enough to break the molds that don't work.

But there was something constantly tugging at my heartstrings and I left Microsoft on October 2007 to join a technology non-profit called InSTEDD. We do advanced technologies for disaster response and global health. Using and doing Open Source. From SMS-based applications for data sharing to visualization and data mining. Although I had a great time at Microsoft, i am having a blast every day working with Google, Facebook, Linux, SalesForce.com, Sun, (...and Microsoft) taking technology as the means, not the end - and it is fulfilling to be working directly with communities where technology holds so much potential.

And you know what? It's challenging all my assumptions of architecture, design, and the economics of software development and use. In a way, I feel like I've jumped some years into the future, and now I am living every day what I felt a glimpse of some years ago (see my 2006 blog post - Forerunners of tomorrow's enterprise architectures ). There's a lot of patterns to be mined here. I hope I do a good job of communicating them.

InSTEDD is inherently cross-platform, but for some fluke reason we have a lot of .NET stuff going on right now, so you might want to check it out (http://www.instedd.org). Of course, we'll make the right chunks run on Mono.

My new blog : http://edjez.instedd.org. This is my last post here.

My new 'customers' live very different lives, but I think there is something to be learnt from every one. To Microsoft and patterns & practices chaps - thanks. Please forward folks to my new blog if you think there's value.

To all customers I've ever worked with - I hope what I've done has been of good use - and it's been a privilege working with you. And if you have a Corporate Social Responsibility angle or have an aching need to donate to what probably is the only humanitarian NGO doing TDD on the planet, you know where to find me.

Policy Injection App Block - Behind the Scenes

2007-02-23T20:53:00Z

Tom and I are making a set of simultaneous posts about a recent addition to the EntLib 3.0 family of Application Blocks - the Policy Injection Application Block (PIAB). His post is an introduction and high-level description, but in this one I wanted to get a little bit behind the scenes and expose the 'why' behind its existence and design.

This post will make little sense as a first introduction, so

1. Go read Tom's post for a quick overview

2. Read this post for a behind-the-scenes look at this new block

Our work is still a Community Technology Preview (CTP) and we are looking for feedback! So please don't be shy.

What's the goal?

At patterns & practices we realize that a huge part of helping make enterprise applications easier to build is having good separation of concerns (SoC). Separation of concerns is about allowing the right people work in the right areas at the right time. This also allows different parts of your systems evolve at different paces.

In other words, a system that has bad separation of concerns makes it hard for people with same or different responsibilities to work in parallel, makes it hard to maintain a body of code without affecting other pieces of code, and forces decisions to be made at times that may not be the best for the team building the solution.

There are many ways to help separate concerns - via tools, platforms, methodologies, programming languages, etc. Our observation is that when the platform supports some level of separation of concerns, it is simpler for the tools and methodologies to follow suit.

Essentially the PIAB allows you to specify code that will run before and after members of your components in your application, as specified in a model, with no real code change requirements in your apps. It implements the common Composition Filters pattern.

The scenarios where this can help range from common ones - such as exception shielding, adding perfmon counters around method calls and other types of instrumentation, security checks - to quite interesting ones - versioning, multiple dispatch, parameter validation, interception for test stub assertions, and so on.

This sounds familiar...

People familiar with Aspect Oriented Programming (AOP), Aspect Oriented Software Development (AOSD) and Composition Filters (CF) should be familiar with this concept, and should resonate with many of the concepts in the PIAB. Over the years I have been personally involved in many discussions about SoC within Microsoft, including an AOSD summit we held last year. For many years I have been collecting a list of challenges customers solve with these approaches, and I can tell you it goes beyond 'instrumentation' which tends to be the first use people imagine.

I also hear many people express that this approach only applies to, and should maybe be constrained to, 'hard' boundaries in the application, such as service boundaries. The issue here is, these boundaries are quite subjective - they could be layers in an application that are not physically distributed, or they could defined by runtime usage -e.g. within a WorkItem or Module in CAB.

For example, WCF has Behaviors for adding functionality at service boundaries, and p&p has been providing blocks and examples on how to use these, if they fulfill your need. With the approach of the PIAB you can apply policies at boundaries that make sense in your design, or apply policies regardless of whether they fall on a conceptual 'boundary' or not.

So I want this to be an in-depth tour of the PIAB exposing some key design decisions, and what drove them.

What's the overall design?

The design of the PIAB can be described quite succinctly.

Imagine we have a target object with a member that we want to add some behaviors/policies to.

We use an interception mechanism to get in the way of calls going to that member, collect a list of policies that apply using a matching rules mechanism, run the chain of handlers specified by those policies in a chain of responsibility and at the other end dispatch the call to the target. Once the target is done - successfully or with exceptions - the stack unwinds, returning through each handler and finally back to the caller.

A policy is a set of handlers in a specific order, and a set of matching rules that specify to what targets it should apply.

Let's drill down into the specifics.

What is the interception mechanism and why?

First of all let me tell you that I am all for having better transparent interception in .NET as a platform. As the CLR and our languages continue to evolve, I expect this to become easier. However as of now the situation is pretty much a pick your poison scenario. Each option forces nontrivial tradeoffs. So here is one of our design choices:

All the infrastructure to gather and run policies is independent of the interception choice. We just provide a default.

That is, while we chose a default, you can use other interception/'weaving' mechanisms and re-use the rest of the design. Or we might ship others after the fact, if there is demand.

We chose remoting proxies as our default, and you will see that in the CTP.

Choosing a default was a hard thing. Here are some of the alternatives we evaluated.

Remoting proxies : Using Real/TransparentProxy

Requires construction with a special factory
Requires class to derive from MBRO, or to have an explicit interface.
Proxy is treated as the real type by the type system (.NET special cases type identity checks around these objects)

Context Bound Objects : Using ContextBoundObject and attributes

Allows interception of ‘new’
Not recommended for customer code - therefore p&p won't ship it as part of guidance!

Assembly rewriting : Taking the IL of your assembly and injecting more IL into your classes

Eliminates the need for proxy classes
Completely compatible with the type system and ‘new’
Can’t be used for external strong-named assemblies without delay-signing (pros and cons)
Not supportable by Microsoft Product Support (PSS) as of today--> ouch

Generating derived classes : Taking your classes and generating wrapping classes that derive from them

Requires construction with a special factory
Only works for virtual methods on non-sealed classes
Could result in type system issues

Generating inline interception code : Taking your classes and adding C#/VB code 'around' method bodies

Requires code to be written in a special way
Interception code is explicit, rather than “magic” (which has pros and cons)
Requires source code for intercepted objects

Other more obscure mechanisms we discarded : Things that work but we wouldn't like to ship and you wouldn't like to maintain

Using CLR profiler APIs
Using CLR JIT Debugger callbacks for runtime IL rewriting

Of course we aren't the first ones to go through these decisions. But being p&p we have to be careful and explicit about our choices as they are Microsoft's recommendation on how to tackle the problem for enterprise production environments, and we get a very broad usage. This doesn't mean other options are wrong or disrecommended, just that our tradeoffs may be driven by different forces.

The approach requires the use of a factory instead of just new for objects that have policy, which can be frustrating. If you are using our Software Factories or specifically Composite UI (CAB), Composite Web UI (CWAB) or a future Web Service Software Factory v3 preview, you are probably already using Object Builder under the hood for dependency injection, and we will provide an Object Builder strategy to make the addition of this PIAB functionality transparent to the rest of the app.

We will be running perf tests against our Reference Implementations and other real-world apps and getting impact numbers, to share performance data with you. Needless to say, using Hello World as a test scenario with this interception choice yields predictably terrible perf results. Then again , Hello World doesn't need separation of concerns; and the PIAB will not wrap classes if they don't have policy that should apply to them.

Again, you could take any other mechanism of your choice (e.g. assembly rewriting) and use the rest of the infrastructure as is.

Let's move on to the next important design element

How do you specify which policies apply to what targets?

Which policies apply to which target members is informed by a set of 'matching rules', which can be set up at runtime programmatically, or from XML config (with tool support), or from attributes (not in this CTP).

A matching rule is essentially a predicate that answers the question - does a policy apply to this member? A namespace matching rule allows you to say something like 'apply this policy if: the namespace of the class containing this method starts with MyCompany.MyApp.BusinessOperations'. You can add matching rules which get ANDed.

Why these matching rules and not just an xml schema that says these members of these types, or something like it?

The matching rules allow you to define what applies where in an expressive way, for simple or complex criteria - avoiding a one-size-fits-all model that is hard to learn for simplest cases a hard to scale to complex cases.

One of our challenges was getting a level of expressiveness in "what applies where" for cases that were application architecture specific - e.g. "All classes that are Services in CAB" or specific to usage patterns - e.g. "all classes that are presenters in view-presenter pairs". We collected a list of common criteria and two things became clear: One, our xml schema for matching rules was growing beyond what we wanted and two, by looking down our product roadmap, we were confident we didn't have all the types of criteria we wanted.

So, by having this matching rules design, each matching rule can have its own schema that is expressive and makes sense for the context. We are providing matching rules implementations for common criteria out-of-the-box, such as matching namespaces, base classes, method signatures etc. You can create matching rules that use your own XML schemas, custom languages (like those used for pointcuts by some AOP frameworks) and DSLs if you fancy. All you need to do is implement IMatchingRule.

We also have a Tag attribute and matching rule that allows you to define your own semantics of members. For example, "Apply Audit policy to every method marked as 'Critical'" is as simple as defining the Audit policy with a logging handler, and using the Tag("Critical") or your own 'Critical' attribute type on the appropriate methods:

[Tag("Critical")]
public void DoSomethingImportant()
{ }

I am not personally a fan of matching based on string comparisons of class and method names, but there is a matching rule for that too.

What are policies, handlers and what can they do?

A policy is a set of handlers in a specific order, and a set of matching rules that specify to what targets it should apply.

For example you can define an "Exception Shielding" policy, with an Exception Handler and a Validation Handler. You can then define matching rules that say that "Exception Shielding" applies to "all methods of classes in the data layer"

One of the challenges in these Composition Filters (CF) or Chain of Responsibility (CoR) style of designs that can have multiple handlers, is how do you know which is the effective order of all the handlers around an object? E.g. obviously, returning cached responses before authorization is not the same as authorizing before checking the cache....

We looked at how customers dealt with this, and in many cases this ended up not being a real problem as they were willing to explicitly, manually, set the order of the handlers to make sense for the outcome. This means there is no automagic sequencing/sorting of handlers, and you define their sequence inside the policy definition in the config tool. Also, policies are ordered themselves, so if more than one policy applies to a target then you can predict the order of handlers.

A handler is the actual object that sits in the call chain before the method gets invoked. These are some interesting characteristics about handlers:

Handlers are executed as a chain of responsibility. This means that handlers will be on the stack by the time the target gets called. This also means handlers can decide if and when to call the next handler. For example, a validation handler may decide to return an exception without continuing the call chain. Handlers also can do work on the way in to the target, or on the way out, or both.
Handlers get access to the call member info, parameter infos, actual argument values, and out/return values. This means you can inspect, log and even change incoming/outgoing arguments as needed
Handlers can get access to exceptions, to log them, etc as appropriate.
Handlers have access to the target object, so they can check its state, or even do operations on it as needed.
Handlers can keep/share information in a loosely coupled way via a dictionary which is associated with the call. This is important as there is only one instance of configured handler per policy per appdomain. We set up the chain of responsibility behavior using delegates, so instead of keeping a pointer to the 'next' handler, handlers get a delegate reference to the Execute of the next handler, allowing us to reuse the handlers in more scenarios.The shared dictionary allows you to keep track of data not part of the call - e.g. the start time of the call; to compute total execution time on the way back.

As you see, we had a design principle, that

Handlers are powerful and can inspect and manipulate the call deeply. We won't try to protect handler authors from making mistakes by removing usefulness

What can I do with this out of the box?

We are planning to include some handlers to add utility out of the box: Validation, Logging, Exception Handling, Performance Counters, Authorization, and Caching. We also plan to have some common matching rules.

Common Questions

This is all very scary. I can't know what will happen by looking at the code! YES - That is the whole point of separating the concerns!. If you want to have hints about what will happen in your code, you can use the tagging attributes to remind you that certain things will happen - but how they happen is up to policy.

How will this impact my debugging? Hopefully the existence of policies can assist your support and troubleshooting by providing information to help you isolate problems. Once you are debugging the code, as of now you will see extra goop. We haven't looked into providing VS tools to help abstract this out, but it is possible to build compelling tools that make you aware of the extra handlers without forcing you to step around foreign code.

Do I have to use factory methods to create my objects? Yes, with the interception mechanism we provide. You can avoid this requirement if you do the extra work of implementing another mechanism. If you do, please share back into the community!

Why don't you call this AOP? If you know about AOP, you can see where it is similar and where it differs from AOP solutions out there. The handlers fulfill the role of 'advice', the matching rules replace 'pointcut languages', and the 'weaving' is black-box based on interception. However the reality is most of our customers have not heard of AOP or AOSD. Please put yourself in their shoes for a second. We wanted a name that was reflective of the use and benefit the block brings, rather than using an unfamiliar term that only the exceptions understand. We also wanted to have no implicit expectations on the design that may be inherited from AO solutions. However, if you think this is a dumb move, please holler on our CodePlex community.

OK, If I use this now what is the road moving forward, how will other pieces of the .NET platform/language support this scenario? This is where I remind you that p&p is not the CLR team, and there is nothing specific announced to date targeting this scenario as part of the .NET platform. One could imagine using C# partial methods for some cases where you need to call out to PIAB handlers in-line, and maybe simplify code-generation of wrapper classes. Dynamic languages provide some runtime manipulation of members, e.g. replacing a member implementation with a wrapping member implementation, or augmenting the implementation with the code that today resides in the handlers. All these just would be enabling technologies to simplify creation of PIAB like infrastructure pieces.

I am using an AOP solution today. Do I care about this? Great! You might find in the provided handlers some useful sample code that can help you plug EntLib blocks into your own infrastructure. Keep using what you have if you are happy with it! Also, if you have built infrastructure pieces yourself for similar purposes, check our EULA and if all is well feel free to reuse pieces, or feel free to post handlers you may have built adapted for the PIAB, or other code, in Codeplex.

Wrapping up...

We hope you will find this to be a useful addition to your toolkit. Sorry for not announcing this earlier, but we did start development 3 weeks ago and we weren't sure this would make it in until this week.

Thanks a lot to Christa Schwanninger (Siemens Corporate Technology) for her feedback and refinements to this blog post.

Software Factories: report from the trenches, and thoughts from p&p

2007-02-02T06:56:00Z

Daniel wrote a nice little post about status of building Software Factories today - using DSLs to express intent around common models and Guidance Automation Extensions (GAX) to automate common use cases. See his perspective here

As the team who has shipped most of the Software Factories from Microsoft, patterns & practices continuously tries to help you build better applications using less effort by applying these technologies. Once the rubber meets the road, we all learn, and we build infrastructure to support better experiences today and at the same time provide feedback to the VS.NET folks building next versions, so they can add features that will make p&p's and your lives easier down the road. Entlib Config and GAT/GAX was an example of such infrastructure.

But where is it going? We think there are many opportunities in the following areas:

1. Integration of multiple models - obviously you can express parts of your application with models, but the moment you start adding different domains - especially crosscutting ones, think authorization; or models at different levels of abstraction- you obvioulsy require to have dependencies, relationships and interoperability/integration of models. A good infrastructure for model integration would allow you to yuxtapose concepts around workflow, and manageability events, for example, without having any unecessary dependencies that wouldn't allow you to use that same manageability model around a totally different concept like web service calls or business data state transitions.

2. Bringing in the team to the factory - Right now the factory experience is a lonely one - you build a thing, move on. Artifacts like models and code survive, but beyond this sharing there is no coordination to the collaboration. Just like GAX can be used to automate 'atomic' use cases that are done by one dude/dudette sitting at Visual Studio, we think that something akin to small team workflows can be used to express outcome-centric activities that coordinate many smaller actions. These are not end-to-end processes, rather small pieces of activities that can't be done all at once - like setting up an environment for mobile app testing, or building/reviewing/checklisting against a threats & countermeasures model.

3. Specializing aspects of the software engineering process - we have ways of expressing with VSTS the process (workitem templates, content, etc) that you use for building stuff. What happened if the process could be specialized in the right areas to help you build not just stuff but a special shape of stuff? Are there templates in requirements, bugs, development tasks etc that would be more valuable to you if they were specially built to help teams build (for example) web services?

Of course a key concern I hear is - wow, with all this stuff won't things just become heavier and more context-dependent to the point I won't be able to use anything just because I'm not living in your little world? - and I understand it. My hope is that we can work on our packaging (which isn't precisely a beauty right now!) so that you can take the parts that you need, yet at the same time have a great experience with the whole. And all of what I blogged about is just the work needed to give your team a guided experience when building solutions. Every team in p&p building a factory has to make a balance between distilling the proven-practice guidance itself, and expressing that guidance in runtime, tooling and content. I hope that, as we continue to roll out more of these, you out there in the community will keep us honest and help us make the right tradeoffs.

Web Client Software Factory Ships!!!

2007-01-13T03:20:00Z

We just released the Web Client Software Factory to Codeplex. Go get it.

I thoroughly enjoyed this project. The team rocked, we had to deal with new technologies and we did a large set of deliverables targeting web apps specifically, which I felt we were slightly behind on compared to other technical areas.

And we obsoleted UIP (finally) with the new PageFlow application block that uses Worflow Foundation by default to let you design flow-rich use cases. There's guidance for UIP users to simplify migration; including a re-do of the old UIP quickstart using the new page flow block (Michael Stuart- are you listening?)

And we have a first cut at composite web apps in the CWAB (Composite Web Application Block), putting in a container model (courtesy of Object Builder) that allows you to do dependency injection to acheive patterns like MVP and MVC, as well as simplify dealing with state and so on. It starts covering the scenarios of composing modules that make up a site - not composing across sites - and allows us to start building a foundation for future scenarios you require more guidance on.

And we have a full reference app that shows all this together.

And documentation explaining the essential design concepts and activities that come together building an app like it.

And visual studio extensions that simplify the job of creating apps imitating the design of the RI using all of the above.

There you go. Enjoy! Now we will listen to your feedback and observe usage patterns to see what opportunities we should tackle in the next release... which may come out sooner than you think. There's areas where we would like to push the ball forward and areas where we may need to cover gaps. Let us know.

http://www.codeplex.com/websf

Please note we shipped it because it was ready - not because we ran out of stickies for iteration planning... :)

I'm it!!

2007-01-05T09:01:00Z

OK - now I'm it - in this fascinating game of blog-tag via Tom Hollander.

I like this game - You need to reveal five things about me that most people don’t know, and tag 5 more folks. I'm going to add my own spin and add 5 pictures.

Here we go:

- I am from Argentina, with a Polish family and went to a Scottish school. I played the bagpipes. In a kilt. It is there that..

- ...I was able to see my first programs run about a year after I wrote them, once I had access to a computer - I had written them on paper. But now I use computers (sometimes) and

- ... I am a private pilot, and love flying around the US pacific northwest.

- ...but a lousy snowboarder, and broke my spine in the midst of entlib v1. I somehow used the infinitesimal chance I had of recovering well, so I’m fine. When I think things are bad, I wiggle my toes and the smile returns.

- I believe in spending time making this a better place and that individuals can change the world, which has led me to multiple engagements with environmental, education and humanitarian scenarios. That is a set of tough problems. I spend time on that when I can. For example, recently at Strong Angel III

Here are my 5 pictures -

So who is "it" now?

Daniel "Kzu" Cazzulino

You don't need to post pictures...that's just me

Have fun! Enjoy the Entlib 3 CTP and Upcoming Web Client Software Factory - with an full-new " Page flow" application block that replaces UIP for web apps and uses WF as the default workflow engine.

Web Client Software Factory on CodePlex!

2006-09-16T03:57:00Z

We have just released oour first community drop of the Web Client Software Factory. www.msdn.microsoft.com/webclientfactory

As we continue working on the project, we expect to provide:

Give best practices for web app development on .NET 2.0
Guidance around pageflow and eventually migration assistance from UIP to the new guidance
Some guidance on AJAX
Integration of the Security & Perf & Scale best practices

It is also one of the first projects we'll try to keep on CodePlex instead of GotDotNet, so please provide feedback on the site experience as well.

Enjoy!

Distributed, mesh-based source code control with SSE?

2006-09-09T02:55:00Z

We were discussing the Simple Sharing Extensions (SSE) usage at Strong Angel 3 in our team and Peter came up with an intriguing direction question: What if SSE was applied in source-code control? The mind reels...

2 new CAB (Composite UI) resources

2006-09-06T23:52:00Z

1. www.cabpedia.com - started by John Socha-Leialoha. John worked with us on the Mobile Client Software Factory and is currently doing some prototype work for a requirements gathering tool, and has set up this excellent community wiki so that folks can update and contribute content. The body of knowledge in there is already impressive!

2. An overview of CAB for those using it in the smart client software factory.... http://msdn.microsoft.com/library/en-us/dnpag2/html/SCSFOverviewOfCompositeUIAppBlock.asp

Forerunners of tomorrow's enterprise architectures

2006-08-27T05:28:00Z

Just returned from Strong Angel III - a week-long excercise and demonstration in the use of ICT (Information and Communication Technology) for humaitarian and first-response missions. I was there to learn many things, and one of the things I brought back are many requirements that systems must fulfill in order to work in complex, emotionally vexing environments. I beleive that the solutions that work in these constrained and dynamic situations have inside certain elements that are indicative of the enterprise needs of tomorrow...so I try to pay attention.

It ended being a mixture of 'jazz and lego blocks' as Nigel Snoad would say, with collaboration with the Microsoft team around SSE (Simple Sharing Extensions), building a model-driven dynamic forms generator for mobile apps for data collection built around an SSE distribution model, and writing glue code for demonstrations of interoperability with Google Earth and Sahana, an open-source web site.

Here are my key takeways that are relevant to this blog's audience. My first one is a vent on the utter complexity our user have to deal with when using most software being built today regardless of the platform it is built on.

My observation is - The tools, languages etc. we use to build enterprise applications are getting better - however we are using them to build quite disempowering systems. Essentially, we are getting better at building the same old stuff. I believe a quantuum leap is needed in applicationas architecture if we want to build systems that empower the users.

Here are some characteristics that I would expect from the next generation of applications:

- User-driven UI customization, integration and mashups. We took a small step with CAB and other composable architectures, but that accounts for a small percentage of what is needed. Imagine being able to take data flows, drive UIs out of them, tie them into worklows, on the same client app you use with no code.

- Interoperability over the use of standard protocols and to the maximum extent possible standard data schemas over the wire. Across platforms.

- Greater usability.

- No need to predict the data flow topology (as long as you can govern it and secure it). i.e. the same app can be configured to work in client-server, 3-tier, peer to peer, and other modes. The decentralization of state management and data flow could even be followed by a decentralization of manageability, and security features.

I expect to see some of the learnings incorporated into p&p deliverables over time. I'll see if where I can post my code about the forms and the SSE library so folks can use it. It is quite primitive but it is a start.

If you want to read more about Strong Angel III you can see news articles all over the web. Here is one good for techies: http://blogs.zdnet.com/BTL/?p=3545

Mobile Client Software Factory debuts @ MEDC

2006-05-11T03:03:00Z

This week most of the Mobile Client Software Factory dev team is at MEDC, in Las Vegas, presenting the cool stuff we've built over the last few months. (You guys should bee proud!)

It includes a loosely coupled collection of application blocks, some guidance packages, and documentation to help you build an end-to-end mobile application with guidance around some critical areas.

The guidance we've put together so far -since around January?- includes:

A Mobile version of CAB
A Connection Management app block to detect connection state, and a block to help you manage configuration for application endpoints for different networks
A mobile DAAB with a super-simple DB data access mapping helper
A Disconnected Service Agent Block + Guidance Package to help you build apps that work when disconnected and that roam networks; queuing requests; configuring web service proxies appropriately and all that
A SQL Server replication block that simplifies how you create and manage data replication to your device; if you choose to use this as a way of getting reference data into the app
An Orientation Aware control that allows you to design different layouts for different screen sizes and orientations and form factors (square, rectangular, etc) directly in the VS.NET designer
A Unit Test Runner that allows you to write tests for the full framework using VSTS tools but then runs them in the emulator without changing your test code
A Reference Implementation app that shows you a simple application using all these areas together illustrating good design patterns for your business logic

In the upcoming 2 months we plan to formalize the Reference Implementation design patterns into Guidance Packages; and depending on how well we do on velocity add a couple of more domains (self-updating mobile apps could be one such area, or Pin-based authentication and key storage). You can stay up to date by getting weekly drops from our community (which include code, docs and presentations about the topic).

We have a great team, and an awesome Expert Advisors board including people from large enterprises, ISVs, MVPs, and OpenNetCF. We will disclose the names of the advisors, as we get their permission :)

This has also been a great experiment for Microsoft in which a product team is building a Microsoft SKU in collaboration with p&p. (You can read about the precursor to this here) The collaboration is fun, as we learn how to integrate a p&p team doing XP on weekly iterations in the west coast of the US; with a Dynamics team doing monthly SCRUMs in Denmark. It's involved some travelling to keep things together but we have been doing great by attending each others iteration planning, having a shared team blog, and capturing tidbits of info in a shared wiki. The Dynamics team is building a specific Composite UI shell for Mobile apps, and a way to have model-driven orchestration of WorkItems as a way of allowing extensibility and customization of the apps they will build. Pretty darn cool!

Please go and join the community to see the p&p project; and let us know whether it will help you build your next mobile app!