BizTalk Server and Sentinet: Protocol Mediation REST to SOAP

아티클
1/17/2024

Introduction

A team of Microsoft consultants developed Managed Services Engine (MSE) as an open source project a few years ago. End of December 2009 it was the final CTP release. MSE was meant to facilitate service virtualization to support versioning, abstraction, management, routing, and run-time policy enforcement for Services. It used a service repository to provide easier and faster deployment of services, change management, and reuse.

Service Virtualization

The power of this concept in its non-intrusive nature. Services that are “virtualized” (or exposed) to ultimate consumer applications through brokers (or network agents). Business Services are fully decoupled from consumer applications. Business Services can be implemented and deployed using unified security and deployment models, while being exposed using ultimate requirements imposed on consumer applications. Changes in business services will not affect consumer applications, and visa-versa, changes in consumer-facing requirements will not affect currently deployed services. All the common SOA infrastructural challenges are addressed by the virtual services hosted in the broker application that takes full responsibility to handle these challenges on behalf of Business Services.

MSE was a promising product, yet it has never been released as a complete, mature product and ultimately was discontinued. However there is a product called Sentinet from Nevatech, which implements all of the MSE concept (and many more) in its product. It’s the only product on the market in its space that is entirely built on the Microsoft platform, which takes full advantage of Microsoft products and technologies, fully integrates with, and extends Microsoft SOA offerings including BizTalk Server and Windows Azure cloud platform. Architecturally, it consists of

SOA Repository, a SQL Server or SQL Azure database that stores and manages all design-time and run-time SOA solutions’ configurations, artifacts and metadata.
Management Services Application which is an API of secure and interoperable Web Services.
Sentinet Nodes, which are specialized brokers that mediate communication between consumer and business services applications.
And a Sentinet Console, a Silverlight-based applications that provides secure and remote access to all manageability aspects of SOA solutions by Sentinet administrators and developers.

The product is a unified on-premises and Windows Azure Cloud infrastructure. The same product and all its individual components can be deployed either on-premises or in Windows Azure, and it can manage Business Services deployed either on-premises or in the cloud.

Sentinet services virtualization platform is built on the latest .NET Framework and related technologies like WCF and WIF. The repository supports MS SQL Server. It has matured over the years and currently is in version 3.4. Basically you can view Sentinet as a replacement of the MSE, and even as an evolution of MSE into advanced and modern SOA and APIs Management Platform. Sentinet is all built on top of the latest Microsoft technologies stack (see diagram below).

Sentinet product installation and configuration

A fully functional evaluation copy of Sentinet can be downloaded from their site. Like any product the installation depends on a couple of prerequisites. For Sentinet this means a Windows Server OS (2008/2012), or client like Windows 7 or 8, a .NET runtime, SQL Server and a few OS specific components like IIS and WAS. The prerequisites are outlined in the installation documentation that is provided with the product download.

Depending on the OS architecture you install the 32- or 64 bit msi. The installation depends on your deployment scenario. For a development and/or test environment you can do a single computer deployment. In that case the Sentinet Node(s), Sentinet Repository Web Services Application and its Repository database are all deployed on individual computer system.

The single machine deployment will be used for this article. For a high available production environment the nodes and repositories are distributed over multiple machines. The installation guide will provide guidance regarding the deployment you will follow.

Configuration of Sentinet means configuring the repository using the repository wizard: database, application, certificate, reporting, mail server and administrator account(s), and configuring the nodes.

The Sentinet node(s) are configured through IIS.

A Sentinet Node is a kind of special Web Application hosted on the IIS Server and depending on your requirements you can create one or more independent nodes within a single IIS Server Instance. Each Node serves as a container (or hosting application) for one or more virtual services that can be remotely and dynamically created on the Node. Each virtual service will act as a kind of proxy, or façade service for your real “business” web services. The Nodes are created and configured from the Microsoft IIS Manager Administrative snap-in. The Quick Start tutorial details how to add and configure regular IIS Server application as a Sentinet Node application.

The installation guide will provide guidance for configuration and is concise and thorough. So to conclude with installation guide in hand the deployment of Sentinet can’t go wrong.

Protocol Mediation Scenario

Sentinet product provides capabilities through its product regarding API/SOA Management. API management products in general have the following characteristics:

Automate and control connections between an API and the applications that use it.
Ensure consistency between multiple API implementations and versions.
Monitor traffic from individual apps.
Provide memory management and caching mechanisms to improve application performance.
Protect the API from misuse by wrapping it in security procedures and policies.

