Agile SOA Governance: SO-Aware and Visual Studio Integration

One of the major limitations of traditional SOA governance platforms is the lack of integration as part of the development process. Tools like HP-Systinet or SOA Software are designed to operate by models on which the architects dictate the governance procedures and policies and the rest of the team members follow along. Consequently, those procedures are frequently rejected by developers and testers given that they can’t incorporate it as part of their daily activities.

Having SOA governance products that don’t integrate into IDEs is just another way to exclude developers and testers from the governance process.

individual%20mandate[1]

With SO-Aware, we are trying to democratize SOA governance and management and make it a natural part of the development process. We accomplished that by providing native integration with Visual Studio 2008-2010 which are the fundamental IDEs developers rely on for building WCF services. We enable that integration in the form of two Visual Studio plugins explained in the following sections.

For WCF Service Developers: SO-Aware Service Explorer

The Service Explorer is the latest addition to the SO-Aware SDK. This explorer helps developers working on WCF services to directly interact with SO-Aware. The main user interface of the explorer lists all WCF services present in the current Visual Studio solution as illustrated in the following figure.

SW_SE1[1]

Publishing a WCF Service to SO-Aware directly from Visual Studio

Using the Services Explorer a WCF developer can publish a service directly to SO-Aware as highlighted in the following figure.

SW-SE2[1]

This is a very common scenario used by development teams to publish different versions of the services as the development process evolves.

Automatically generating WCF configuration

The coolest feature of the WCF Service Explorer is the fact that developers can import the WCF configuration stored in SO-Aware directly into their WCF project. This guarantees the consistency of the configuration across the different service projects.

In order to import the WCF configuration for a specific WCF service, we can select the Associate to SO-Aware section highlighted in the following figure.

SW-SE5[1]

After that we can select the specific WCF service we would like to import the configuration from.

SW-SE3[1]

Now we need to select the configuration file to which we would like to import the configuration as illustrated in the following figure. On this menu, we can select whether we would like to import the SO-Aware simplified configuration or the WCF native configuration as part of your WCF project.

SW-SE4[1]

If we select the native WCF configuration option, the wizard generates the complete system.ServiceModel section as illustrated in the following code.

   1: <?xml version="1.0" encoding="utf-8"?>
   2: <configuration>
   3:   <system.serviceModel>
   4:     <services>
   5:       <service name="Tellago.ServiceModel.Governance.Samples.SimpleService"
   6:             behaviorConfiguration="Throttling_CredentialsBehavior">
   7:         <endpoint address="address" 
   8:                 contract="ISimpleService"
   9:                 binding="ws2007HttpBinding" 
  10:                 bindingConfiguration="MutualCertBinding" />
  11:       </service>
  12:     </services>
  13:     <behaviors>
  14:       <serviceBehaviors>
  15:         <behavior name="Throttling_CredentialsBehavior">
  16:           <serviceThrottling maxConcurrentCalls="150"
  17:                              maxConcurrentSessions="150"
  18:                              maxConcurrentInstances="150" />
  19:           <serviceMetadata httpGetEnabled="true" />
  20:           <serviceDebug includeExceptionDetailInFaults="true" />
  21:           <serviceCredentials>
  22:             <serviceCertificate certinffo />
  23:             <clientCertificate>
  24:               <authentication certificateValidationMode="None" />
  25:             </clientCertificate>
  26:           </serviceCredentials>
  27:         </behavior>
  28:       </serviceBehaviors>
  29:       <endpointBehaviors />
  30:     </behaviors>
  31:     <bindings>
  32:       <ws2007HttpBinding>
  33:         <binding name="MutualCertBinding">
  34:           <security mode="Message">
  35:             <message clientCredentialType="Certificate" 
  36:                      establishSecurityContext="false"
  37:                      algorithmSuite="Basic256"
  38:                      negotiateServiceCredential="false" />
  39:           </security>
  40:         </binding>
  41:       </ws2007HttpBinding>
  42:     </bindings>
  43:   </system.serviceModel>
  44: </configuration>

Alternatively, we can select the simplified SO-Aware configuration and the wizard will generate the configuration containing a reference to the service version stored in SO-Aware. You can read more about how we simplified WCF configuration on this blog post from the SO-Aware product team.

   1: <?xml version="1.0" encoding="utf-8"?>
   2: <configuration>
   3:   <configSections>
   4:     <section name="serviceRepository" 
   5:              type="Tellago.ServiceModel.Governance.
   6:                    ServiceConfiguration.ServiceRepositoryConfigurationSection, 
   7:              Tellago.ServiceModel.Governance.ServiceConfiguration" />
   8:   </configSections>
   9:   <serviceRepository url="&lt;SO-Aware Endpoint>">
  10:     <services>
  11:       <service name="ref:SimpleService(1.0)@dev" type="SampleHost.SampleService"/>
  12:     </services>
  13:   </serviceRepository>
  14: </configuration>

After we generate the configuration we can keep it up to date by periodically upgrading it as illustrated in the following figure.

For WCF client developers: Add Service Reference from SO-Aware

Similarly to the service side, we wanted to make SO-Aware an intrinsic part of the WCF client development experience. In that sense, we extended the traditional WCF Add Service Reference dialog with a new option that allows developers to generate a service reference directly from SO-Aware. The following figure illustrates this concept.

Using this dialog, we can select the specific service version we are trying to consume as highlighted in the following figure.

SW_SR1[1]

After clicking generate, the runtime generates a WCF client configured to resolve the configuration from SO-Aware. In that sense, the client configuration file looks as simple as the following.

SW_SR2[1]

You can think about this technique as “service discovery on steroids”. Behind the covers, we used a WCF channel factory that not only resolves the client endpoint address but its entire configuration (bindings and behaviors) using SO-Aware.

No Comments