Jesus Rodriguez's WebLog

Simplicity and the ability to listen to customers are some of the principles behind SO-Aware and Tellago Studios for that matter. Building sophisticated software that is still simple and intuitive from the user/operator perspective is one of those fundamental missing links in enterprise software.

The ability of incorporating valuable customer feedback into your product quickly is one of those things that everybody says they do but only a handful of companies truly believe on. Having a team that is receptive to valuable/constructive feedback is one aspect that can make a difference between the success and failure of a product.

Looking at our current release, we think SO-Aware is incredibly simpler compared to the rest of the SOA Governance products in the current market. Certainly, you don't need a 200 page manual or an army of consultants to get up and running with SO-Aware. However, based on the feedback of some of SO-Aware's early adopters, we that we could improve our installation experience if you put a little bit more intelligence in the installer. Taking that feedback as a starting point, we decided to take a first stab at simplifying the SO-Aware installation experience.

After a couple of days of work, we launched our new SO-Aware installer and the feedback has been incredibly positive. We managed to simplify the installation experience to 4 STEPS!!!!!!. Let's take a look:

After the initial installation screen, you will the following page that helps you with the installation prerequisites :

After that you can customize the process by selecting which components to install:

At this point you can select the website on which to deploy the SO-Aware portal and service API:

After that you just need to configure the information required to deploy the SO-Aware database:

After that, YOU ARE DONE!!!!!! Seriously, at this point you are completely ready to install SO-Aware:

I hope you find this experience as simple as we do. We really need to thank our customers and partners for providing us with such a valuable feedback. If you have any other ideas about how to improve other aspects of SO-Aware don’t hesitate to email me at jesus dot rodriguez at tellago dot com

Are you interested on the strategies and tools that will help you to manage WCF services? Struggling to keep up with your WCF configuration? Looking for a service registry/repository solution that works seamlessness with WCF? Wondering how to effectively test, monitor, catalog your WCF services?