To discuss the Sentinet product I will do a complete walk-through with a basic example demonstrating a couple of product features like protocol mediation, routing, and monitoring. The example will demonstrate the product API management characteristics.

In the basic scenario I will poll data through a BizTalk application from a database containing running data from races I ran in the past like Berlin Marathon, CPC Half Marathon, 16 and 15K races. I will place a Sentinet Node in front of a BizTalk hosted service to provide access to my BizTalk application. The BizTalk application has as a hosted service (i.e. schema’s exposed as a WCF service), which is a SOAP service configured with basicHttpBinding. Through a virtual service I like to expose a RESTful endpoint, which will route the message to the BizTalk hosted SOAP Service. Below you will find an overview of the example.

The following steps described the setup of the example:

Creation of request/response schema’s for the BizTalk hosted service;
Creation of binding for the send port communicating with SQL Server database;
Developing mappings;
Creation of a virtual service through the Sentinet console;
Testing the solution.

Scope of the example

The emphasis of this example is on steps four and five. The first three steps are basic steps that every BizTalk professional is pretty familiar with. These steps will be described from a high level perspective.

Creation of request/response schema’s for the BizTalk hosted service

The first step of this example is pretty straightforward. Create a new BizTalk project in Visual Studio, click Add Schema and create a schema for request and response messages. This schema can be used to be exposed through a WCF service, which is hosted in BizTalk (i.e. in IIS/receive location). To expose schema’s as a WCF Service the BizTalk WCF Service Publishing Wizard can be used.

Creation of binding for the send port communicating with SQL Server database

The next step is to setup communication with the backend, the SQL Server database. By using the metadata browser (Consume Adapter Service) built into Visual Studio. NET you can configure access to table containing the data, for a good example see WCF-SQL Adapter Table Operations. After the configuration you will have a few schema’s and a single binding file added to our associated BizTalk project in Visual Studio.NET. The binding file can be used to set up a send port after deploying your schema’s and mappings.

Developing the mappings

The final step before deploying the BizTalk project to the BizTalk runtime is to map the incoming request message to SQL table operation message (Select) and the response from SQL Server to the outgoing response message.

Creation of a virtual service through the Sentinet console

The creation of a virtual service consists of the following steps:

Register the BizTalk hosted service
Create the virtual service
Assign the hosting environment
Specify the endpoint address
Map the REST operation to the SOAP request
Configure the access to the endpoint

The first step is to create a virtual service within Sentinet to be placed under the node. The virtual service will act as a proxy for my WCF runner service. To do this you need to register your service in the Repository. The Repository is one of the four major components of Sentinet (others are the Nodes, management services and administration console). The added value of the Repository is that it can store and manage for you your services metadata, identities, documentation and other artifacts associated with your services treated as your software “assets”. The repository can be managed using the administration console.

You log in the administration console, which is a Silverlight based RIA application. Subsequently you select the Repository root element in the Repository view panel. Right-click on the Repository root element and select the Add->Service->SOAP menu option (you can also register your services in the different Repository sub-folders that you can create to better represent more complex hierarchy of your SOA projects). Specify your service metadata URL into the WSDL from URL field and click Next. The Wizard will download the service metadata and when the download is complete the Web Service structure tree will be displayed. Click Finish and the service will be imported into the Repository in a Version 1 state.

The first step is completed, and the service is registered. Now you can create (design) the virtual service. Click Add->Virtual Service->SOAP menu option. Change the service name to YourService and click Save. An empty virtual service is created and at this point the service is not virtualizing any Web Service. A virtualization structure is required to be designed. So you click the Design tab to show the Virtual Service Design surface. Subsequently you click modify to start designing. To virtualize the Version 1 of your service you drag-and-drop the Version 1 tree element on to the IVirtualInterface surface.

Note: The beauty of this product is that you can virtualize multiple business services behind a single virtual service. Your Business services can be deployed at different locations, with different communication and security requirements, and yet virtualized through a single aggregate virtual service. Moreover, you have fine-grained control over the virtual service structure where you might prefer to virtualize only some of the business services’ operations.

Now a hosting environment for the Virtual Service needs to be assigned (you need to define where Virtual Service will be hosted). Virtual Services can be hosted on one or more Sentinet Nodes through one or more endpoints. Each Virtual Service Inbound endpoint can be configured with its own transport and policies. To host your service on the New Node select the New Node in the Repository tree and drag-and-drop it on to the “Inbound Endpoints” surface.

