During my last project, I took the time to take a look what we had build and re-build over the last couple of years and decided to redesign the library from the ground up. After some initial designs I noticed that my initial decision to use ASP.NET MVC as the basis for my complete rewrite turned out to make things much more complex in some areas. I also remembered that the most problems we had with previous designs was to find the right mechanism to “jump” between different views. Over the course of earlier WebForms solutions we used Server.Transfer, Response.Redirect, CrossPagePostbacks and other options, but it remained one of the biggest challenges.

Following that insight, I did two things. First of all I completely separated the UI part (how to display the view) from the Flow part (decide which view should be next). The “UI independent” Flow part – now called WebFlowManager – connects to the framework-specific part using a single enum as light-weight contract. The second thing I did was to implement a completely new WebForms based implementation of the UI part which I named WebFlowContainer. That WebFlowContainer basically holds references to actual UserControls that represent the actual screens and knows how to display them. I also decided to use UserControls (or WebControls) instead of complete ASPX pages for the views, which is another key learning of several earlier WebFlow versions – it makes things much easier than having to deal with the above mentioned “jump” mechanisms.

So, how does the new library actually work? Well, to use version 0.3b – which, despite its naming, is quite powerful already – with WebFlow, you have to do the following things:

1. Define a simple Enum type that contains all the steps you want to use in your wizard (“MyPwp” is the name of the demo project). This is the glue that connects the WebFlowManager to the WebFlowContainer.
   
2. Add a <webFlow:WebFlowContainer> control to your ASPX page and register all views (as simple UserControls or WebControls) by placing them within the WebFlowContainer.
   
3. Assign Enum flags to every UserControl / WebControl.
   
4. Create the definition of the actual web flow using a new class that inherits from WebFlowDefinition. The WebFlowDefinition returns a list of steps (IWebFlowStep) and the initial step as Enum (FirstStep).
   
5. Implement each IWebFlowStep using the ID, Next and Prev properties, optionally extending its functionality with the following delegate properties:
   Check() – Is the user allowed to “see” this view at this moment. If not, raise an exception.
   Init() – What needs to be done to initialize this view.
   Validate() – What needs to be validated after the user has submitted the view? If there’s something wrong with the data, raise an WebFlowValidationException.
   Complete() – What should happen after the submitted input has been validated?
   
6. Connect the WebFlowContainer and the WebFlowDefinition using the WebFlowManager during the Init event of your ASPX page and initialize the framework.
   
7. Implement the “next” and “prev” buttons with simple calls to the WebFlowManager. (Note: Future versions of WebFlow will also support additional custom commands such as “buy”).
   
8. Start your web app and browse to the ASPX page with the WebFlowContainer.

Although the concept of management and the concept of leadership are probably the most powerful skill combination in the world, they are actually two quite different things. While management is primarily the practice of transforming resources into value for a group of customers by taking responsibility for performance and producing results, leadership is first and foremost the ability to create a compelling vision, inspire people to follow you on the way towards achieving it and finally making it a reality by convincing the hearts and minds of others to take action.
However, both share a common principle that is fundamentally important for their success: Trust. Although we don’t know a great deal about trust, we do know that it is essentially about believing in someones predictability. And we know that it usually takes years to build it and just seconds to destroy it. Microsoft might just have done that.

And that’s a pity, because trust is an indispensable ingredient if you want to build and keep a global community of technology professionals who base their work on your products. So the question is, why would Microsoft risk losing it twice in a row when it comes to a strategic technology like WPF / Silverlight? My guess is, they wouldn’t – they just didn’t think enough about what they should have been telling people.

WPF and Silverlight are probably the most advanced technologies for desktop, rich internet and mobile phone applications in the world today and a lot of Microsoft’s success in the recent years is based on a loyal developer community that went along with a major technology change in .NET 3.0 by shifting their mindset away from WinForms, Mobile Forms and Flash to embrace these technologies. Nobody at Microsoft, not even the IE9 crew who just moved on from being “the guys who brought you IE6″, could be so arrogant to ignore that fact.

