Open RIA Services is a reality, it is moving time

Open RIA Services has been officially announced. I will be blogging at the new http://www.openriaservices.net website and I will leave this blog in place as a historical record. I wouldn't want to get people confused between blog posts about WCF RIA Services and Open RIA Services.


Apology to anyone who tried to contact me

I discovered today that this blog was not configured correctly. Anybody who tried to contact me using the Contact page of this blog had their email sent to an email account that I was not monitoring. I am very sorry if I missed your message.


Musings on WCF RIA Services #4: A Plan for the Future

I have been asked several times what the community can do to help get WCF RIA Services open source. After doing some research into how open source works, and reading articles like this one, it is clear that just asking Microsoft to open source something is not enough. We need to have to have a vision and a plan.

What I am going to layout here is my vision for what an open source WCF RIA Services project would look like. I have development split into three main branches which I have numbered as 4.2, 5.0, and 6.0. We are starting at 4.2 as the current closed source WCF RIA Services has a 4.1 version number.

WCF RIA Services 4.2

4.2 will be the initial open source release of WCF RIA Services. Here we will fix bugs, add M2M support, change a bunch of internal code to public, and other things which do not break backwards compatibility.

WCF RIA Services 5.0

The version 5 branch of WCF RIA Services will be where cross-platform work will happen. My position is that supporting the same API across all platforms is more important than maintaining the current Silverlight API as-is. Accordingly, there may be breaking changes within the Silverlight client and/or server parts of WCF RIA Services to create a consistent API. If you want to contribute breaking changes to WCF RIA Services then the 5 branch is where you will want to be.

WCF RIA Services 6.0

The 6 branch is targeted to be released along with Visual Studio v.Next and the Roslyn compiler. The focus of the 6 branch will be on integrating Roslyn into WCF RIA Services where it makes sense. For example, Roslyn will enable client side POCO object to be used as entities instead of the current code generated entities which inherit from Entity.

WCF RIA Services Experimental

This branch is where I am going to put things that may not end up in one of the main releases. There is a lot of wild things that could be done in WCF RIA Services and not all ideas may turn out to be good ones.

The Plan

So, that in a nutshell is my vision for WCF RIA Services. As you can see, each branch has a page linked where more information about each branch can be found. What you can do is provide additional ideas in the comments of this blog post. I will copy them into whatever branch page I think makes the most sense.

If/when WCF RIA Services is open source my main priority is going to be the 5.0 cross-platform branch of development. Merijn de Jonge , the developer of M2M4RIA on Codeplex, has already indicated that he would be willing to work on adding M2M support to the 4.2 branch and there a few things I want to get done in the 4.2 branch like change notification before I get too deep into the 5.0 branch.

I don't think development on the 6.0 branch will start until late 2013 after the 5.0 branch is completely stable and more features have been added to the 4.2 branch.


Musings on WCF RIA Services #3: What is it?

When this blog first started I named it "The Elephant and the Silverlight" which was referring to the old story, "The Blind Men and the Elephant", which was translated by John Godfrey Saxe. If you are not familiar with the story it is on the very first post of this blog. In the story multiple blind men examine an elephant by touch and each comes away with a different understanding of what an elephant is.

The story of WCF RIA Services is much like the story of the elephant. As I discussed in Musings #1, the original answer to the question is that WCF RIA Services was the DomainDataSource. The problem is that even before WCF RIA Services had been released to the public for the first time early users such as myself had already abandoned the DomainDataSource. Scott Barnes said recently in a comment to this blog that WCF RIA Services was created to solve a problem that didn't need to be solved. Perhaps that is what caused the blind men effect, since the official problem that was solved didn't need to be solved, WCF RIA Services became a solution in search of a problem.

Ok, so what problem did you need solved?