You now need to specify the endpoint addresses, where you have to add a policy. The Add Policy Wizard will display a hierarchical structure of registered shared policy templates. You can select the WebHttpBinding (Default) policy and click Finish. You will now have your endpoint configured like below.

By default virtual REST operations are configured with one-to-one mapping to virtualized SOAP operations. REST operations are expected to post XML requests in HTTP message body so that they will be passed-through to SOAP operations after adding SOAP envelope and security SOAP headers if SOAP service requires them (see screenshot above). In my scenario I will change my REST service operation to send request via HTTP GET method and to send actual message data with HTTP GET query parameters:

/GetResultsByRaceNameRunnerNumber?r={race}&n={number}

I will uncheck pass through, click the Generate Template Message and change the content like below:

Next step is to map the REST operations of the virtual service to SOAP operations of the WCF Service. To perform this mapping I will have to modify the GETRESULTSBYRACENAMEARUNNERNUMBER virtual operation of my REST service that virtualizes the same operation of the WCF SOAP Service.

With this change I have instructed REST operation to expect /GetResultsByRaceNameRunnerNumber?r={race}&n={number} HTTP GET request, where {race} and {number} are the variables name whose values will be replaced in the outgoing SOAP message exactly where the same variables names are used. Sentinet helps to generate XML representation of expected SOAP message in a form of template message. Here is an example how mapping will be happening at run time.

Now the access control to the virtual service needs to be defined. For simplicity in this sample the access to the service will be for anyone. The Everyone Access Rule is available with the default product installation. The Access Control is driven by the Access Rules located under the Access Rules folder in the Repository tree. You can expand the Access Rule folder in the Repository view. Drag-and-drop the Everyone Access Rule on the root of the Virtual Service tree and will be assigned to your service with the Permit permission. The final step for the virtual service is to promote it to an Active state.

Test the protocol mediation solution

Now that the service is up I can test it. I will use Fiddler to test the REST endpoint. In Sentinet I select the virtual service version 1 and I can look up the endpoint address.

In Fiddler you can select composer and specify the endpoint address.

Click execute to see what will happen.

As you can examine the picture above a response is returned with the runner data.

Now I will switch over to the monitoring side. Sentinet enables you to monitor traffic coming in and out, performance metrics, activity metrics (successful calls, unsuccessful calls, message sizes, total messages, and so on (see Monitoring Sentinet). In this scenario I am interested in messages coming in, subsequently being transformed in a SOAP call to the database and the response messages.

First I will go back to the Sentinet Administrative console. Select Version 1 of the REST Running Service in the Repository tree and click the Monitoring tab. The first thing you will see if you do this is the real-time monitoring data at 5 seconds intervals being displayed.

The tab called Logs is the next one I will click to see what has been logged.

A list of transactions that occurred during the time interval observed by the graph will be displayed (you can expand the Search panel to search for transactions at a specified time interval). When you click the [+] located next to each transaction it will expand the selected transaction.

Above you can see a very detailed view of how the transaction was transmitted from the client application (Fiddler) to my REST endpoint. If I double click the RESTRunningService than the details of that part of the transaction will be shown.

To be able to see the actual payload being sent of the wire and back I will have to configure the recording. By default this is not enabled and only the transaction statistics are collected. By clicking modify and moving the Monitoring Profile slider bar to Full I can monitor more than just the statistics.

The Sentinet Node will get the new specified monitoring settings with its next heartbeat. When I send more message through Fiddler the payloads will now be recorded. If I go back to monitoring and select Logs I can select one of the recent messages and select the RunnerResultsSearchService (SOAP).

Now I can inspect the actual payload of what comes in and goes out. To me this is an amazing feature. Enabling monitoring at a pretty granular level, seeing the format of messages going back and forth in just one simple interface feature of the Sentinet Administration console.

Sentinet offers more than just the demonstrated features in this article. The other out-of the box features are:

Wrap up

As you have been able to read through this article working with Sentinent is all about configuration. To provide access to your data only involves generating services, configure/design a virtual service for your end users to consume. The benefits of using Sentinent and concept of service virtualization in this concept (example) are:

Simplifying the authorization and authentication by delegating it to the virtual service (see also Sentinet security)
Mediation and support for multiple protocols (see also Sentinet Services Virtualization). An example of protocol mediation has been discussed and demonstrated in this article.
Easy management of virtual services as demonstrated (designing, configuring).

다음을 통해 공유