Archives
-
The swiss knife for managing X509 certificates in Windows
Raffaele Rialdi, a security MVP from Italy, has just released a very cool tool to manage X509 certificates in windows. X509 certificates has always represent a pain for most developers, as they are hard to deploy or configure correctly with the right permissions. A tool like this is absolutely need when working with frameworks like WCF or WIF that makes an extensive use of certificates.
-
Exposing additional service metadata with WS-Discovery in WCF 4.0
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.
-
SWUtil - A new tool for generating service proxies from the SO-Aware repository.
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.
-
Why ASMX web services are not an excuse anymore with WCF 4.0
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).
-
Managing the SO-Aware Repository with PowerShell
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.