Back in mid-2008 I began the design process on a large scale Line of Business application written in Silverlight. The resulting application has an MDI layout that uses Telerik's Ribbon and Dock controls. It would be used to open hundreds of rows of data scattered over 70 different database tables, edit massive numbers of those rows, and then the user could either save all of the changes back to the database or cancel all changes at the click of a single button and partials saves must be prevented. Different users would have different security requirements so I needed to implement role based security. There were also large numbers of business rules that had to be enforced server side, however due to the complexity of the editing process the business rules also needed to be enforced client side in the UI so that the users would get instant feedback on business rules issues. So to recap, the problems I needed to solve are:

  1. Client side change tracking for entities
  2. Efficient loading of large numbers of entities both in row count and type of entity
  3. Business rules are needed both on the server and in the client
  4. I would really like to not have to write the business rules twice
  5. Role based security enforced on the server but also accessible client side.
  6. I want to use something LINQ based so that I can query for entities from the client.
  7. I am worried about allowing to much access to my database through those LINQ queries.
  8. I need strong support for Unit of Work.

I had been looking at using ADO.NET Data Services to supply the entities and the change tracking. However, Data Services (OData) transfers entities in an object oriented fashion where the resulting object graphs can change depending on how data was loaded. It also seemed to me that data services opened my database up for more querying then I was completely comfortable with. From a performance, usability, and security perspective, I was close to switching back to plain WCF services. That is when I saw a demonstration of WCF RIA Services (known as just Alexandria at the time) at that years PDC. I contacted the presenter to request early access to the code and I haven't looked back since. As I said above, my application didn't really have master detail screens so the DomainDataSource didn't really fit my needs. It was all of the other parts WCF RIA Services that made it exact library I needed for my application.

  1. It has robust client side change tracking for entities
  2. RIA Services uses foreign keys to connect objects intead of object relationships like Data Services. That means it has no problems dealing with large numbers of rows and large numbers of entity types. At least, not until you start getting into >10,000 rows in memory.
  3. With RIA Services, you write your business logic on the server side and it is then automatically copied into the client layer.
  4. ditto
  5. RIA Services enforces role based security on the server and provides an AuthorizationContext to push role based security into the client side as well.
  6. RIA Services supports LINQ queries...
  7. ...but it limits those queries to further filtering of the query exposed by the server.
  8. Unit of Work is a central design element of WCF RIA Services

Ok, so what is WCF RIA Services?

WCF RIA Services is a class library that supports the creation of an n-client, n-tier business logic layer. Two important aspects of WCF RIA Services is that it uses foreign-key based domain models and is designed around the Unit of Work pattern.


Musings on WCF RIA Services #2: The Backlog

The original User's Voice site for WCF RIA Services seems to be gone, luckily the Internet Archive Wayback machine has a copy. I thought it might be interesting to go through the list of the issues from the first page that have not been completed yet and see what I would do in my own fork of WCF RIA Services if it were open sourced.

 Support data change notifications from the server

I have a proof of concept design for a change notification system that uses SignalR. The DomainService needs a tweak to make it easier to get the primary keys of each entity on the server.

RIA Services support for Windows Phone 7 [Windows Phone 8, WPF, WinRT)

Windows Phone 8, WinRT, Mono (Droid and IOS), and WPF support are all a top priority and, I think, doable. However, I would not be porting the DomainDataSource as it is too specific to Silverlight.

Fluent-API based metadata (to replace buddy classes)

This is already an active project being spearheaded by Merijn.

EntityQuery<T>.Select() to project entities from the RIA Clients without creating DTOs at the server

This is very unlikely as it goes against the basic design and purpose of WCF RIA Services.

Support more of OData

In general, I think replacing the current WCF based DomainService with a WebAPI based "DomainController" would be a good direction to go in. However, WCF RIA Services is not WCF Data Services and attempts to make either one of them more like the other is misguided.

Ability to Include Navigation Properties Based on Many-to-Many relationships

The M2M4RIA project on CodePlex would be rolled into WCF RIA Services itself. I am not sure exactly what that would look like but I know Merijn is ready to handle it.

 A visual plugin for VS to manage domain services

This is very unlikely, I would be moving away from visual editors and towards direct code editing. If somebody else wants to tackly this then I would happily add it to my version.

Offline support in RIA Services

An open source WCF RIA Services would have a much improved version of RiaServicesContrib.EntityTools which does support complex types and composition. Those new hooks should allow the easy creation of rich offline capabilities.

