Jesus Rodriguez's WebLog

Tellago & Tellago Studios at Microsoft TechReady

This week Microsoft is hosting the first edition of their annual TechReady conference. Even though TechReady is an internal conference, Microsoft invited us to present a not one but two sessions about some our recent work. We are particularly proud of the fact that one of those sessions is about our SO-Aware service registry. We see this as a recognition to the growing popularity of SO-Aware as the best Agile SOA governance solution in the Microsoft platform.

Well, on Tuesday I had the opportunity to present a session about SO-Aware to a very enthusiastic and knowledgeable Microsoft audience. It’s great to see how, in just a few months, SO-Aware has become a vital component of Microsoft’s Connected Systems stack. As part of the session, we unveiled one of our new products that we will be releasing at the end of the month. I couldn’t be happier about the feedback we received from the Microsoft attendees.

In addition to our SO-Aware session, my colleague and friend Dwight Goins presented a session about patterns for integrating with Oracle Applications using the Windows Server AppFabric. This session is based on a series of projects that we have been collaborating with different Microsoft product teams to improve the interoperability between Microsoft’s technology stack and Oracle applications.

The experience at TechReady was phenomenal. Kudos to Microsoft on organizing a a great event.

Tellago Devlabs: A RESTful API for BizTalk Server Business Rules

Tellago DevLabs keeps growing as the primary example of our commitment to open source! Today, we are very happy to announce the availability of the BizTalk Business Rules Data Service API which extends our existing BizTalk Data Services solution with an OData API for the BizTalk Server Business Rules engine. Tellago’s Vishal Mody led the implementation of this version of the API with some input from other members of our technical staff.

The motivation

The fundamental motivation behind the BRE Data Services API is to expose the capabilities of the BizTalk Server BRE engine in a highly interoperable RESTful service interface so that they can be accessible to applications developed in heterogeneous platforms such as J2EE, dynamic languages or even mobile application development frameworks.

Since its 2004 release, the BizTalk Server Business Rules has become of the unique and most popular technologies in the BizTalk Server ecosystem. Essentially, BizTalk BRE enables the modeling of Boolean expressions in a completely declarative model and stores them in a central repository so that they can be interpreted by other applications. In that sense, BRE is somewhat independent of BizTalk Server given that the business rules stored in BRE can be consumed by any .NET application. However, in the current version of BizTalk Server, developers will have to rely on BizTalk specific assemblies in order to interact with the BRE system. In order to overcome this limitation, we decided to implement a RESTful, OData-based API that exposes the entire BRE subsystems as simple resources accessible via HTTP.

The result

After debating a few options, we decide to rely on the current version of WCF Data Services and the OData protocol to surface the interactions with the BizTalk Server BRE engine. The result of this implementation is a ridiculous simple interface that allows developers to browse the entire BRE system using HTTP GETs based on the OData protocol as well as to execute policies using simple HTTP POSTs.

Here are a few examples extracted from our basic documentation:

The existing version of the API allows you to navigate the entire BRE systems using simple HTTP GETs.

Browsing BRE artifacts

Querying BRE Policies

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Policies

Querying BRE Rules

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Rules

Querying BRE Vocabularies

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Vocabularies

Querying individual BRE resources

Querying a specific Policy

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Policies(‘PolicyName’)

Querying a specific Rule

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Rules(‘RuleName’)

Querying all Rules under a Policy

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Policies('PolicyName')/Rules

Querying all Facts under a Policy

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Policies('PolicyName')/Facts

Querying all Actions for a specific Rule

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Rules('RuleName')/Actions

Querying all Conditions for a specific Rule

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Rules('RuleName')/Actions

Querying a specific Vocabulary

http://<service endpoint>/BREDataServices/BREMananagementService.svc/Vocabularies('VocabName')

Executing a BizTalk Server Business Rule using HTTP

In addition to the enabling querying capabilities, this version of the BRE Data Services API also enables to execute rules by issuing a HTTP POST against a specific URL as specified in the following code:

Request:

POST /<service endpoint>/BREMananagementService.svc/ExecuteRuleAsSvcOperation?FactInstance='%3Cns0:LoanStatus%20xmlns:ns0=%22http://tellago.com%22%3E%3CAge%3E10%3C/Age%3E%3CStatus%3Etrue%3C/Status%3E%3C/ns0:LoanStatus%3E'&%20FactType='TestSchema'&PolicyName='TestPolicy' HTTP/1.1

Content-Type: application/xml

Host: localhost:8080

Content-Length: 0

Connection: Keep-Alive

Response:

HTTP/1.1 200 OK

Server: ASP.NET Development Server/10.0.0.0

Date: Tue, 08 Feb 2011 16:56:50 GMT

X-AspNet-Version: 4.0.30319

DataServiceVersion: 1.0;

Content-Length: 309

Cache-Control: no-cache

Content-Type: application/xml;charset=utf-8

Connection: Close

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<ExecuteRuleAsSvcOperation xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices">&lt;ns0:LoanStatus xmlns:ns0="http://tellago.com"&gt;&lt;Age&gt;10&lt;/Age&gt;&lt;Status&gt;false&lt;/Status&gt;&lt;/ns0:LoanStatus&gt;