But if that’s true, what is this announcement of Windows 8 using HTML5 and JavaScript to build the new shell UI really about? From my point of view, it’s quite simple: HTML5 and JavaScript are just the lowest common denominator. In addition to the thousands of WPF and Silverlight developers that currently cry their heart out, the guys building the new Windows UI had a couple of other guys to take into consideration as well: The thousands of Win32/C++ developers, the thousands of ASP.NET web developers, the thousands of Office developers and the thousands of developers that use other toolsets to build applications for Windows (Java, Python, Adobe Air, etc.).
So ask yourself the question, what would you have done? Do you really think, you could convince people to install Visual Studio, learn XAML and build WPF / Silverlight apps just to hook up your native Win32 app in the Windows Start screen? What if you only wanted to build a lean cloud app and that can be launched easily from Windows’ main shell UI? Exactly, you would have chosen a technology that everyone can, and probably already has, learned to some extend and which is simple enough that you don’t have to write dozens of HowTo tutorials. And what else could that technology be if not HTML5 and JavaScript?

Building the new Windows 8 UI based on HTML5 in order to enable all those developers mentioned above – regardless of their framework, their skill set and their technology – to utilize its full potential is the right decision. Period. The real problem is that Microsoft failed (again) to explain this to the thousands upon thousands of developers who have just watched the Windows 8 introduction video from Microsoft UI design team. That’s the issue, not more and not less.

So what should we as developers do? In my opinion, we should ask Microsoft to confirm that the current situation is indeed based on a communication issue (again) and that our investment in Microsoft’s next generation UI platform WPF / Silverlight is safe. And what should we expect from Microsoft? Well, in order to fix the current situation, the company has to demonstrate their commitment to the investments made by the Microsft developer community. And who could do that more effectively than Scott Guthrie and Steven Sinofsky? I really think, those two guys should put on their strategic hat and answer those questions themselves – it is now time to act quickly and decisevly, gentlemen. Maybe after that, we can all get back to those things that are really important and don’t waste our time with rumors and end of days scenarios.

For those of you who visit this blog for the first time, I would like to summarize my background in the software industry a little bit. It is always important to understand who is making a statement in order to understand the underlying motives better. So before you need to speculate too much about it, here are the facts: My name is Julius Ganns and I’m a software architect and manager from Germany. I have a software development experience of about 14 years and a software architecture experience of about 8 years, and over that time frame, I worked with a lot of platforms, languages and frameworks – including, but not limited to, Perl, PHP, VB, VBA, VBS, Ruby, Java EE, C++, JavaScript, C#, .NET, Groovy, F#, and Python. A couple of years ago, I choose .NET as my primary platform for professional purposes, but I’m still very interested in other interesting features and functionalities outside of the Microsoft space (I especially admire Ruby for its speed of innovation and Java EE for its well-designed architecture in several of its core frameworks).

So what’s my view on the current discussion about whether .NET and Microsoft’s platform stack is a viable option for start-ups or not? Well, first of all, I worked in one of those start-ups and we have never regretted to switch to .NET as our primary technology stack. I’m not saying that there weren’t any challenges, and I’m not saying that we had everything we needed right from the start, but the Microsoft development stack has changed significantly over the last seven years and if I had to make the decision today, I would definitely go for .NET again.

Obviously, Microsoft had large gaps in their development platform back in 2005 when we wrote our first larger project with the beta version of .NET 2.0. There wasn’t a decent object/relational mapping framework (and please don’t get me started on DataSets here) and coming from a Java EE world, the event-based, component-centric WebForms framework was not easy to work with either during the first three months or so. But in retrospect, the major problem we had with .NET was our attitude: If you approach a new framework (like WebForms) with your existing mindset (coming from Struts and PHP) and don’t try to understand first what you’re working with, failure is to be expected – and that is true for every platform, every language and every framework.