MVVM support in project Template

 Targeted NuGet packages will probably be preferred over project templates going forward.

RIA Services support for AJAX (HTML clients)

I think HTML5 support will be important, figuring out what that means is the difficult part.

Propagate authorization/role metadata from server to client so that it can be used for building authorization-specific UI; e.g. admin sees additional named update methods that a user does not.

Honestly, I have no idea what that even means.

Paging support without requiring LINQ backend (e.g. sprocs)

This is a maybe. To some degree I feel that user defined table valued functions would accomplish the same goal without needing any changes made. I do have a few ideas here which I may try out, however it may wait until there is a user who is willing to be the guinea pig.

Transaction support from client

Same as paging support, I have some ideas here on how to package multiple SaveChanges calls from multiple DomainContexts into a single communication with the server but  no real proof of concept.

RIA Service support for ORMs besides EF

This request was about adding support for more ORMs to the DomainService wizard. Honestly, thinking long term, I am not sure if the DomainService wizard is going to keep working for EF.



Musings on WCF RIA Services #1: The DomainDataSource

Frame the problem for me 

Today I tweeted this:

WCF RIA Services was actually very mature, the DDS just always was and always will be a bad idea.

On further reflection, that statement is not correct. It isn't the DomainDataSource that was the problem, it was the perception of the DomainDataSource's importance that was the problem. To restate the issue:

Thinking of the DomainDataSource as the primary component of WCF RIA Services is a mistake.

For most of the demos and walkthoughs that originally showed off the capabilities of WCF RIA Services were about the DomainDataSource. The focus was on rapid application development and creating applications using very little actual code. If you are trying to show off how good Silverlight can be at creating LOB applications and you only have an hour to present it was a wonderful thing. The problem is that these demos tended to undersell what WCF RIA Services as a whole is capable of doing and oversell what the DomainDataSource is capable of.

What is the DomainDataSource?

The DomainDataSource is an on-screen component that supplies single-entity-type bindings for simple data viewing and editing scenarios. It is really good at supplying grid controls with data and for master-detail scenarios where a grid control is paired with a DataForm control. In short, it is really good at creating the same type of simple business applications that ASP.NET MVC is good at creating.

The DomainDataSource is not very good at multi-entity scenarios and should not be used for binding to the ItemsSource of controls within a DataForm (i.e. ComboBoxes). The DomainDataSource is also designed for safety above all else. For example, in a paging situation the DomainDataSource disables paging if there is any unsaved modifications within the DomainContext. This is to prevent modified data from being accidentally removed from the cache without being saved. For the basic, no-code type of application that the DomainDataSource was designed to support, such safety considerations are very important. Unfortunately, this means that the DomainDataSource is too inflexible to be used for more complicated, Line of Business type applications.

If the DomainDataSource was not useful for large scale LOB applications, what was the point of creating it?

At the time that WCF RIA Services was first shown to the public as Alexandria, Silverlight was still looked at as a Flash and HTML replacement. The idea of using Silverlight as important tool for creating LOB applications was in its infancy. That happened later as Windows Forms refugees like myself who has been forced to suffer under the yoke of ASP.NET Web Forms for several years looked at Silverlight as the way out of our misery. At the time I remember being asked by Microsoft employees on the Silverlight team why programmers like myself were interested in using Silverlight to create LOB applications. From their perspective, they just needed a way to create simple business applications, not large scale LOB applications, and the DomainDataSource was really good at doing that.

Wait, you lost me, if the DomainDataSource was the main product of WCF RIA Services, how could thinking of it as the primary component of WCF RIA Services be a mistake? It was the primary component!

The history of Silverlight is littered with intentions to create one thing resulting in the creation of a completely different thing. Silverlight started off as a replacement for Flash and HTML, it ended up replacing Windows instead. I highly doubt that WinRT would be where it is today if Silverlight hadn't blazed the trail to begin with.

In the case of WCF RIA Services, the programmers and arcitects at Microsoft who were assigned to the project were simply better at their jobs then they needed to be and the back end of WCF RIA Services was over designed. While the DomainDataSource is of limited utility in complicated Line of Business applications, the back end code that was written to support the DomainDataSource does not have that same limitation.

