Pablo M. Cibraro (aka Cibrax)

WS-Discovery is not only a mechanism for discovering service endpoint addresses at runtime, but also a way to query for specific service information and metadata. If you look at it from another standpoint, WS-Discovery provides access to a decentralized short-lived service catalog that is available as long as the services are running. It is decentralized because every service expose their own metadata, unless you use a WS-Discovery managed proxy, which act as an intermediary and central location for service discovery. It is short-lived because it is only available when the service is running, and it is not something that clients could use at any time.

As we announced last week, we are shipping a new Visual Studio plugin for generating service proxies as part of the SO-Aware SDK. The functionality is equivalent to what you find today in the “Add Service Reference” command, but the results are much better as you get a proxy that does not require any WCF configuration, and also knows how to resolve bindings and behaviors from the repository.

ASXM web services has been the favorite choice for many developers for building soap web services in .NET during a long time because of its simplicity. With ASMX web services, you get a web service up and running in a matter of seconds, as it does not require any configuration. The only thing you need to do is to build the service implementation and the message contracts (xml serialization classes), and that’s all. However, when you build a system as a black box with most of the configuration hardcoded, and only a few extensibility points in mind, you will probably end up with something that is very easy to deploy and get running, but it can not be customized at all. That’s what an ASMX web service is after all, you don’t have a way easily change the protocol versions, encoders, security or even extend with custom functionality (SOAP extensions are the only entry point for extensibility, which work as message inspectors in WCF).

As Jesus mentioned in this post, SO-Aware provides three interfaces for managing the service repository. An OData API in case you want to integrate third applications with the repository. OData is a pure http API that can be easily consumed in any platform using a simple http client library. The management portal, which is an ASP.NET MVC user interface layered on top of the OData API and probably the one most people will use. And finally, a PowerShell provider that also mounts on top of the OData API to allow administrators to automate management tasks over the repository with scripting. 

WIF is an excellent framework that allows you to develop an STS in just a few minutes if you know exactly what you are doing of course :). In my role as consultant and architect in Tellago, I went through several projects in which some level of customization was required at wire level to accomplish some interoperability between a STS built with WIF and existing federation solutions like ADFS 1.x and OpenSSO.

Configuring a WCF service to use federated authentication in an organization is not something trivial as it requires some good knowledge of the available security settings, and more precisely, how to talk to the existing security token services with the right WCF bindings.

WCF Data Services ships with two built-in query providers, a query provider for Entity Framework that uses the CSL model to infer all the service metadata for the exposed entities and their associations, and another provider, a Reflection Provider that uses .NET reflection over the exposed object model to infer the same metadata.

My colleagues Jesus Rodriguez and Dwight Goins were talking about many of challenges you might find for managing WCF services in the enterprise, and how SO-Aware can help you out in all those aspects. Check it out here.