Contents tagged with TellagoStudios

  • Telesharp – An Application Repository for .NET applications

    A year ago, we released SO-Aware as our first product in Tellago Studios. SO-Aware represented a new way to manage web services and all the related artifacts like configuration, tests or monitoring data in the Microsoft stack. It was based on the idea of using a lightweight SOA governance approach with a central repository exposed through RESTful services.

    Read more...

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

    Read more...

  • Visualizing Service Dependencies in SO-Aware

    A common requirement that we received from some customers while we were in the early design stages of SO-Aware was the ability of tracking static dependencies between services. For instance, Service A calls Service B and Service B calls Service X. This feature is not only useful for documentation but also for helping administrators to determine which services are going to affected with a change in one of the existing service. (In that example, a change in the service X would affect Service A and B).

    Read more...

  • WCF configuration simplification with SO-Aware

    As I discussed in the previous post, everything in SO-Aware is exposed as resources via OData. You can simply take a look at this by browsing at the main feed of the service repository.

    This means that we can import a new service into the repository and configure it with the correct bindings and behaviors a simple set of http requests. In SO-Aware you will able to find three different kind of services, SOAP services, REST services, and OData services. And although an OData service is in essence a REST service, we made a distinction for the simple fact that an OData service exposes metadata that we can use to import the service automatically into the repository. We are doing the same thing with a SOAP service, as you don’t need to manually create the different endpoints, contracts or operations that a SOAP service exposes. All that information is automatically inferred from the service WSDL, so when you specify either the WSDL url or the WSDL content (the whole xml chunk), the repository parses the WSDL, and decomposes the WSDL into different entities that are finally associated to the service. Therefore, importing a new SOAP or OData service into the repository is quite trivial, you only need to provide the metadata url. REST services on the other hand requires some more work, as all the resources or http operations with the corresponding media types must be created manually and imported in the repository using either the SO-Aware portal or the OData api (We have plans to import this automatically from the help feed in the WCF 4.0 REST services or the WCF services that use the Help attribute in the REST Starter kit).

    It’s always very useful for the enterprise to have a catalog of services and available operations into the repository for documentation purposes, and also for testing and monitoring.

    The following code illustrates how a new SOAP service can be imported into the repository using the OData api (The example uses a WCF Data service generated proxy).

    Importing a service from an existing WSDL

       1: var repository = new ResourceRepositoryContext(RepositoryUri);
       2:  
       3: var service = new Service
       4: {
       5:   Name = "Customers",
       6:   Namespace = "http://soaware/demo",
       7:   Style = "SOAP"
       8: };
       9:  
      10: repository.AddToServices(service);
      11:  
      12: var serviceDescription = new SoapDescription
      13: {
      14:   MetadataURI = "http://localhost:8080/?wsdl"
      15: };

    Associate the WSDL to an specific service version

       1: var serviceVersion = new ServiceVersion
       2: {
       3:   MajorVersion = 1,
       4:   MinorVersion = 0,
       5: };
       6:  
       7: repository.AddToServiceVersions(serviceVersion);
       8:  
       9: repository.SetLink(serviceVersion, "Soap", serviceDescription);
      10: repository.SetLink(serviceVersion, "Service", service);

     

    The code above is creating a new version (1.0) for the service, and associating the WSDL and all the inferred entities (endpoint, contracts, operations and schemas) to that version.

    Associate a WCF binding to the imported endpoints

       1: var endpoint = serviceDescription.Endpoints.First();
       2: var binding = repository.Bindings.Where(b => b.Name == "kerberos").First();
       3:  
       4: repository.SetLink(endpoint, "Binding", binding);
       5:  
       6: repository.SaveChanges(SaveChangesOptions.Batch);

     

    Configuring the service host

    As you can see, we are getting an existing binding “kerberos” from the repository for using message security with kerberos (SO-Aware already ships with a bundle of pre-configured bindings for supporting different scenarios), and associating that binding to the imported endpoint. Therefore, next time you restart the service host for that service, it will start using the selected binding for that endpoint.

    Ok, so far we have imported a service into the repository. As next step, something you can do is to configure and specific service host that we provide for automatically get the service configuration from the repository (in the example above, the new endpoint configuration with the “kerberos” binding)

    In order to do that, you need to use a custom service host “Tellago.ServiceModel.Governance.ConfigurableServiceHost” or the custom service host factory “Tellago.ServiceModel.Governance.ConfigurableServiceHostFactory” in you case you are hosting WCF in IIS.

       1: ServiceHost host = new ConfigurableServiceHost(typeof(Customers),
       2: new Uri("http://localhost:8080"));
       3:  
       4: host.Open();

     

    This “ConfigurableServiceHost” uses an specific configuration section to know how to map the service type “Customers” to the service version in the repository.

       1: <serviceRepository url="http://localhost/SoAware/ServiceRepository.svc">
       2:   <services>
       3:     <service name="ref:Customers(1.0)" type="CustomerService.Customers, CustomerService"/>
       4:   </services>
       5: </serviceRepository>

     

    The prefix “ref:” tells the host to look for that service into the repository. This is when you want to download the complete service configuration and all the associated endpoints from the repository. However, this service host also supports another syntax in the configuration section for downloading only specific bindings or behaviors.

       1: <serviceRepository url="http://localhost/SoAware/ServiceRepository.svc">
       2:   <services>
       3:     <service name="CustomerService.Customers">
       4:       <endpoint name="Customers_WindowsAuthentication" binding="ws2007HttpBinding" bindingConfiguration="ref:kerberos"  contract="CustomerService.ICustomers"/>
       5:       <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
       6:     </service>
       7:   </services>
       8:  </services>
       9: </serviceRepository>

     

    The example above only tells the configurable host to download the “kerberos” binding from the repository, and not the rest of the service configuration.

    Configuring the client application

    The configuration on the client side is also very trivial. We provide a class for automatically configuring a proxy, “Tellago.ServiceModel.Governance.ServiceConfiguration.ConfigurableProxyFactory”, or a class “Tellago.ServiceModel.Governance.ServiceConfiguration.ConfigurationResolver” for resolving individual WCF configuration objects like endpoints, bindings or behaviors that you want to inject in your existing proxy.

    The following code illustrates how the ConfigurableProxyFactory can be used to invoke the service without having a single line of configuration.

       1: class Program
       2: {
       3:   static Uri RepositoryUri = new Uri("http://localhost/SOAware/ServiceRepository.svc");
       4:  
       5:   static void Main(string[] args)
       6:   {
       7:     var factory = new ConfigurableProxyFactory<ICustomers>(RepositoryUri, "Customers(1.0)");
       8:     var proxy = factory.CreateProxy();
       9:  
      10:     try
      11:     {
      12:       var customer = proxy.GetCustomer(1);
      13:  
      14:       Console.WriteLine("Customer received {0}", customer.FistName);
      15:     }
      16:     finally
      17:     {
      18:       factory.Dispose();
      19:     }
      20:   }
      21: }

    As can see, everything was inferred from the configuration in the repository, even the endpoint address and the configured binding.

    Download the sample code from this location.

    Read more...

  • SO-Aware is here. A RESTful service repository

    I am very proud to announce today the release of our product in Tellago Studios, SO-Aware, a RESTful service repository based on OData.  The main difference between SO-Aware and other existing products is that everything is exposed as resources via OData feeds that can be retrieved or manipulated with standard http verbs like POST, PUT, GET or DELETE (All this is implemented with WCF data services).

    Read more...