In the world of 2011 however, there isn’t one single platform offering in the world that would allow you to start software development as quickly, as easy, as cost-effective and as professional as the Microsoft platform does. Just take a look at http://www.microsoft.com/web, download the Web Platform Installer and select everything you need – starting with a web server (IIS or IIS Express), a database server (SQL Server Express or other), a project workspace (WebMatrix), a first-class development environment (Visual Studio Express), and dozens of frameworks based on the Microsoft .NET platform like ASP.NET (with WebForms, MVC, Dynamic Data), LINQ, the Entity Framework, AppFabric (WCF, WF), Silverlight and several other ones. There are also hundreds of open source tools and libraries available, either from Microsoft’s CodePlex site or using the NuGet technology.

But actually, that is not even the reason why I would recommend the Microsoft platform as the right technology for start-ups. I recommend it, because there will (hopefully) come a point in your company’s lifetime, where you don’t want to be a start-up anymore. And while this situation first and foremost demands a new way of thinking and working (and thereby new processes and priorities, new structures and systems) the question is how fast you can adapt your existing technology stack to meet the new demands.
Will your perfect “start-up technology” still be enough to do serious business with large customers or large amounts of users? If not, is there at least a clear path to migrate it to the next level? And what about the skills of your experienced and loyal people? Although you definitely can’t continue to do what you did so far, can you at least re-use most (or at least some) of your technologies, tools and systems?

Looking back at the history of my former start-up (which still exists and flourishes, by the way), the processes, priorities, structures and non-IT systems were much more of an issue than the technology we used. Of course those were things we were able to change in large parts, but believe me, we were quite happy that we didn’t have to switch the technology platform at the same time. At least for us, Microsoft’s technology stack and the way we used it turned out to be the right one – even for larger endeavors.
Today I’m working in several multi-million enterprise projects with huge server farms and heavily customized enterprise technologies – and I’m still using most of what I learned in the early days of my career. The reason for that is simple: Microsoft’s technologies and tools – even if not always perfect – usually provide a common “appearance” from the perspective of developers and architects, enable your good people to re-use existing knowledge and have built-in integration capabilities to integrate products across the overall MS portfolio. And that is something, you will not find for years in any of the often-called “lean” start-up technologies like PHP and Ruby. Of course you will find these enterprise capabilities in Java EE, but unfortunately that platform (while being exceptionally well-designed, versatile and powerful) is one of the most overwhelming and complex pieces of technologies currently existing.

In the end, my conclusion is quite simple: In the start-up phase, there isn’t a huge difference between those technologies that have been discussed so vividly, sometimes even violently, in the last couple of days. Although .NET’s reputation might not be as “cool” as some of the others, it is definitely one of the top choices and in regard to what you get out-of-the-box and what you can do with very little effort, is is probably one of the top three. The major difference, however, will emerge just after the first two or three years when your company is getting more grown-up and your technology stack has to keep up with the demands of the organization. This is where most companies fail (usually because of issues that initially don’t have anything to do with IT) and where technology should be the enabler rather than something, that “has to be changed, too”.

Looking forward to your comments,
All the best,
Julius

Guess No. 1: Silverlight will become what the name “WPF/E” promised – and cease to replace Adobe’s Flash format

Obviously, HTML5 will play a major role in Microsoft’s future web strategy. Nothing to be argued here. The question is, however: What will happen to Siverlight? According to various sources, Silverlight’s focus will shift away from attacking Flash and the browser addin will become what it’s first codename “WPF/E” (Windows Presentation Foundation Everywhere) tried to express a few years back: A runtime environment for rich applications on all (Microsoft) devices. From a consumers point of view, this will primarily be Windows Phone, but another main hotspot for Silverlight will be the space of corporate and enterprise business applications. The reason for that is simple: Silverlight solves about 90% of all deployment and versioning problems that large business software projects had to deal with in the last 15 years: Access can be provided over the web to nearly all places, applications run either within the browser or on the Vista / Windows 7 desktop, the runtime environment is lightweight, communication and integration options exist for nearly all cloud- and server-side endpoints, integration with existing desktop apps is on its way, and the UI options and features are what most people expect from a modern user interface framework. What does this mean for you as a developer? Well, if you’re already in the “internal apps” space, you’re CV has just received a major plus point if it includes Silverlight. If you’re, on the other hand, focused on “public apps” running in the web, it’s now time to switch to HTML5 and JQuery (or any other powerful JavaScript library).

