Visibility in both SSL and Non-SSL SOAP traffic

Obviously as we mentioned in the below discussion it is imperative to have visibility into web service communication. This visibility is important for creating SLA's and managing performance and faults generated in the runtime environment.

There is also a need to find out on a per client basis how the Web service is performing and the passive monitoring of the service environment needs to be for every client accessing the service.

Now lets assume that the SOA environment includes an XML gateway where the requests from the actual clients are sent using SSL to this gateway. The gateway then in turn will decrypt the message and forward the decrypted message to the server hosting the service. The service will process the SOAP message and sends a clear text SOAP response to the gateway which encrypts that message and send the response encypted to the client that initiated the conversation.

So most soa management products can give you visibility to the communication between the XML gateway and the Web service. But what about understanding what is happening from the client to the XML gateway. To do that you would need visibility into SSL traffic.

Getting visibility into the SSL communication will allow you to build your SLA's around the actual client accessing the service and will include any perfromance degredation that the XML gateway will introduce into the communication. It will also allow you to correlate between the SSL and non-SSL portion of the communication. It allows you to also audit those messages and be able to use that information for SLA enforcement.

You can read about how JaxView provides agentless visibility into SSL traffic please read here.


AA

http://www.managedmethods.com/

Runtime SOA Visibility Options

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

http://www.managedmethods.com/

Do I need an XML Firewall?

Ok, so you are building Web Services and putting them into production. Soon some external partners need to use your services and a question of Security comes up: how do I secure my services?

Whether you want to make the communication over SSL or just use basic http authentication or authentication through an LDAP server, there still needs to be an implementation of any of these security mechanisms. In this blog, I'll talk a little about what those options are and what the pros and cons are of each, regardless of which security type you need to use.

1. Adding security directly to the Web service.
In this option, the security for the Web Service is embedded into the code for the Web service. This is the most common way of implementing security. Although it might be a good option, if you are building a single Web service, there are many flaws with this approach.
The main issue with this approach is change management. In this case, the addition of security is the job of the developer who is building the service. So if there is an authentication of the user that needs to be done, it will be done by the service before the actual work the service is supposed to do. Now what if there is a new policy in which all the consumers of the service need to be authenticated through a different mechanism than the one that was originally designed? Well in this case, the developer would have to re-write the code and then send the service back into QA and so on. So this is far from an ideal implementation type.

2. Installing the Security in a handler agent.
In this case security is still owned by the developer of the service, but the code for security is not embedded in the code for Web Service. Instead the developer installs the security as part of the handler chain in J2EE environment or an extension in the .Net environment. Although this is a better choice than building the code directly into the Web Service, as you build more and more services this becomes a management nightmare, as you would have to modify configuration files on the application server hosting the service to install these agents, if there are any changes. Also in a lot of environments, if the handler chain code is modified, then everything needs to go through the QA process. In this way, you would still have the problem of adding security directly to the web service (number 1).

3. Use an XML Firewall
This is the best option available, to introduce a gateway or a proxy where all of the requests to the Web service will be authenticated. In this architecture, the consumer of the web service will send requests to an intermediary (XML Firewall) where authentication and authorization will take place. Then the intermediary will be able to route the messages to the web service, wait for a response, and then send the response back to the consumer. It essentially virtualizes the service. So as far as the consumer is concerned, the XML firewall is the web service.
This implementation allows you to externalize the security from the web service, therefore any changes to your security policies do not result in any code change at the service layer. All of the management of the security will be done at the firewall. You can perform encryption/decryption and authentication externally of the web service. It also removes all of that processing from the application server, as many of the processing done for security is very resource intensive.
Also it removes the security implementation from the hands of the developer and puts it in the hands of the operation folks, where security should be.

Most XML firewalls also include visibility and monitoring features, so you could also use the firewall to meter and manage your services.

Traditionally, it was thought that you need many services and a big budget to buy an XML Firewall. Not true! There are affordable options available now, starting at as little as 2k. This is cost effective solution, in respect to the amount of money this can save by just changing the management process of the QA cycle.
So even if you are putting a single Web service in production, you should think about using an XML Firewall.

AA

www.managedmethods.com

Metric Baselining and Why its important

