Exposing a service through Sentinets Virtual Service concept
This time we will follow up on the Service Virtualization concept I mentioned in my previous post.
- Service redesign
- Apply security
- Monitoring
http://abdulrafaysbiztalk.wordpress.com/
We can change this by defining a Virtual Service layer around the webservice, for this, we will use the public Geoipservice which (unfortunately) only exposes 2 methods (but I think the example provides a good example);
1) GetGeoIPContext
2) GetGeoIP
Time to fire up Sentinet;
Sentinet is a web-based product where you can build of a repository of artefacts such as Access rules, Services, Policies, etc)
We will import the wsdl of the GeoIPService by added a new SOAP service, after which we will get a dialog where we should paste the wsdl;
It will download the metadata;
And display the metadata extracted from the wsdl, and allows us to define if we will directly use the service by ticking ‘Add service in active state’ (if not, we can prevent this service to be accessible from Sentinet after the import);
After the import, when can view the details of our service;
And start with….Virtualisation, we click on the Node (physical endpoint where we host the service) and define the type of service we would like to create;
Note: We can select SOAP (WCF bindings) and as well REST, so already…we can do transport mediation, our service can be exposed with a different binding with which it was exposed originally.
We define metadata about the service;
And that’s it….altough the service won’t do anything yet….
The next step is to design the service, and this is where the magic will happen;
The designer allows us to REDEFINE the WSDL, we can define one or multiple endpoints, and even add methods from one or multiple webservices…we can combine service, change service expose, and as we will see later on, control the security.
We will modify the service, so we need to click on ‘Modify’;
We can drop the GeoIPService (imported WSDL) on the designer of the Virtual Service, this by dragging it from the repository to the designer;
This will update the designer;
By selecting the methods we want to expose;
We can control how the virtual service will be exposed! Additionally, we can define where to host the service, by selecting a Node;
This allows us to modify how we expose the Virtual Webservice;
We will select a policy, which is a WCF-Binding, applied to the endpoint;
Note: We can define ‘common’ bindings and place them in a shared repository, allowing company policies.
In this case we will select the basicHttp binding;
So at this point, we have redesigned the service, changed the endpoint, how about setting up securiity?
Sentinet provides access rules, which can be design in a graphical designer, as well as defined in an Xml editor. You can actually copy-paste the Xml and the designer will update. There are a lot of predefined keywords available, for instance the Transaction Count.
Let’s assume that the webservice should not be called more than 5x a minute, we can define a Dos Attack Protection rule, this will block requests exceeding this rule! We can define our customer behavior as there is a .Net extension point, but it already possible to apply rules based on security (is a certificate provided, is a SAML token available with certain metadata, is a specific value in the message defined etc;
We can drag the rule to the Web service, and even to specific methods (however, there’s only 1 left after our redesign
);
We can define multiple rules, and define which rule has precedence;
Our service definition is now complete, however our service is not exposed, we can do this by promoting our service;
We will promote our service, which places it in the active state;
So that’s it, we have created our virtual service, in the next post we will use it and monitor it by using the additional monitoring capabilities of Sentinet.
Kind regards,
Sander
Tags van Technorati: Virtual Service,BizTalk
Comments