Journey from RIA Services V1 to V1 SP1 Beta

Finally on the eve of PDC 2010, we get to share our latest bits with the community. Jeff has done a great job of covering the details of what's in so I won't repeat that here. Just check his latest post for that and also Tomek's posts that cover a broader vista of WCF technologies on tap for PDC. Instead, I will briefly cover how it shaped up.

Like many other V1s, WCF RIA Services V1 was done under intense time pressure and locked to Silverlight 4 Tools schedule. In hindsight too, that was the right thing to do as it allowed us to get a reasonably feature-full and capable package in users' hands. The response was very gratifying and on occasions, I was pleasantly surprised by what folks in the community were able to build with our bits. We as a team were also glad to see strong community involvement - when folks showed appreciation and when those in the know took us to task for missing capabilities or plain bugs or missing info (sadly most frequent of the three). There were many who spent so many of their hours advising us - Colin Blair, David Yack, Ben Hayat, Fredrik Normen, Dan Wahlin, Bill Burrows, Billy Hollis and many others outside Microsoft. Equally impressive were those who weren't directly on the product team but every bit a part of it with their contributions - John Papa, Pete Brown, Tim Heuer and many others.

SP1 is our attempt to give back to the community with a relatively quick turnaround - in about 5 months. Typically Service Packs (SP) are all about bug fixes and related quality improvements. This one is a bit more than that.

There were clear baseline capabilities that we wanted to cover in V1 but just couldn't. That was the price to pay for shipping - I guess well worth it. But we wanted to cover those soon. First came the bugs that had to be postponed because they didn't meet the high bar while locking down V1 RTW. So did a bunch of infrastructure and test improvements to make us more efficient and pay down debt. Then we were able to get to key items like "shared entities", complex types, ICollectionViewFactory and T4.

For this post, I will just briefly talk about shared entities - not being able to share the same entity type (say Employee) across two different DomainService types (say PurchaseOrderService and EmployeeInfoService) was a problem for those building apps with multiple DomainServices. Data models often have "spiders". The entity at the center of the spider is often involved in multiple submodels. The object model simply reflects that. Now you can do that without resorting to workarounds.

Doing that feature required some intense discussions about the approaches - each DomainService gets to "shape" the code-gen'ed entity in the client project. Do we take the intersection or the union? If one DomainService adds a named update method, how do you deal with the corresponding member on the entity in a different DomainService? What about associations that are different in the two DomainServices? After huddling with our "advisors" from the community, we settled on the union approach and the feature was on track. The usual design, implement, stabilize, meet all quality gates were done and we were close to PDC lockdown date.

Such was the journey. Maybe I will cover some bugs in the next installment. If you would like to see anything specific covered, please let me know about that as well.

Until then, please try the bits and keep the feedback flowing - on forums, blogs, twitter ...

First post since move

Here is the starter post to wave my flag. My previous blog entries were at
http://blogs.msdn.com/dinesh.kulkarni

Briefly, I have worked on LINQ / C# and WCF RIA Services.