Enterprises using the .NET Framework have been investing in their code bases for more than a decade, using proprietary Microsoft technologies such as .NET remoting, Windows Forms, ASP.NET, Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Silverlight, and ASP.NET MVC. Software developers in those enterprises now face the challenge of leveraging their extensive expertise in .NET development in the brave new world of applications based on HTML5, JavaScript, Cascading Style Sheets (CSS), HTTP REST, and web APIs, as organizations adopt these technologies to build state-of-the-art applications.
.NET-based software teams can and should modernize their development approach by transitioning to the newer technologies. To do so, developers will need to move away from proprietary Microsoft front-end technologies to HTML5/JavaScript/CSS and from a back end based on WCF services to web APIs. In this article and subsequent articles in a multi-part series, I will discuss an approach to modernization that can help software teams move to the newer development technologies. This approach lets you use every line of .NET code written as business logic and, when necessary, employ Microsoft BizTalk Server to aid with the transition. This modernization approach can help .NET developers build applications that support standard enterprise requirements such as logging, security, scalability, and maintenance yet are flexible enough to accommodate all new connected devices.
Moving Away from Proprietary Technologies
Proverbial ".NET shops" typically have significant investments in various Windows servers—Microsoft IIS, SQL Server, BizTalk, and others. Abandoning these technologies and the considerable expertise a development team has acquired in implementing them is not feasible in the short term. To give your modernization effort the best chance of success, you must carefully strategize and direct your organization to a future in which you have access to a more diverse pool of developers who are adept with the newer technologies and a code base that can evolve without costly rewrites.
To get a good understanding about the next steps you'll need to take toward modernization, it's useful to consider some of the first principles of client/server communications. My introduction to client/server communications was through .NET remoting, the tail end of a series of technologies that includes OLE, COM, and DTS. Remoting made an object "remotable," thereby allowing you to write a piece of business logic without having to think about client/server boundaries. The relevant portion of the code would execute either on the client or on the server side. In theory, this was a great idea. The catch with remoting was that it required you to tightly couple client-side logic with server-side logic, essentially locking you into the particular client-side technology you were using. Can you imagine shipping the latest version of your product in 2014, still using Windows Forms? Sadly many companies today are in such a predicament. The only way out is to rewrite the entire application, in the process throwing out years of bug fixes.
Another downside of .NET remoting is that it is difficult to understand and also hard to set up, although you don't need to understand it to work with it, especially if someone else has already set up the basics and you're just doing the implementation. Essentially .NET remoting is a "black-box" technology. Microsoft's successor to remoting, WCF RIA Services, is similar to remoting. In both remoting and WCF RIA Services, everything works great with simple data grids. But for both technologies, the downside is that once your application gets complicated enough, the black-box nature of remoting and WCF RIA Services turns out to be their Achilles' heel.
Thus, from considering the strengths and weaknesses of these two familiar, proprietary Microsoft solutions, we can infer what characteristics we want in the technology that will carry us forward. This development technology should be open, easy to work with, easy to understand, and powerful enough to scale and be secure.
Service-Oriented Architecture and Modernization
When I worked with .NET remoting, I read a lot about service-oriented architecture (SOA) and its promising future. During that time, Microsoft delivered WCF, intending it to be the be-all and end-all communications stack. However, many deployed services that use WCF also include Simple Object Access Protocol (SOAP), XML, and Web Services Description Language (WSDL) technologies, which enforce endpoint interfaces to be well defined and are as verbose as can be when transferring data over the wire. Many organizations approach the idea behind SOA incorrectly and believe that SOA requires WCF with SOAP.
An ideal SOA setup would be to split up your business logic into logical services, and, if you follow the single-responsibility principle, you'll end up with a nicely modular back end. As a bonus, your back-end logic is automatically decoupled from your front end. Because all logic is nicely compartmentalized, during development ideally all you'd need to do would be to work on the service you're interested in, so that you are exposed to a limited portion of the code base. In practice, however, development environments are set up so that you have to build all services all the time—an arrangement that removes many of the advantages of SOA. The configuration complexities that developers routinely face just testing and implementing simple features become frustrating and unproductive.
A lot of development teams find it difficult to move away from the idea of strongly typed and well-defined endpoints inherent in SOA. A decade of C# and the promise of compile-time certainty is mostly the driver behind this thinking. However, well-defined endpoints are beneficial only when you use the waterfall model of software development and do all your requirements gathering and analysis up front. Only about 30 percent of projects that use the waterfall model ever succeed. Compile time certainty might be great, but that doesn't matter if the project is never even completed.
In contrast with waterfall development, in an agile development environment that uses the Scrum development methodology, project success rates typically exceed 70 percent. In Scrum you iteratively develop slices of functionality and incrementally deliver them, discovering requirements as needed, incorporating feedback, and making corrections along the way. In this context, well-defined endpoints are akin to a wrench in an otherwise smooth-running piece of machinery. The amount of effort required to change a field's type in a SOAP service, deployed over several servers with different parts of the service maintained by different teams, is a daunting task. A quick bug fix turns into endless meetings and a slow-moving process that only invites more bugs.
Low coupling and high cohesion, encapsulation, abstraction, and single responsibility are some of the benefits of SOA. Having an effective SOA in place is essential to ensuring the long-term viability of your code base, no matter what your technology stack is. In an increasingly mobile world, where your data and services can be consumed by a diverse set of devices, your code base must be flexible. Lessons learned from past experiences show that Microsoft's at times cumbersome, proprietary SOA technologies don't mix well with new technologies, including Microsoft's very own, and don't allow for an effective agile Scrum implementation, making it difficult and costly to iteratively evolve your code base.
The Future Is HTTP
Earlier, I named the characteristics of the ideal development technology—in particular, for developing services. Such a technology exists. It is HTTP: proven, stable, and the most widely used communication standard. HTTP REST communications with JavaScript Object Notation (JSON) serialization offer frictionless, standards-based interoperability, making it possible to have a heterogeneous technology stack, so that you can use the right tool for the right job. Microsoft's maturing Web API and SignalR technologies are well positioned to take advantage of HTTP REST and WebSockets. We'll start looking at HTTP REST in the next article in this series, where I will explore in more depth how you can gradually transition your code base to the standards-based technologies mentioned here, using tools, technologies, and skill sets familiar to your enterprise, as well as pitfalls to avoid in such a transition.