Guess No. 2: WCF will get a major upgrade – and focus on HTTP

While there weren’t many session around WCF at the PDC, a lot has been written and broadcasted before and after the event itself. One of the mosts significant posts is “The Future of WCF is RESTful” on InfoQ from October 21st, Glenn Block’s session at the PDC itself and his blog post titled “WCF Web API’s, HTTP your way”. Instead of repeating the content here, I highly encourage you to read the articles yourself, and to dive deeper into the thoughts behind this decision, which can in large parts be found in Jon Flander’s fantastic book “RESTful .NET” (I it right after it was published) and in “RESTful Web Services” by Leonard Richardson and Sam Ruby from May 2007 (that one rested until October 2007 and thereby far too long on my “Books to Read” stack). While SOAP and WS-* based communication will remain a very important concept for large, transaction-oriented enterprise and B2B processes, REST has already started to take over the space of lightweight application integration. In addition to “pure REST”, Microsoft’s ATOM-based OData protocol will probably end up becoming the new number one standardized data access technology for the web. OData, originally developed by the WCF Data Services team (which was called ADO.NET Data Services team back then), has not been build into a variety of platforms, frameworks and products, including Microsoft’s business productivity and collaboration platform SharePoint 2010.

Guess No. 3: BizTalk will move to AppFabric – on-premise as well as in the cloud

Although it shouldn’t come as a surprise to those who have worked with WCF and WF4, I didn’t expect the announcement of the BizTalk tean so soon after the release of BizTalk 2010. Nevertheless, the new direction of BizTalk has been decided and you can read about it here: Changing the game: BizTalk Server 2010 and the Road Ahead. To make a long story short, BizTalk will be rewritten (or at least re-assembled) based on Windows Server AppFabric and Windows Azure AppFabric. It will probably adopt WF4 as its primary workflow engine and rely on WCF as its main communication layer. This is great news for WCF/WF4/AppFabric developers as well as for BizTalk developers – both will benefit from a unification of Microsoft’s SOA offering and I’m especially looking forward to the future direction of the ESB Toolkit 2.0.

Guess No. 4: The future of programming is asynchronous – but not necessarily concurrent or parallel

In the end of 2008, I started a blog series called “Asynchronou, Parallel and Concurrent Programming on the .NET Platform”. Although I never finished it (and my blog has been moved also), it would probably have been a big waste of time. In the end of 2008, there were so many different concepts and framework components to create asynchronous, parallel and concurrent applications, that it was really difficult to keep track and to take the right approach for the job at hand. Between Threads, TheadPools, Async-Methods, Begin/End Invole, Aynchronous Delegates, BackgroundWorker, lock statements and various other techniques (like the absolutely great Concurrency Coordination Runtime), developers usually started waving the white flag.
A couple of months ago, however, Microsoft released the Task Parallel Library – a unified approach to developing responsive application that utilized the features of modern multi-core processors and multi-user environments (like the web). Now, with the rising success of the Task-based programming technique, Microsoft’s language designers will introduce the concept as first-class citizens in C# and VB.NET. The way, Anders and his team have introduced the “async” and “await” statements is not only elegant on the optical and conceptual level – it is really one step ahead of the current discussion that focussed more on “creating and managing multiple threads” than avoiding it until it becomes absolutely necessary.
I strongly recommend taking the time to watch Anders session at the PDC and the Channel 9 interview with Mads, they will show you what elegant aynchronous programming is going to look like in the near future. After that, go and download the CTP of Visual Studio Async – I did it and rewrote a pretty complex application in about 10 minutes while reducing it to half its size.

That’s it for now from my side.
See you soon,
Julius

Take a look at what VS2010 offers to developers today already. Sure, if you’re going to create a larger application, you still have to think about things like solution architecture, application layers and tiers, services and components, and a lot of cross-cutting stuff like security and concurrency, but lets move away from that scope for a minute and focus on areas like rapid application development, prototypes, and mashups. If your goal is to show off results as quickly as possible, for example to test a concept or to present an idea, Microsoft offers phenomenal tools already. You basically start VS2010, create a new Entity Data Model, let it generate your database, create a RIA Domain Service, write three or four business methods and expose parts of your EDM to the world. After that you fire up Blend 4, create a new Silverlight app, drag a bunch of controls on the screen, wire up your domain data source with your domain service and vóila, there is your RIA business app. The story on the server-side for ASP.NET WebForms is basically the same.

