Ok, so you're starting to develop some web services and deploying them in production. When you reach this stage where even one service is put into production and clients start to access the service, there's a need to gain visibility into this environment.
Some questions that come up might include:
- How would you know who is accessing this service and how often?
- How is the service performing during different times of the day and from different clients?
- What faults are being generated and how will these faults, generated by the runtime clients, affect the performance and availability of the service?
- How do you enhance your service to generate less faults, or more importantly, less un-accounted for faults?
- What are the SLA's that need to be put into place for the clients that need to access this service, especially if there is a charge back of usage involved?
- How to use this runtime "real user messages" to expand your test coverage? There's a need for integration with 3rd party testing tool and your runtime governance tool.
Answering these questions is what SOA and Web services visibility is all about. Obviously there's a need to answer these questions, but more importantly, how to get these answers with the least amount of intrusion as possible.
To get these answers, any tool you use needs to get access to the Web service traffic from real users. Here are the different options you can use:
1. Look at the message flow by looking at out of band network traffic. This by far the least intrusive model. Basically in this option, the tool monitors the out of band SOAP traffic by using a SPAN port or a TAP on a switch where the traffic flows. This "Agentless" option adds virtually no latency or overhead to the network. The tool "sniffs" the SOAP request and response packets and then generates and monitors the traffic for metrics such as performance, and therefore answers the questions above.
2. Deployment of a Network Gateway. This architecture requires a network gateway where the gateway acts as an intermediary between the client and the web service. This deployment option is less optimal than looking at message flow in out of band natwork traffic (number 1), as now the clients would have to send their requests through this gateway. So the endpoint address of the Web service changes, and since this is a gateway, there will be some added latency. On the other hand, if there are policies that need to be enforced, such as security, schema modification, or routing, then this is the best approach.
3. Use of Agents. This architecture requires installation of agents on the application server hosting the web service, usually a generic handler as part of the handler chain in the J2EE deployment or a .Net extension in the .Net web services. This deployment option does not require any change to the client code, but it does require changes to configuration files on the application server hosting the server. This is ok if you're only deploying on one application server, but if there are a lot of application servers, then the configuration management of this deployment could be a headache. This deployment also adds some latency to the system, as the agent would have access to the message before the web service. It also adds some un-necessary processing to the application server. Also the load on the network will also increase, as the agents would have to forward data to the main monitoring server.
Although there are other deployment options, such as integration with a message broker, I feel that if you are only looking to get monitoring and visibility into your environment, then out of band monitoring is the best, least intrusive option available and probably the quickest to get up and running.
AA
No comments:
Post a Comment