Archives / 2010 / September
  • 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).

    On the other hand, you have WCF, which is extensible beast for building services among other things. The number of extensibility points that you will find in WCF is extremely high, but the downside is that configuration also becomes extremely complex and a nightmare for most developers that only want to get their services up and running.

    Fortunately, the WCF team has considerably improved the configuration experience in WCF 4.0, making possible to run a service with almost no configuration. The approach that they have taken for this version is to make everything work with no configuration, and give the chance to override what you actually need for a given scenario.

    For instance, a WCF service that uses http as transport behaves a ASMX web service by default (it uses basicHttpBinding with SOAP 1.2, transport security, text encoding and Basic profile 1.1) unless you change that. So, how can you create a new WCF service as you did before with ASMX ?. That’s simple and you need to follow these steps,

    1. Create a new WCF service in Visual Studio


    2. Modify the service and data contract to expose the operations you actually need in the service.


    // NOTE: You can use the "Rename" command on the "Refactor" menu to change the interface name "IService1" in both code and config file together.
    public interface IService1

    string GetData(int value);

    CompositeType GetDataUsingDataContract(CompositeType composite);

    // TODO: Add your service operations here

    // Use a data contract as illustrated in the sample below to add composite types to service operations.
    public class CompositeType
    bool boolValue = true;
    string stringValue = "Hello ";

    public bool BoolValue
    get { return boolValue; }
    set { boolValue = value; }

    public string StringValue
    get { return stringValue; }
    set { stringValue = value; }

    3. Optionally, enable the service metadata page for the service, so any client application can use this to generate the proxies.

    <serviceMetadata httpGetEnabled="true"/>


    4. Optionally, enable the ASP.NET Compatibility mode to use the ASP.NET security context (Otherwise, the service will use the default security settings for the basicHttpBinding). That will require two additional steps, adding the “serviceHostingEnvironment” element in the existing service model configuration.

    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>


    And adding an attribute in the service,

    public class Service1 : IService1

    That’s all you need to implement a new WCF service that will behave as a traditional ASMX webservice. As you can see, no service or binding configurations were required for the service. In addition, the behavior element does not have any name, so it applies to all the services running in the same host.


  • 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. 

    The SO-Aware PowerShell provider, in that sense offers around 40 commands that enables simple management scenarios like registering bindings or services or more complex scenarios that involves testing services or sending alerts when a service is not properly working.  

    This provider can be registered as an snapin in an existing script using the following command,

    $snapin = get-pssnapin  | select-string "SOAwareSnapIn"
    if ($snapin -eq $null)
    Add-PSSnapin "SOAwareSnapIn"

    Once you have registered the snapin, you can start using most of the commands for managing the repository.

    The first and more important command is “Set-SWEndpoint”, which allows you to connect to an existing SO-Aware instance. This command receives the OData service location as first argument, and it looks as follow,

    Set-SWEndpoint -uri http://localhost/SOAware/ServiceRepository.svc


    As next step, you can start managing or querying data from the repository using the rest of the commands. For instance, the following example registers a new binding in the repository only if it was not created already

    function RegisterBinding([string]$name,[string]$type,[string]$xml)
    $binding = GetBinding($name);
    Add-SWBinding -Name $name -BindingType $type -Configuration $xml

    function GetBinding([string]$name)
    $bindings = Get-SWBindings
    foreach($binding in $bindings)
    if($binding.Name -eq $name)
    return $binding

    RegisterBinding "stsBinding" "ws2007HttpBinding" "<binding>
    <security mode='Message'>
    <message clientCredentialType='UserName' establishSecurityContext='false' negotiateServiceCredential='false'/>

    As you can see, this provider brings a powerful toy that administrators in any organization can use to manage services or governance aspects by leveraging their scripting knowledge.