OK, sum it up for me

When WCF RIA Services first came out, the DomainDataSource was the star component that needed to be showed off. As time went by, LOB development became a really important part of Silverlight development, the importance of the DomainDataSource waned, and the importance of the code components of WCF RIA Services became more important. The problem was that the original demos, documentation, and presentations given on WCF RIA Services were still all about the DomainDataSource which was no longer the most important part of WCF RIA Services. Learning how to use WCF RIA Services correctly came from reading my blog, John Papa's presentation at Silverlight Firestarter, the blogs of the RIA Services team at Microsoft, and the forums at Silverlight.net where I constantly repeated the "Do not use the DomainDataSource" refrain over and over again.

That is why we are in the positon we are in today, to most of the community WCF RIA Services is still thought of as the DomainDataSource, a simple control only good for simple applications. In future musings, I am going to look at the rest of WCF RIA Services and what it really is. Along the way, I hope to redefine just what WCF RIA Services is.


WCF RIA Services is Dead, Long Live WCF RIA Services

7/3/2013 Make that WCF RIA Services is Dead, Long Live Open RIA Services

Today, Microsoft officially and publically revealed that development of Upshot.JS and DataController, the spiritual if not actual WCF RIA Services V2, will not continue at Microsoft.

With WCF RIA Services V1 joined at the hip with Silverlight, that means that WCF RIA Services is in whatever category you consider Silverlight itself being in. Personally, I am still writing new Silverlight applications and using WCF RIA Services. I think that will continue for a few more years before my client get ready to start moving off of Windows 7 as their primary platform. At that point I will probably start porting our Silverlight applications to WinRT.

So, what does this news mean to us?

  1. Microsoft still supports WCF RIA Services.
  2. I still support WCF RIA Services.
  3. I still expect WCF RIA Services to get EF5 support, that falls under Microsoft's responsibility to support the product they have already released.
  4. Don't expect Microsoft to release any additional functionality for WCF RIA Services.

What about the future:

  1. I am pushing to get WCF RIA Services V1 open sourced. If that happens I will be porting it over to WinRT and making large scale improvements to the Silverlight client.
  2. If you need something now to port to WinRT, or you need something that has a bit more umph behind it as far as support goes, I would recommend looking at IdeaBlad DevForce. It is similar to WCF RIA Services in many ways but it supports almost every platform including WinRT.
  3. As far as Upshot goes, if WCF RIA Services is open sourced then I will be looking at alternatives to improve HTML5 support for WCF RIA Services. For example, IdeaBlade has an open source alternative to Upshot.js named BreezeJS. I haven't had a chance to check it out yet but it may be a candidate for later adoption.
  4. I am also strongly considering replacing the DomainService with the DataController but I will probably change the name to DomainController.

Is there anything the community can do?

Yes, put pressure on Microsoft to get WCF RIA Services open sourced. My hands are tied until that happens.

6 Month Update

It has been a little over 6 months since this blog entry went up, so I decided to update it for anyone new happening upon it. Newer blog entries contain the development plans for an Open RIA Services. The current status is that Microsoft doesn't need any convincing, we are just waiting on the lawyers.


The Quick and Dirty EF 4.1 Code Generator

Have you ever wanted a fast, easy way to generate EF 4.1 Code First POCO objects from a database without using a lot of resources? Here is my attempt at solving that problem. You simply run this query in SQL Server (with a table name set) and SQL Server will generate code to populate your POCO object as fast as you can push the execute button.

declare  @tableName varchar(50)
set @tableName = 'TABLE NAME HERE'
declare @ConvertTable table
        SqlType varchar(50),
        ClrType varchar(50),
        IsNullable char(3)
