In my previous post I introduced the follow up of Microsoft Services Engine, Sentinet from Nevatech. I discussed the deployment of Sentinet on a single machine, which I am going to use for further exploration of this product. In this post I like to share the user experience and management side of Sentinet.
To discuss the user experience and management of Sentinet I am going to do a walk-through with an example. I will poll data through a runner service from a database containing my 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 service to provide multiple ways of providing access to my runner service for different end users. Below you will find an overview of the example.
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.
WCF Service is created by selecting WCF Adapter Service Template in Visual Studio. This template is available in case you have installed the BizTalk Server Adapter Pack, which includes the WCF-SQL Adapter. The benefit of using this adapter through the pack is that everything is generated for me based on the operations I like to perform on a database. The template provides a wizard you can walk-through to generate your WCF service.
Once the service is up and running in IIS under an application pool that has the appropriate access to the runner database. You could test using the WCFTestClient to see if functions accordingly.
Next 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.
The following steps are derived from the Quick Start tutorial:
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.
You can provide a human readable endpoint name, and assign a policy to the inbound endpoint. Endpoints can be assigned policies from the shared standard policy templates created in the Sentinet Repository. The Add Policy Wizard will display a hierarchical structure of registered shared policy templates. You can select the BasicHttpBinding (Default) policy and click Finish.
The BasicHttpBinding policy is now assigned to the Virtual Service inbound endpoint. This binding can be used to configure and expose endpoints that are able to communicate with ASMX-based Web services and clients and other services that conform to the WS-I Basic Profile 1.1. Your Virtual Service structure is now defined and you can click Save in the main toolbar.
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.
Now that the virtual service is active you could test it by consuming it. You can click the WSDL button and select the Wsdl(s) menu option to see your virtual service’s WSDL in a new browser window (other two menu options allow retrieval of the same service metadata either as a single file or in a Metadata Set format).
Note: Based on my solution (example) overview diagram at the top of this post, this virtual service’s WSDL is what End User client applications have to know about (and not the WSDL of my business service that is now hidden from them by the Sentinet Node).
You can copy URL to WSDL from the browser to use in the client solution or in the WCFTestClient.
You can have more SOAP services in the background that expose data/operations on your SQL Server database. You can for instance generate those via same Adapter Service templates in Visual Studio. Subsequently you can create multiple virtual services that can expose all these services and/or a subset of them and/or subset of their operations. Each virtual service you can choose what protocol you want to support, what authentication/authorization you require for each end user.
As you have been able to read through this blog 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)
- Easy management of virtual services as demonstrated (designing, configuring) in this blog. You will have to experience it to get a good view and opinion yourself.
In next part I will discuss the management a bit further by exploring the monitoring features.
Cheers,
Steef-Jan