Now consider what would happen, if your model would not only contain the structures and data you wanted to use in your applications, but also a definition of the corresponding processes and business operations in the form of a domain specific language. The whole development story would shift from the implementation of applications to the modelling of business concepts. A sophisticated business framework would then be able to expose the resulting logic as service operations and UI frameworks like Silverlight could pick up on the meta-data to propose a set of controls to create the client UI. What’s even more important than the rapid application development aspect, are the benefits of defining and managing information structures and business processes in a central location to distribute them across the enterprise. Today, re-defining a business process is not only a matter of deciding what to do and to create a business case, it is above all the effort to re-design and re-program the company’s information systems accordingly. If Microsoft would really be able to create a complete end-to-end story based on these technologies, all those hopes that were put in SOA, BPM, BI, rules engines and other types of dynamic IT initiatives might not be that unrealistic after all.

I’m not saying, that software development will become like a strategy game where you only have to place some artifacts on a diagram, but in the world of software engineering evolution is often accomplished by putting one layer of abstraction on top of another, while occasionally going down one level to fix some “not yet out of the box” issues. The truth is, it’s not longer about whether this will happen or not, it’s just a question of when.

Find out more about Oslo and the Entity Framework in this interview with Danny Simmons and on Douglas Purdy’s Blog. Also, make sure to take a look at the Model-Driven Development portal at the MSDN Data Developer Center. Rhocky Lothka also created a three-part video series about his “M”-based DSL for the CSLA.NET framework.

What do you think?

Instead of:
string propertyName = “Property”;

You can now write:
string propertyName = Prop.Name(() => obj.Property);
(“obj” being the object whose property name – “Property” in this case – you want to retrieve)

Or by using the PropName() extension method:
string propertyName = obj.PropName(() => obj.Property);

I’m currently researching a way to use .NET 4.0′s implementation of DynamicObject to simplify the syntax even further, and I’m planning to introduce a caching mechanism, but the current version of this very small library can already be used.

Download the binary assembly. Source code coming asap.

While EF now delivers what its name suggests – a framework that makes working with data entities easier -  it still lacks many features other ORM pioneers can bring to the table. As some of you might know, I started to work with NHibernate about three years ago (having already some years experience with Hibernate in various Java Enterprise projects) and I have to say, I was always excited about the way, new enterprise features were brought into the framework. The ones I’m missing the most in EF4 are especially lifecycle callbacks, which would allow the interception of mechanisms like object creation (e.g. to utilize DI and AOP frameworks), pre-defined fetching strategies (e.g. to retrieve certain properties with eager loading by default), the ability to update a database that was generated from a model instead of dropping and re-creating it, and more guidance on how to use a the frameworks in certain scenarios, as it is available for NHibernate’s ISession, ISessionFactory and Configuration classes. There is also no native support for a pluggable 2nd level cache, inheritance support is weak compared to other ORM frameworks, it doesn’t support batching (for queries and updates) yet and the enterprise tooling (e.g. optimization tools, sql statement logging, performance diagnostics, etc.) is virtually non-existent. For more information regarding the ongoing discussion about EF4 and NHibernate, make sure to read this post on InfoQ (I especially recommend the comments section) and this performance test by Gergely Orosz.

In the end, EF4 can now be considered a useful data access framework with a reasonable feature set and very good integration with .NET (and especially with LINQ, ADO.NET Data Services, and RIA Services) and VS2010. For Software Architects with experience in advanced engineering concepts (like DI, AOP, patterns & best practices) and ORM fans, however, it is not yet able to compete successfully with other solutions, but that might come in the near future.

I absolutely support that decision and I welcome the new spirit that found its way into the ASP.NET team since ASP.NET MVC was started. But it kind of makes me wonder what’s going to be next… exciting, isn’t it?