As companies start to build more and more services that are truly loosely coupled and trusted, they become a source of revenue. These services can then be used by the interested parties on a per use basis. That means the owner of the service has to meet certain service levels to operate the service. So they build certain SLA's that the service has to meet for it to be acceptable.

Some of these SLA's might include things like availability, performance, fault generation, etc. In this blog, I would like to specifically talk about performance SLA's.

Setting a performance service level agreement means that the service provider agrees that for any request sent to the service that the service sends a response back within a set time frame. So you set a static threshold, and if the performance exceeds that threshold, then it's breaking the service level.

This is a great way to set service levels, if the load on the web service is the same all the time, but usually that is not the case. So as an example, a threshold of 2 seconds might be an ok threshold during the busy times, but not ok during slow times.

To avoid these types of service levels "disagreements", there is a need for a dynamic threshold called baselining. In these cases instead of comparing the performance of the service for any message to a static threshold, we compare it to a dynamic or "rolling baseline". So as an example, let's say we have a 3 hour rolling baseline. The request comes in and a response is sent back. Let's say this transaction took 2 seconds. In a 3 hour rolling baseline situation, we look at all the requests that came in the last 3 hours and their performance. We create an average and a standard deviation (baseline), then we see if this new performance metric (2 seconds) is within a certain standard deviation. This type of baselining will account for busy times, etc.

This baseline comparison can still be taken a step further. For example instead of looking at the last 3 hours for the baseline, we could look at the same 3 hour period going back multiple weeks. That will give us a better baseline and also help us with trending and forecasting. So we know what the baselines are for any time period during the week and set our SLA's accordingly.


AA
www.managedmethods.com

Active vs Passive monitoring in SOA Management

OK, so you hear a lot about SOA Monitoring and why it's important. You also hear words like Active monitoring and Passive monitoring. I think everyone has his or her own definition of what these terms mean. In our case, our product JaxView performs both active & passive monitoring of a single Web service and also active & passive monitoring of a collection of services where these services are the backend applications that support a business process.

So what is Active monitoring? Active monitoring is essentially mimicking how a Web service performs and responds when a synthetic request is sent to the Web service and response is received, on a schedule. So the monitoring application will create and send a synthetic request, sending it to the service and measuring how long that transaction took, while also monitoring the response to make sure it's a valid response at the same time monitoring the actual response. As an example, let's say a Web service response includes the inventory number for an item for sale. You want to actively understand what that number is. So with an active monitor you can create a synthetic SOAP request that queries the Web service and then monitors that response. If the response is below a specific threshold, the monitoring engine will send off an alert. Now this alert could be an email to someone that tells them to go refill that item, or it may invoke a refilling service that will increase the inventory number.
Active monitoring also will give you a heart beat of the Web service, so in case the Web service is down it can alert someone or execute a script to re-launch the web service.
We also see people invoking their web service actively to keep the Web service initialized, therefore allowing it to perform better when a "real client" accesses it. The initialization time can sometimes be huge compared to the actual service performance time.

What is Passive Monitoring? Passive monitoring is basically monitoring of real time client interaction with the Web service. Basically sitting back and looking at the message flow from "real clients" and generating metrics around that. These metrics could be SLA metrics, showing who is accessing the web service, how often, and how the web service performs for each individual client. Passive monitoring is extremely important as it allows you to look at the real user runtime data and in some cases use that data to increase your testing coverage in QA. As an example, let's say the Web service developer would like you to monitor for a specific fault code, and if that fault code is detected in a response from the Web service, to send him the actual request that caused that fault. Then that request can be used in the QA to extend the testing coverage. This just a very simple example of why passive monitoring is important.

AA
www.managedmethods.com

Blue Collar SOA Management

OK, so I just got back from SOA world and after thinking about all the different panels that I saw, the one that stuck out to me the most was from Active Endpoint and Synovous Financial. These guys talked about something called Blue Collar SOA.

They integrated all of their business processes through loosely coupled services using AE's bpel engine within days and at a much more cost effective rate.

There needs to be more tools like that, and as SMB's start to migrate to SOA they need these types of Blue Collar SOA tools that don't take months to implement and deploy.

What a novel idea!

AA
www.managedmethods.com