</ExecuteRuleAsSvcOperation>

Using this capability now we can build applications that leverage BRE without the need of relying on specific BizTalk assemblies. Specifically, this approach opens the BizTalk BRE capabilities to applications built on heterogeneous platforms such as J2EE, dynamic languages such as Ruby or Python or mobile platforms such as Windows Phone 7 or Android.

I hope you truly enjoy this release of the BizTalk BRE Data Services API. We encourage you to download the bits, give it a try and drive us crazy with your feedback.

Using a service registry that doesn’t suck Part III: Service testing is part of SOA governance

This is the third post of this series intended to highlight some of the principles of modern SOA governance solution. You can read the first two parts here:

• Using a service registry that doesn’t suck part I: UDDI is dead
• Using a service registry that doesn’t suck part II: Dear registry, do you have to be a message broker?

This time I’ve decided to focus on what of the aspects that drives me ABSOLUTELY INSANE about traditional SOA Governance solutions: service testing or I should I say the lack of service testing.

Scenario

SOA infrastructures leverage SOA governance frameworks to model its web services ecosystem. Typically, that ecosystem is based on the services and policies that implement the different functional blocks of various enterprise solutions. As the SOA management arm, the MOST important aspect of a SOA governance framework is to provide accurate and simple to understand information about the runtime behavior of the services available in a given SOA infrastructure. When a SOA governance product fails to enable this ability of understanding the characteristics and behaviors of a service it becomes another archaic data repository in your enterprise infrastructure. Sounds familiar? ;)

Thinking around lines, we can probably agree that modeling rich functional tests is one of the most effective ways to communicate the behavior of a web service. In the era of test driven development (TDD) and continuous delivery, testing (on its different variations) is a key mechanism to help users to understand the functionality of a specific piece of a technology. In the case of SOA governance, functional tests will help developers, architects to effective understand the characteristics of a service, it’s runtime behavior based on the different policies, it’s SLAs and performance profiles among many other key governance aspects.

Arguably, the most important thing about service tests as a SOA governance mechanism is that it provides REAL information about services, policies etc. In that sense, functional service tests are much more effective than static metadata when comes to understand the behavior of a service. Unfortunately, SOA governance products like SOASoftware or HP-Systinet have spent years building products that completely ignore these facts.

The screwed-up traditional solution: “No hablo” service testing

As explained in the previous section, service testing should be seen as one of the fundamental mechanisms of any effective SOA governance strategy. Sadly enough, service testing and SOA governance have evolved on separate paths for the last few years. As a consequence, traditional SOA governance products such as SOASoftware or Systinet DO NOT INCLUDE any support for testing in their current versions. Instead, enterprises need to invest in additional products such as SOAPUI Pro in order to implement any sort of service testing strategy.

The challenge with this approach goes way beyond the hassle of having different product suites for testing and SOA governance. More often than not, organizations that follow this approach end up with separate, unrelated paths for their service testing and SOA governance strategies. This is mostly due to the fact that, based on interoperability limitations, it’s incredibly hard (and expensive) to integrate any sort of testing module into traditional SOA governance products such SOASoftware or HP-Systinet.

Using an analogy, you can think about the SOA governance process as a government agency that is responsible for creating and implementing a series of policies for the internal affairs of a country. Now think about what would happen if that same agency will delegate the monitoring and validation of those internal policies to a foreign country. Sounds crazy? Apparently not crazy enough for products like SOASoftware or HP-Systinet :)

The SO-Aware way

With SO-Aware we are trying to bridge the gap between service testing and SOA governance by bringing the two together in the same lightweight service registry infrastructure. In that sense, service testing has been one of the first class citizens in SO-Aware since its conception. In the current version, developers can model functional tests against a service endpoint and organize those tests into semantically meaningful categories so that they can be followed by other users. The following figures highlight the process of authoring a test on the SO-Aware portal.

After creating a tests, the developers can either execute the test on demand (a la SOAPUI) or schedule it for future execution. SO-Aware will track the execution and results of the different tests and it will enable certain analytics around it as illustrated in the following picture.

That’s great! but I have all these other test tools…..

Even though SO-Aware provides a highly sophisticated service testing infrastructure, we really wanted to empower developers to enable creative testing mechanisms that are the best fit for their SOA solutions. In order to enable that, SO-Aware exposes its entire testing infrastructure using a very simple REST base API that will allow developers to extend SO-Aware with their own testing strategies. Using this API, you can integrate the SO-Aware testing infrastructure with unit testing frameworks like NUnit, build servers like CruiseControl.NET, bug tracking products such as JIRA, among others. A clear example of the simplicity of SO-Aware’s REST API is the fact that we can execute a test by issuing a simple HTTP GET as illustrated in the following figure.

At this stage in the evolution of SOA infrastructures, I believe that investing in a SOA governance strategy that doesn’t include service testing is a recipe for failure. That approach will not only prevent your SOA governance infrastructure from the most effective way to describe the characteristics of a service but it will force your SOA governance and service testing strategies to evolve on separate paths disrupting what should be a keep premise of your SOA governance infrastructure: simplicity.