The Future of WCF Is RESTful [Updated]
- Share
-
- |
Read later
My Reading List
Glenn Block, a Windows Communication Foundation (WCF) Program Manager, said during an online webinar entitled “WCF, Evolving for the Web” that Microsoft’s framework for building service-oriented applications is going to be refactored radically, the new architecture being centered around HTTP.
Block started the online session by summarizing the current trends in the industry:
- a move to cloud-based computing
- a migration away from SOAP
- a shift towards browsers running on all sorts of devices
- an increase in the adoption of REST
- emerging standards like OAuth, WebSockets
He mentioned that the current architecture of WCF is largely based on SOAP as shown in this slide:
One of the key features of WCF is support for multiple transports (HTTP, TCP, named-pipes) under the same programming model. Unfortunately when it comes to HTTP, a lot of HTTP goodness (scale, content negotiation) is lost because WCF treats it as a transport. So Block is looking forward to see WCF supporting HTTP as a first class application protocol with simple and flexible programming model as depicted on the following slide:
HTTP was introduced in .NET 3.5, allowing the creation of services accessed via HTTP, but “it does not give access to everything HTTP has to offer, and it is a very flat model, RPC oriented, whereas the Web is not. The Web is a very rich set of resources,” according to Block. Instead of retrofitting the current WCF to work over HTTP, Block considers WCF should be re-architected with HTTP in mind using a RESTful approach.
WCF will contain helper APIs for pre-processing HTTP requests or responses, doing all the parsing and manipulation of arguments, encapsulating the HTTP information in objects that can be later transferred for further processing. This will relieve the user from dealing with HTTP internals directly if he wants to. This feature will also present a plug-in capability for media-type formatters of data formats like JSON, Atom, OData, etc. WCF will support some of them out of the box, but the user will be able to add his own formatters.
The new WCF is already being built, Block demoing sample code using it, but he mentioned that the feature set and what WCF is going to look like is not set in stone. They will publish an initial version of the framework on CodePlex in the near future for the community to be able to test and react, shaping the future of WCF. More details are to come during PDC 2010.
Update
We asked Glenn Block what it is going to happen to the other protocols, especially SOAP. His answer was that WCF is going to fully support the existing stack, and the current development is meant to evolve WCF to fully support HTTP without renouncing to anything WCF has so far.
A WCF Community website is now set up on CodePlex for all those interested in the evolution of WCF.
Glenn Block presented a more detailed view on the future of WCF and how it relates to current investments in Microsoft's SOA technology at PDC 2010.
Suprising
by
James Watson
I often don't recognize MS anymore. They seem to be casting off the 'bloat is just OK' mantra and trying to become more lean and mean. This is a smart direction and it's got my attention.
Re: Suprising
by
Duraid Duraid
Re: Suprising
by
Darrel Miller
The benefit of this approach is that you get to choose the right protocol for the right job, and be confident that they will happily play together on the same infrastructure.
Misleading
by
Darrel Miller
The other protocols that WCF supports will continue to be supported as before.
Re: Misleading
by
Darrel Miller
Is this the rigth choice?
by
William Martinez
I'm very happy MS is taking seriously REST, not just as a name tag to attach to my bumper. I mean, Glenn approached the REST guys to learn, with a low profile, humble questioning, eager to find out the true meaning of REST and ready to even make these deep changes to WCF.
Still, I wonder. Based on what I read here, it seems we have an interesting shift: Instead of supporting several protocols, WCF seems to support just HTTP, for whatever it takes. And since HTTP may have its complexities, WCF will provide a facade, that will hide HTTP behind objects. Fine, I guess.
But, here we may encounter the first little issue someone may raise later: the use of HTTP as a communication protocol instead of an application one. Not sure, though, as I have no more info, but getting rid of RPC conception is really difficult. If the WCF provides a way to map arguments, URIs and formats to objects, parameters and methods, it will end up being a wrapper to RPC. So, instead of helping the user to grasp REST idea, it will end up hiding REST under a object+methods representation. Ok, that is a speculation until I see the final WCF.
I still need to finish the webinar. So far, I got two new objects to encapsulate the request and response HTTP messages, which is good as that is one of my primary needs, to work with the message. Will finish watching the webinar to see if the fears may go away.
Re: Misleading
by
Abel Avram
Glenn was not specific on what will happen with other protocols and I did not say they will be thrown over the board. It is quite possible the old protocols to be supported in the MS backwards compatibility style, but all new stuff will go into HTTP. I am 90% sure of that because he said they will not repeat what happened to WF (Workflow) where there was a disruptive change.
Re: Is this the rigth choice?
by
William Martinez
Yep, it is not just a URI to object/method mapper. It is an attempt to allow modeling of HTTP and making that model as extensible and flexible as it can be. It is dealing with the processing of the HTTP messages following a Pipes&Filters style, so all I need to do is to add a new filter (processor). It also allows conneg, interesting.
It started to go beyond the messages by introducing a resource abstraction, at the service model level. There is a discovery part, which tries to map with resource enumerators, assemblies to resource abstractions in the request. That is very interesting, although we may be careful not to confuse resources to be services (they can be, but for REST realm they are datum).
Still needs some work, Glenn says. Sure! I will expect support for hypermedia (as a state engine) in the future. The service model is a broader thing. Services may be no just one resource, but a full set of interactions between several resources, all of them driven by hypermedia. Supporting that is not easy. But as Glenn mention, working with guys like Ian Robinson, Mike Amundsen, Jim Webber, Savas et al will help a lot and their hand is present. Still, I think the programming model so far needs some more cleaning up. For instance, the uses of interfaces and the processing flow is hard to follow, at least from the presentation. Codeplex will be good to fine tune this.
So, Congrats Glenn! Seems good stuff!
Re: Misleading
by
Darrel Miller
This project is about surfacing HTTP as a true application protocol instead it just being used as a transport.
REST is not the solution to every problem in the distributed system space and Microsoft know that. This is about bringing REST and HTTP up to be on an equal footing with the other protocols, not replacing them.
Re: Is this the rigth choice?
by
Darrel Miller
Re: Suprising
by
Glenn Block
I love your enthusiasm for what we are doing, and we share it. Just to make clear, we are not retiring our existing SOAP stack, or our existing HTTP stack. What we are doing is evolving WCF to provide richer support for HTTP and more targetted. The new support is opt-in, thus it will allow existing WCF HTTP customers to continue. We are also offering a migration path that makes it easy for folks to use the existing WCF HTTP programming model with our new infrastructure.
Thanks again
Glenn
Re: Is this the rigth choice?
by
Glenn Block
What we are doing is specifically designed to using HTTP NOT as just a transport protocol. The reason we are doing this work is because we agree with you that HTTP is much more than that and what is needed is a model and infrastructure built around that notion.
Re: Misleading
by
Glenn Block
Re: Misleading
by
Chris Edge-Alexander
...REST is not the solution to every problem in the distributed system space and Microsoft know that...
Hear, hear. Binary over TCP and MSMQ are two of the offerings I use myself. WCF has been a useful multi-tool so far, I'd be concerned if we lost all the options.
An easier to configure architecture is welcome though.
Re: Is this the rigth choice?
by
William Martinez
My 2 cents:
When getting to the resource abstraction keep in mind:
1. Protocol and resource management is one semantic level. The actual app semantics may be different.
2. Forcing the App domain or even the language paradigm into REST may not work, expose the REST paradigm and domain into the language through modeling. Yeah, confusing, I know.
3. Lots of developers questions are not about the server, but about the client, particularly with HATEOAS in the middle. It looks like we removed the workflow control of the system from the server, and put it into the client. The state/workflow business logic now resides on clients? Wrong, It is put into the message instead. Frameworks do a fair job supporting servers, but client side?
4. The other major part of questions is about media types. I feel it is not good to mix the media type semantics with the app semantics, and use both at the HTTP level. But this is a long and complex discussion. Just take that into account.
Great work. Now I can add WCF to my review of REST frameworks. Nice!
Re: Misleading
by
James Watson
...REST is not the solution to every problem in the distributed system space and Microsoft know that...
Hear, hear. Binary over TCP and MSMQ are two of the offerings I use myself. WCF has been a useful multi-tool so far, I'd be concerned if we lost all the options.
An easier to configure architecture is welcome though.
Just to be clear, when you transmit data through HTTP (e.g. a GET or a POST) that data is transmitted in binary over TCP. And I don't mean it's binary in the sense that everything is binary. I mean that your bytes are sent as you specify them. There is no encoding. There's a common misconception that HTTP requires everything be sent as text. The headers and parameters need to be sent as text but you can transmit arbitrary binary streams through HTTP connections.
One other thing that is not really relevant to this discussion but worth noting anyway is that REST is not specific to HTTP. Most people who talk about REST probably mean HTTP but you can implement REST using any technology. Technically, it's an architectural style and HTTP isn't actually a 100% implementation of it.
Re: Is this the rigth choice?
by
Glenn Block
1. Agreed
2. We're not actually forcing a REST paradigm. If you watched the talk our goal is really a first class HTTP platform that enables REST, not that forces it.
3. Removed how? Can you clarify? Using the new model you can create processors that include hypermedia constraints, thus the server sets the workflow.
4. Interested to understand that better. Can you email me, or start a discussion on the REST list :-)
Cheers
Re: Misleading
by
Glenn Block
Re: Misleading
by
James Watson
It would be great if a standardized way of specifying and providing documentation for custom content specifications were created and adopted. The biggest limitation for REST right now is that there isn't consistent way to provide documentation on how content can be understood when it isn't a standard content type. application/xml doesn't really cut it.
Thanks for getting involved in the discussion.
-James
Educational Content
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think