I my previous post; Exposing a service through Sentinets Virtual Service concept i’ve explained how to redesign a service by leveraging the Virtual Service concept.
We will now execute this service and monitor it. When we open up Sentinet, we have a catalog of Virtual Services; If we go into the details of the Virtual Service, we can generate the WSDL;
This WSDL will be made available for a limited duration (i believe 15 min), so that we can use it to generate the consumer, so we see here, that we have our webservice GeoAdmin i had created earlier;
We can now use a tool such as SOAPUI to fire requests to the service;
As we can see, only the method we had choosen earlier is available, the method ‘GetGeoIPContext’ was not selected in our Virtual Service;
Resulting methods in our wsdl;
We can send a request to the service;
And here, we can use the features Sentinet provides, which is something we can use On-Premise, and in Azure by placing Sentinet Nodes in-front of Azure Services! We see a request;
And if we look at our specific service, we can look at the message flow;
We can look at the message details which shows which rules were applied;
And we can tune the monitoring profile, from None, Extend, Full, Custom (we can choose which event to monitor);
If we enable full monitoring, we have tracking for each operation, on a meta and message level;
If we send a another request, we can now look, and see even the message details;
Because Sentinet works as a repository, we have a dashboard which shows a lot of information on a high-level indicating the state of the repository;
So, controlling/monitoring/securing/redesigning services is all possible and managed in a single repository.
In future posts, i would like to look at hybrid scenarios, where this allows us to ‘secure’ a relay, monitor the Cloud endpoints, decouple the Cloud from the On-premise, a lot of potential added value.