Evolution in Data Integration From EII to Big Data
Approaches to integrating data are changing with emergence of cloud computing.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
The Future of WCF Is RESTful [Updated]
Posted by Abel Avram on Oct 21, 2010
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.
- See more SOA content at: http://www.infoq.com/soa
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
Suprising
by
James Watson
Posted
Re: Suprising
by
Duraid Duraid
Posted
Re: Suprising
by
Darrel Miller
Posted
Re: Suprising
by
Glenn Block
Posted
Misleading
by
Darrel Miller
Posted
Re: Misleading
by
Darrel Miller
Posted
Re: Misleading
by
Abel Avram
Posted
Re: Misleading
by
Darrel Miller
Posted
Re: Misleading
by
Glenn Block
Posted
Re: Misleading
by
Chris Edge-Alexander
Posted
Re: Misleading
by
James Watson
Posted
Re: Misleading
by
Glenn Block
Posted
Re: Misleading
by
James Watson
Posted
Is this the rigth choice?
by
William Martinez
Posted
Re: Is this the rigth choice?
by
William Martinez
Posted
Re: Is this the rigth choice?
by
Darrel Miller
Posted
Re: Is this the rigth choice?
by
Glenn Block
Posted
Re: Is this the rigth choice?
by
William Martinez
Posted
Re: Is this the rigth choice?
by
Glenn Block
Posted
Corrections
by
Colin Jack
Posted
-
Is it just me or is this really significant? Given that MS created SOAP and were a major contributor to defining WSDL, it seems like a big deal that they are kicking SOAP to the curb.
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. -
Well they've been doing many such things lately like moving from asp.net webforms to mvc and from ajax.net to jquery. Behold Mirosoft is awakening!
-
They are definitely not "kicking SOAP to the curb". This initiative is really just a recognition that the best way to support multiple protocols is not to abstract the differences away. The idea is to embrace and expose the different protocols but have the implementation of those protocols share some common proven infrastructure.
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. -
Unfortunately, this article is misleading. What Glenn was describing was a change to the way WCF exposes HTTP based services. He was not trying to infer that all of WCF was going to be replaced to use HTTP everywhere. There is a huge difference there.
The other protocols that WCF supports will continue to be supported as before. -
o-o. I just re-listened to Glenn's E-Van again and it does sound like he saying that WCF is going to use HTTP everywhere. I'm quite sure that's not what he meant and I'm sure he will provide clarification very soon :-)
-
Interesting.
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. -
Hi Darrel,
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. -
Ok. 55 minutes later on the webinar it has a new shape.
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! -
Nah, you are over-reading Glenn's enthusiasm for his current project. I am convinced the other protocols are going to continue to be developed and supported as equal peers to the HTTP protocol.
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. -
You have no need to fear. This is truly about allowing HTTP to be used as an application protocol. There are lots of extra features that allow you to make the mapping from bytes on the wire to strong types in the easiest way possible, but HTTP and RFC2616 remain first class citizens.
-
Hi James
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 -
Hi William
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. -
Exactly what Darrel says. The idea of supporting specific protocols is a strategy shift, but it is in-addition-to not a replacement of. We think there are other places we may go in the future to support other protocols in a similar fashion, for example you could imagine an MSMQ specific protocol (not committing to this, but just as a thought experiment) :-)
-
...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. -
Great! Darrel, Glenn.
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! -
...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. -
Thanks William
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 -
James, in addition to not retiring our old stuff, we are looking ahead at applying more specific app layer protocol support like we are doing here for other protocols going forward. This is just the first of many efforts to come.
-
Glenn-
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 -
I'd suggest removing this line as its not really what he said:
"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."
20 comments
Watch Thread Reply