Silverlight is a pure client technology. So, it has nothing to do with your SOA strategy, right? Not so fast. While most Service-Oriented Architectures try to remain agnostic about the clients who will approach the system, you can't be totally ignorant of the constraints that clients might impose. There are many "potential" requirements that architects have to think about. For every requirement that gets written down, there are usually two or three other implied requirements that never get expressed on paper. Architects just make sure that the plumbing of the applications help the developers to handle these cases when they arise. Of course, this is why WCF abstracts the concept of bindings as well as it does. Being able to expose any WCF service through a variety of tuneable, standards-based and proprietary bindings is one way that an architect can remove some rigidity from the system.
Silverlight is interesting because it exposes WCF client classes like ClientBase<T> and ChannelFactory<T> to a class of users who've never drunk from the services well before, so to speak, at least not directly. There is a notable exception from Microsoft in the not-too-distant past. Remember the DHTML Web Service Behavior? This was an HTML Component (HTC) script published by Microsoft just as XML Web Services were beginning to become popular. It used the XMLHttpRequest Object exposed by the browser to allow client-side script to invoke web services using WSDL and SOAP. The HTC would automatically download the WSDL contract for a service and build dynamic objects to expose the service and its operations at runtime. What an incredibly simple and powerful tool that was! It didn't support anything but simple data types for moving information between the browser and the server. But, when you have a XML Data Islands and a JavaScript Base64 codec on the browser, there's not much data that can't be expressed as a string.
I wrote many applications using the DHTML Web Service Behavior before the term AJAX appeared on the scene. Maybe this why when AJAX started to become a movement, I wasn't all that impressed. It seemed like old news to me. I remember how I designed those services. I took great care to make sure they were stateless and load-balancer friendly. I set up security protocols that would detect and prevent malicious activity. I had all sorts of profiling and logging code in there. In short, I treated those services with the same care that a good architect applies to any real web service. However, when the AJAX movement started, a lot of the scrutiny that I would have applied to real web services didn't seem to be in fashion for the many AJAX callbacks flying about. Those AJAX callbacks were somehow second-class citizens from an architectural point of view, not because I wanted them to be so but because many of the developers encapsulating callbacks into their AJAX controls didn't think of them as real service calls. And because it was up to developers, not architects, to drag and drop AJAX controls onto a design surface, the attention just wasn't there to do what was right in all cases. Hence, a lot of poorly-structured AJAX applications were written (and are still being written today).
Today, REST and POX are becoming popular for accessing web services. This is due, in large measure, to the rise in popularity of scripting languages and the somewhat duanting complexity of WSDL and SOAP. However, Microsoft proved that SOAP 1.1 could be handled via JavaScript as described before. And you can imagine that a company like Microsoft, if it decided to pursue the refinement of its DHTML Web Service Behavior, would have been able to handle the dynamic creation of data contracts via JavaScript, too. The problem wasn't the service contracts, operation contracts, fault contracts and data contracts. The real problems with dynamic, JavaScript proxies are security, reliability and transaction management. Those are the things that differentiate SOAP from all other forms of web service access today.
Back to the premise. With the WCF client classes moving to millions of desktops via the web, there's a shift coming in the SOA world. This creates for the first time what I call the Web Desktop. Being able to extend standards-based security, reliability and transaction management to the Web Desktop means that architects will feel more comfortable moving their SOA strategy up the stack. This is a very good thing. Most serious software developers love and hate the web. The deployment model is great but what's good about it sort of stops right there. HTML and JavaScript are just awful mediums for expression. And what about debugging client-side script? Nothing short of a nightmare, that is. It's no wonder that it's taken this long and hundreds of millions of dollars of research and development across the industry to get decent DHTML/AJAX applications into circulation. Event still, the quality and reliability of those applications across so many browsers and platforms is often sketchy. And the cost to implement such an application and properly test it is out of reach for all but the wealthiest companies.
The coming changes due to WCF support in Silverlight probably won't be cataclysmic but the changes will offer useful new ways of thinking for solution architects and developers who understand how poorly all of us are exposing applications over the web today. To dampen the spin a bit here, I should tell you that the Silverlight 2 Beta 1 is still a bit weak on the WCF front. It has near nil support for metadata exchange and only supports the BasicHttpBinding. But Beta 2 promises many improvements. Stay tuned.
Subscribe