This Wednesday at 2pm US EST, I will be presenting a webinar (http://www.regonline.com/register/checkin.aspx?EventId=882502) that will cover in detail the concepts, motivation and value proposition behind SO-Aware. The webinar will deep dive into the complete SO-Aware feature set including aspects such as service cataloging, centralized configuration, service testing, dependency modeling, service activity monitoring, OData API, integration with other technologies such as BizTalk Server among many others. I am planning to keep the presentation 100% practical so we are going to spend a lot of time looking at demos and code :)

If you are interested on learning more about SO-Aware and WCF management in general, please register here http://www.regonline.com/register/checkin.aspx?EventId=882502

During the first few weeks after the lunch of SO-Aware we have had a few very interesting sessions with customers. Interestingly enough, our customers seem to have similar questions when comes to evaluating the SO-Aware value proposition. Although the answer to those questions becomes apparent after they see or test the product, I thought I would take a few minutes to summarize some of the answers that hopefully will help to clarify the role SO-Aware can play in your SOA.

If you are evaluating SO-Aware against traditional SOA Governance frameworks you might want to review the Five Reasons Why SO-Aware is Different sheet on our website.

Here are some of the common questions we have been hearing from our partners and customers.

• Is SO-Aware a service registry?
• Can SO-Aware manage J2EE Web Services?
• Does SO-Aware hosts my Web Services?
• Does SO-Aware enables service discovery?
• Does SO-Aware competes with the Windows Server AppFabric?
• How is service testing different with SO-Aware?
• Does SO-Aware integrates with BizTalk Server?

Is SO-Aware a service registry?

Absolutely!!! SO-Awareprovides a very broad functionality set but at its very core is a repository for cataloging services, endpoints and other WCF artifacts such as bindings and behaviors. SO-Awarealso enables the capability of modeling versions of a service as well as dependencies between services.

Can SO-Aware manage J2EE Web Services?

Yes!!!!! SO-Awareprovides a consistent model for managing SOAP and REST services developed on multiple Web Services technology stack such as the ones included with the major J2EE application servers. In addition to the ability of managing services developed on heterogeneous platforms, SO-Awaretruly excels of the management of WCF services by cataloging WCF-specific artifacts such as bindings or behaviors.

Does SO-Aware hosts my Web Services?

No!!!!! SO-Awarehosts only the metadata associated with Web Services and clients and not the services itself. We enable a creative model for exposing the service configuration stored in SO-Awareso that it can be used by the Web Services host itself. Following this model, SO-Awaredoesn't need to act as a message broker and consequently it does not impose any performance or scalability constraints in your SOA.

Does SO-Aware enables service discovery?

Yes!!! In SO-Aware, discovering a service endpoint is as simple as executing an HTTP GET against our REST-OData API. SO-Awarecan not only resolve the endpoint address but also the bindings and behaviors required to interact with the target service.

Does SO-Aware competes with the Windows Server AppFabric?

Not at all!!!! SO-Awareand the Windows Server AppFabric are complementary technologies. Whether the AppFabric provides a sophisticated model for hosting WCF and Workflow Services enabling capabilities such as persistent, tracking and caching; SO-Awarefocuses on centralizing the metadata associated with WCF services which might or might not be hosted in the Windows Server AppFabric. For instance, you can envision scenarios on which a series of Workflow Services hosted in the Windows Server AppFabric resolves their configuration from SO-Aware.

How is service testing different with SO-Aware?

Most, if not all Web Service testing  tool can only test service endpoints configured with the basicHttpBinding. Unfortunately, this couldn't be further from the reality of enterprise SOAs on which that have services configured using various protocols such as WS-* security models or transports such as TCP or MSMQ. Additionally, most web service test stacks are incredibly difficult to integrate into other test or build frameworks use by enterprise applications.

SO-Awareis an ideal platform for modeling and executing web services tests given that it hosts and bindings and behaviors associated to different web services. This makes possible to test services that use arbitrary complex security or transport configurations. Additionally, SO-Awareprovides a model for scheduling the execution of tests and a tracking mechanism to report its details. The most important aspect of our testing engine is the fact that in SO-Awareevery test is a RESTful resource that can be executed using an HTTP GET. This capability makes the integration with other testing or build frameworks completely seamlessness.

Does SO-Aware integrates with BizTalk Server?

Absolutely!!! As part of our SDK you can find a custom resolver that integrates SO-Aware with the BizTalk ESB toolkit. Additionally, we will be releasing more samples that integrate SO-Aware with different components of the BizTalk technology stack such as adapters, business rules, pipelines etc.

The second episode of our interview about SO-Aware for Endpoint TV is now available at http://channel9.msdn.com/shows/Endpoint/endpointtv-Meet-SO-Aware-Part-2/. This part focuses on service testing, monitoring, extensibility and the PowerShell provider. You can also watch the first part of the interview at http://channel9.msdn.com/shows/Endpoint/endpointtv-Meet-SO-Aware-Part-1/. I hope you enjoy and bombard us with your feedback.

A few days ago we had the opportunity to sit down with Microsoft's Technical Evangelist Ron Jacobs to record two Channel9's Endpoint TV episodes on which we discuss the architecture and capabilities of SO-Aware(our WCF Registry). The episodes illustrate different capabilities of SO-Aware such as configuration management, service testing, service activity monitoring, dependencies, OData API, among many others.

The first one of those episodes is now available on the Endpoint TV website. I hope you enjoy watching this interview as much as we did recording. Don't forget to send us some feedback.

In the last few days, various of our customers and partners have been interested on the capabilities of SO-Aware to integrate with the different technologies of the Windows Azure platform. This post will illustrate how to use SO-Aware to centralize the configuration of WCF services that interact with the Windows Azure platform AppFabric.

The Windows Azure platform AppFabric is a key component of Microsoft's cloud computing platform. In a nutshell, the AppFabric includes a Service Bus for connectivity across network and organizational boundaries, and Access Control for federated authorization as a service. The interaction with the Service Bus and the Access Control Service is abstracted through elements of the WCF programming model such as bindings and behaviors . Similarly to other protocols, developers need to familiar with the configuration of those bindings and behaviors in order to successfully interact with the Azure AppFabric. This task can be drastically simplified if developers could reuse an existing configuration stored in a centralized location.

SO-Aware (Tellago Studios' WCF Registry) enables developer to centralize the configuration of the Windows Azure AppFabric bindings and behaviors using the same model followed by other WCF artifacts. For instance, the following figure illustrates the default configuration of the netTcpRelayBinding using SO-Aware.

In addition to bindings, we can use SO-Aware to store the WCF behaviors required to interact with the Windows Azure platform AppFabric. The following figure illustrates the use of SO-Aware to configure an instance of the shared credentials behavior required by the Azure Access Control Service.

Let's assume we would like to use the aforementioned Azure bindings and behaviors with the following WCF service.

   1: [ServiceContract]

   2:    public interface ISampleService

   3:    {

   4:        [OperationContract]

   5:        int Add(int param1, int param2);

   6:    }

   7:  

   8: public class SampleService : ISampleService

   9:    {

  10:        public int Add(int param1, int param2)

  11:        {

  12:            return param1 + param2;

  13:        }

  14:    }

We can instruct the service to resolve its configuration from SO-Aware using the following code.

   1: <serviceRepository url="http://localhost/SOAwarePortal/ServiceRepository.svc">

   2:     <services>

   3:         <service name="ref:SampleMathService(1.0)@dev"

   4:           type="Tellago.ServiceModel.Governance.AzureSamples.SampleService, 

   5:                 SampleService"/>

   6:     </services>

   7: </serviceRepository>

Using the SO-Aware portal, we can configure the service to interact with the Azure Service Bus as shown in the following figure.

At this point, our sample WCF service is completely configured to use the Azure platform AppFabric. The following client interacts with the service using the Azure Service Bus.

   1: private static void Test()

   2: {

   3:   SampleServiceClient service= new SampleServiceClient();

   4:   int result= service.Add(11,11);

   5: }

Using the following configuration.

   1: <system.serviceModel>

   2:         <client>

   3:             <endpoint address="sb://tellago-samples.servicebus.windows.net/"

   4:                       binding="netTcpRelayBinding"

   5:                       behaviorConfiguration="sharedSecretClientCredentials" 

   6:                       contract="ISampleService"

   7:                       name="AzureBinding_ISampleService"/>

   8:         </client>

   9:  

  10:         <behaviors>

  11:             <endpointBehaviors>

  12:                 <behavior name="sharedSecretClientCredentials">

  13:                   <transportClientEndpointBehavior credentialType="SharedSecret">

  14:                         <clientCredentials>

  15:                             <sharedSecret issuerName="owner" 

  16:                                issuerSecret="Issuet Secret"/>

  17:                         </clientCredentials>

  18:                   </transportClientEndpointBehavior>

  19:                 </behavior>

  20:             </endpointBehaviors>

  21:         </behaviors>

  22:     </system.serviceModel>

As you can see, by centralizing the WCF configuration, the use of SO-Aware can drastically simplify to the adoption path for the Windows Azure platform AppFabric in the enterprise.

In previous posts I've described how we can use SO-Aware to centralize the configuration of WCF services avoiding the need of maintaining complex configuration files across services and clients. The mechanism is enabled by a custom WCF service host which downloads the configuration from SO-Aware's OData feed and reconfigures the target WCF service

The current version of SO-Aware enables a couple of models for centralizing and simplifying WCF configuration: service-centric and binding/behavior-centric. Let's explore both model using a sample WCF service configured with the ws2007HttpBinding and the mutual certificates security profile. To enable this scenario, the binding configuration should be stored in SO-Aware as shown in the following figure.

Similarly, the behavior used to configure the certificate credentials can also be configured in SO-Aware as illustrated in the following figure.

Our sample service is configured in SO-Aware using the bindings and behaviors explained above. The highlighted sections in the following two figures illustrate this process.

At this point, we can reuse SO-Aware’s configuration in our sample WCF service. The current version of SO-Aware enables two fundamental models for accomplishing that: service-centric or binding/behavior centric.

Service-centric

On this model the entire service configuration will be driven by SO-Aware. This entails service and endpoint configurations including bindings and behaviors. We can enable this model by indicating the service version to be configured using the name attribute of the service configuration section as illustrated in highlighted section of the the following code.

   1: <serviceRepository 
                  url="http://localhost:9999/SOAwarePortal/ServiceRepository.svc">

   2:     <services>

   3:        <service name="ref:CRMSOAPService(1.0)@dev" 

   4:                 type="Tellago.ServiceModel.Governance.Samples.CRMSOAPService, 

   5:                     Tellago.ServiceModel.Governance.Samples.SOAPServices"/>

   6:     </services>

   7: </serviceRepository>

Binding/Behavior-centric

This model represents an alternative to the service-centric model on which we can configure the specific bindings and behaviors that should be configured from SO-Aware. The following code illustrate that model.

   1: <serviceRepository 

   2:      url="http://localhost:9999/SOAwarePortal/ServiceRepository.svc">

   3:     <services>

   4:       <service name="Tellago.ServiceModel.Governance.Samples.CRMSOAPService"

   5:   behaviorConfiguration="ref:ServiceCredentialsBehavior">

   6:  

   7:          <endpoint binding="ws2007HttpBinding" 

   8:            bindingConfiguration="ref:MutualCertBinding"

   9:            contract="Tellago.ServiceModel.Governance.Samples.ICRMService" >

  10:          </endpoint>

  11:       </service>

  12:     </services>

  13: </serviceRepository>

Whether the service-centric models definitely offers a more transparent model for simplifying WCF configuration, the binding-behavior-centric model allows the developer to use specific bindings or behaviors already deployed in SO-Aware’s repository.

As always, remember you can download the express edition of SO-Aware at http://www.tellagostudios.com/download

Service testing is one of the fundamental components of SO-Aware (Tellago Studios’ WCF Registry). In its current version, SO-Aware enables modeling tests against WCF services as well as scheduling their periodic execution. With so many Web Service testing tools in the market, some of you may be wondering why we decided to create a new one and, more importantly, how is SO-Aware different from other offers in the market.

As part of our work on various large WCF implementations, we use a variety of web service test tools and we seem to always run into the same set of issues. With SO-Aware, we have attempted to address some of those challenges using a very simple and yet highly scalable model. If you are planning on establishing a testing strategy for your WCF services, you might be considering the following:

· I want to know which services I am testing

· I want to test services that use WS-* based capabilities such as security, trust, etc

· I want to integrate my Web Service tests into other test frameworks and tools

· I want to be able to schedule and track the periodic execution of Web Service tests

· I want my architects, developers and QA staff to collaborate in the design and execution of the Web Service tests.

· I want to script highly customized tests that simulate specific business logic

The rest of this blog post will examine in detail each one of the previous challenges and explain how they can be addressed using SO-Aware.

Knowing Which Services to Test

When you are using some of the Web Services testing tools in the marketplace, it is your responsibility to figure out the details required to invoke the target service. In that sense, you need to understand where the service is located, understand its contract, figure out the message exchange patterns and the message payload for its different operations, etc. While this process is sufficient for a single service, it couldn't be more inefficient for enterprise solutions that involve hundreds of Web Services.

Following the previous argument, it is very easy to envision how a Web Service testing tool can benefit from a service repository that contains the details of the different Web Services in the enterprise as well as the details required to invoke them. That way, the tests are created, cataloged and stored together with the services in the repository and can be used to determine the correct functioning of the Web Service.

The SO-Aware™ Solution

In SO-Aware, tests are directly associated with service versions stored in the service catalog. Similarly, WCF bindings, behaviors and other artifacts required to test the service operation are kept in SO-Aware and can be reused across multiple tests. This centralized model provides the tester with a complete picture of the characteristics of the target service as well as their dependencies.

Testing Beyond basicHttpBinding

WCF is arguably the most sophisticated Web Services technology in the marketplace. Consequently, it is very difficult, if not impossible, for Web Service testing tools to interact with WCF services that implement features or WS-* protocols that go beyond simple SOAP over HTTP. For instance, it is almost impossible for the majority of Web Services test tools in the current market to test WCF services that use WS-Trust as a brokered security protocol.

The SO-Aware™ Solution

Given that SO-Aware has been entirely built on WCF, it includes the necessary infrastructure to test highly sophisticated services. Obviously, SO-Aware excels in the testing of WCF services but it is equally effective testing services developed on any Web Services technology stacks. Its WCF foundation makes SO-Aware better equipped to interoperate complex Web Services than any other testing technology in the market.

Integrating with Other Test Frameworks

Web Service testing is just a small component of the testing strategy in the enterprise. Ideally, organizations would like to integrate this type of testing into more complex test cases developed using existing frameworks such as MSTest, NUnit, JUNit, etc. However, this simple need is almost impossible to achieve with existing Web Services testing tools without undergoing a ridiculous development effort. Additionally, this integration looks different depending of the testing framework we are using.

The SO-Aware™ Solution

SO-Aware is a service registry completely built based on the principles of REST and OData. In a nutshell, every single element of SO-Aware can be accessed or modified using simple HTTP and OData. This principles also applies to the testing repository in which every test can be executed using a simple HTTP GET as illustrated in the following figure.

The RESTful nature of SO-Aware tests makes it completely seamless to integrate into other testing frameworks. For instance, the integration between SO-Aware and Team Foundation Server(TFS) can be easily accomplished by configuring TFS to execute the correct HTTP request to query or execute tests.

Record Test Results

Almost without exception, the majority of Web Services test tools in the current market can do a decent job executing isolated tests against a service but they offer next to zero capabilities in terms of tracking and analyzing the test results. This is partially due to the fact that these tools focus almost exclusively on on-demand tests in which a user is starting the test and waiting for the results. The need to schedule the execution of tests on a regular basis is a key requirement of effective testing in a SOA environment.

The SO-Aware™ Solution

In addition to the traditional "on-demand" testing, SO-Aware offers the capability of scheduling tests so that they can be executed periodically. Additionally, SO-Aware tracks the results of the executed tests and offers a series of analytics based on it as illustrated in the following figure.

Testing and Monitoring

Web Services testing and monitoring are two capabilities that can be combined to enable complete visibility into the runtime behavior or a service. Unfortunately, the current market is lacking of tools that combine both capabilities with the service metadata enabled by a service registry. If you want to enable both testing and monitoring in your SOA, you are most likely looking at a decent development undertaking to cohesively integrate the web service monitoring and testing suites you are using.

The SO-Aware™ Solution

SO-Aware combines the service registry, monitoring and testing capabilities into a single product which enables the effective monitoring of the tests scheduled against specific Web Services. Using this model, the operations team can not only monitor the execution of the tests but also determine how those tests are impacting the performance of the Web Service.

Collaborative Testing

Quite often, Web Services testing is seen as a task of the QA or the operations staff. However, this process excludes developers or architects who can provide a lot of insight into the correct functioning of the service.

The SO-Aware™ Solution

By using a centralized model, SO-Aware enables a collaborative testing approach in which developers, architects and the QA staff can work together in the design, modeling and execution of the tests. Using the SO-Aware portal, developers can design the initial version of tests which can be later modified and scheduled for execution by other members of project team. By leveraging the test tracking capabilities, the team can get insight into the execution of the tests we well as detect possible defects on the SOA infrastructure.

The Power of Scripting Tests

When comes to testing, it is very presumptuous to assume that one tool or framework can fit all your test scenarios. More often than not, big SOA implementations require very customized testing procedures that leverage internal tools or processes. Scripting languages are an ideal solution to build customize tests that orchestrate different systems or tests designed with various test tools. Unfortunately, most, if not all, Web Services test tools in the current market do not enable seamless integration with scripting languages that will facilitate the development of more specialized tests.

The SO-Aware™ Solution

SO-Aware includes two fundamental artifacts that enable the development and execution of highly complex and customized tests: A PowerShell provider and a RESTful API. In its current version, SO-Aware includes a complete provider for Windows PowerShell that enables almost the complete set of functionalities available with the portal interface from a scripting environment. Using this mechanism, testers can script highly sophisticated tests entirely from the PowerShell environment.

In addition to the PowerShell provider, SO-Aware also includes a highly interoperable RESTful API based on the OData protocol. The capabilities of the testing subsystem are completely available through this API which enables its interaction with other scripting languages such as Python or Ruby by using simple HTTP commands.

Where Are We?

We believe SO-Aware presents a unique value proposition to Web Service testing by enabling a WCF-based infrastructure that facilitates the testing of arbitrarily complex Web Services which are impossible to test using other products in the market. SO-Aware's infrastructure combines a highly scalable and interoperable RESTful API, a unique model to expose tests as RESTful resources, a sophisticated model to schedule the execution of tests and a robust tracking system to monitor the correct functioning of the tests.

For more information check our this video on our website and go ahead and download the Express version of SO-Aware . Don't forget to send us some feedback.

My colleague Pablo Cibraro has written a very interesting post about the WCF configuration capabilities of SO-Aware (our WCF registry)