INSERT INTO @ConvertTable
VALUES ('bigint', 'Int64', 'NO')
, ('binary', 'Byte[]', 'NO')
, ('bit', 'Boolean', 'NO')
, ('char', 'char', 'NO')
, ('date', 'DateTime', 'NO')
, ('datetime', 'DateTime', 'NO')
, ('datetime2', 'DateTime', 'NO')
, ('DATETIMEOFFSET', 'DateTimeOffset', 'NO')
, ('decimal', 'Decimal', 'NO')
, ('float', 'Double', 'NO')
, ('int', 'Int32', 'NO')
, ('money', 'Decimal', 'NO')
, ('nchar', 'String', 'NO')
, ('numeric', 'Decimal', 'NO')
, ('nvarchar', 'string', 'NO')
, ('real', 'Single', 'NO')
, ('rowversion', 'Byte[]', 'NO')
, ('smallint', 'Int16', 'NO')
, ('smallmoney', 'Decimal', 'NO')
, ('sql_variant', 'Object', 'NO')
, ('time', 'TimeSpan', 'NO')
, ('timestamp', 'Byte[]', 'NO')
, ('tinyint', 'Byte', 'NO')
, ('uniqueidentifier', 'Guid', 'NO')
, ('varbinary', 'Byte[]', 'NO')
, ('varchar', 'string', 'NO')
, ('xml', 'string', 'NO')
, ('bigint', 'Int64?', 'YES')
, ('binary', 'Byte[]', 'YES')
, ('bit', 'Boolean?', 'YES')
, ('char', 'char?', 'YES')
, ('date', 'DateTime?', 'YES')
, ('datetime', 'DateTime?', 'YES')
, ('datetime2', 'DateTime?', 'YES')
, ('DATETIMEOFFSET', 'DateTimeOffset?', 'YES')
, ('decimal', 'Decimal?', 'YES')
, ('float', 'Double?', 'YES')
, ('int', 'Int32?', 'YES')
, ('money', 'Decimal?', 'YES')
, ('nchar', 'String', 'YES')
, ('numeric', 'Decimal?', 'YES')
, ('nvarchar', 'string', 'YES')
, ('real', 'Single?', 'YES')
, ('rowversion', 'Byte[]', 'YES')
, ('smallint', 'Int16?', 'YES')
, ('smallmoney', 'Decimal?', 'YES')
, ('sql_variant', 'Object', 'YES')
, ('time', 'TimeSpan?', 'YES')
, ('timestamp', 'Byte[]', 'YES')
, ('tinyint', 'Byte?', 'YES')
, ('uniqueidentifier', 'Guid?', 'YES')
, ('varbinary', 'Byte[]', 'YES')
, ('varchar', 'string', 'YES')
, ('xml', 'string', 'YES')
 'public '+ ConvertTable.ClrType + ' ' + column_name + ' { get; set; }'
 INNER JOIN @ConvertTable ConvertTable
 ON information_schema.columns.DATA_TYPE = ConvertTable.SqlType
 AND information_schema.columns.IS_NULLABLE = ConvertTable.IsNullable
 TABLE_NAME = @tableName
order by ordinal_position


Microsoft's New Mullet

Yesterday the following slide was shown at Build:


Original Slide

A lot of people are misreading that picture as this:


Old and busted slide

But I see it is as looking like this:


Mullet slide

UPDATE: A little more explanation here. I am not saying that there will not be any business applications using the Metro interface or consumer applications using the desktop interface. I actually belive that we will be seeing lots of split personality LOB applications where a read only or quick entry screen will use the Metro interface while the main application is still using the Desktop interface. However, I am saying that I think most LOB applications will not lend themselves well to Metro.

My current thinking is based around information density. I think the Metro UI is extemely good at presenting a relatively small amount of data to the user in a very easy to consume way. For example, by glancing at my phone I can quickly understand everything from the weather to how many emails I have. The desktop metaphor has never been very good at this kind of thing. On the other hand, the "classic" desktop UIs are extremely good at presenting extremely large amounts of data to the user in a understandable way. The LOB applications I work on every day would never work in a Metro UI.  There are other parts that are screaming to be put into Metro so that they can be used in the field on a tablet. One of the big challenges we will be facing is how to write composite applications in Metro and Desktop UIs that do not drive our users crazy flipping back and forh between UI types. I have coined a term for this "UX Thunking". I hope to see the term spread.

Month List