Mono 2.8 is approaching and I should indeed blog about it, but this post is about my recent hack in git head. Within the current future plan, we will be releasing 2.8.2 based on the git head, and by that time we'll deliver our results that I'm going to write here.
It is about WCF 4.0 implementation status in Mono. While it was not my priority, I have been somehow working on it (initially it was due to my laptop's crash and repair, now I rather want to finish this ongoing side work), it seemed good to write about it.
WCF 4.0 had added a lot of new features that didn't exist in 3.5/SP1. An excellent article by Aaron Sconnard is on MSDN, so I'll describe our ongoing effort based on the items he described.
| featured area | current status |
|---|---|
| Simplified Configuration | almost done |
| Discovery | Announcement: done. Discovery: ongoing. |
| Routing | done |
| REST improvements | not done. |
| WF4 support | no plan yet. |
(Note that this table does not contain other components such as WCF Data Services.)
Simplified configuration
In WCF4, configuration description can be reduced and it became much simpler to write. It's not always good as it also hides what WCF actually does from application developers, but almost everyone wouldn't understand what the engine does anyways, so no need to worry about that.
Default Endpoint was the last thing I actually hacked (as of now). In WCF 3.x, you always had to add service endpoints either in your app.config or by call to AddServiceEndpoint(). Since you wouldn't host more than two contract interfaces at a time and had to specify explicit endpoints for each, it is almost always waste of time, so in WCF4 it is automatically configured if you didn't provide explicit endpoint.
To achieve Default Endpoints, contract, binding and endpoint address must be provided. Since contract and endpoint can be given at ServiceHost constructors, only binding needs to be automatically guessed. And here is the practical use of Protocol Mapping. It is URIscheme-to-BindingType mapping, and the base addresses in a service host contain URI scheme.
The default Protocol Mappings are not visible in the machine.config in .NET 4.0, but they are filled at ProtocolMappingSection's InitializeDefault method. (You cannot see this overriden method in MSDN API reference - it could be confirmed through our class status pages, or some people like me could smell it because ClientSection also had overriden InitializeDefault implementation like this and hence it lacked the actual config section.)
Standard Endpoints are implemented in accordance with WCF Discovery work. While I don't really like WCF configuration stack, there would be a couple of samples that are based on configuration to run, and I didn't want to get messed just by lack of it while dogfooding.
File-less activation is also what I think nice-to-have feature, but not implemented yet. (Well, and actually whatever I haven't written here aren't yet either.)
Discovery
WCF Discovery is a WS-Discovery implementation, which enables us to dynamically register and dispatch the destination information for specific type of services by announcement by service providers and queries by client consumers. Sadly it is SOAP-based and useless for other bindings.
WCF Discovery needed some tricks and underlying layers that I had to (and need to) work on:
- Standard endpoint support. Both AnnouncementEndpoint and DiscoveryEndpoint are standard endpoints that needed extra work on WCF 4.0 stack done earlier.
- UDP transport. It is so far available only through those standard endpoints (ServiceEndpoint's Binding property). .NET UDP transport implementation as well as ours has some hacky code, for example it repeats sending messages a couple of times so that the recipients will rarely miss it, so I can understand why it's not exposed as part of public API. (Repeating UDP messages won't fit other UDP uses such as sending OSC messages to instruments.)
- Multiple WS-Discovery spec. version support. There are WS-Discovery 1.1, WS-Discovery CD1 (committee draft), and WS-Discovery April 2005. They reside in different namespaces, yet have almost identical set of elements and functionality. Different namespaces means different service contracts, but there are no contract types in WCF Discovery assembly (System.ServiceModel.Discovery.dll). In fact those types exist as "internal" interfaces which are implemented in AnnouncementEndpoint, DiscoveryService or DiscoveryProxy.
- The trickiest part is that the contract type differs when the binding supports request-reply and when the binding supports duplex. I got request-reply style discovery (actually only Find operation) working, but not for duplex discovery yet so far. Actually, this complexity affects all over the API (indirectly).
Routing
Actually our WCF Routing implementation had been there since Mono 2.6 and I have already wrote about it, so I don't write duplicates here.
Routing configuration types are implemented, so at some stage it will be completed when some people (or we) would like to use it in practice.
Other tasks
REST improvements is sort of on our stack, but I have no concrete plan to work on it yet. It also applies to some new features such as receive context. WF4 support too, but it's very different as we don't have WF4 itself. BTW WF4 is made into System.ServiceModel.dll and now it messed me a lot by injecting a lot of our class status pages. As compared to that of 3.5, the number of missings looks quite big, but we don't lack new features that much.
And, while I wrote about 4.0, my primary hacking area is 3.0 stack. I'm likely go back to components that make up WSHttpBinding and further ones once I achieved duplex Discovery work.
