I just read one of our competitors has finally added support to provide visibility for IBM DataPower. How? Well they finally wrote an agent for the IBM appliance. An intrusive agent is how they mange to provide visibility into DataPower mediated services.
Well JaxView has been providing visibility into DataPower or any other security or xml appliance for the last few years. How? We don't use agents. Our agentless deployment looks at the network traffic to provide visibility metrics and is independent of protocol or platforms. It supports protocols such as JMS, RMI, HTTP, REST, SSL, JOLT, WTC, JDBC and any other TCP protocol used by services.
And BTW JaxView is about a tenth of the cost of the so called leaders in the Runtime Governance market. You can download JaxView and try it for yourself here.
AA
Friday, April 24, 2009
Tuesday, October 14, 2008
What is SOA Management?
As we sift through the hype of SOA this question comes to mind. How do I effectively manage my SOA. I would have to say the most effective way to manage an SOA infrastructure is to manage it without having to disrupt the SOA.
There are more than a few SOA management vendors out there but for the most part deployment of a SOA management solution is both cumbersome and expensive. The cost of this deployment is more than the cost of the product license. Some of these products are so complicated that there is a need for a resource just to manage the SOA management product. That is a ridiculous notion in my opinion.
Most of these products require an agent to be installed on all the application servers or gateways to be able to provide visibility. Again that's a hidden cost of these products that usually is overseen. Managing the agents and deploying the agents is both time consuming, disruptive and intrusive.
With these agents installed you could then get visibility into different protocols such SOAP, REST, JMS, JDBC, RMI etc. But the over head the agent adds to the server its installed on and the time to configure all the agents etc is too much for many companies that they just go about their SOA without a management tool.
A better way to go about SOA management is to manage the SOA environment without the use of any agents by monitoring at the network layer instead of the server. Many network monitoring tools use this architecture to monitor tcp/udp packets. Why not use the same mechanism to monitor other protocols that are used within the SOA. Well that is exactly how the agentless deployment from JaxView monitors the SOA.
Don't get me wrong there are cases where you need to have an agent or there is a need for a proxy for other enforcement of policies such as authentication and authorization but in general an agentless approach has much less overhead than any other approach. Here are some reasones why agentless approach is more efficient.
There are more than a few SOA management vendors out there but for the most part deployment of a SOA management solution is both cumbersome and expensive. The cost of this deployment is more than the cost of the product license. Some of these products are so complicated that there is a need for a resource just to manage the SOA management product. That is a ridiculous notion in my opinion.
Most of these products require an agent to be installed on all the application servers or gateways to be able to provide visibility. Again that's a hidden cost of these products that usually is overseen. Managing the agents and deploying the agents is both time consuming, disruptive and intrusive.
With these agents installed you could then get visibility into different protocols such SOAP, REST, JMS, JDBC, RMI etc. But the over head the agent adds to the server its installed on and the time to configure all the agents etc is too much for many companies that they just go about their SOA without a management tool.
A better way to go about SOA management is to manage the SOA environment without the use of any agents by monitoring at the network layer instead of the server. Many network monitoring tools use this architecture to monitor tcp/udp packets. Why not use the same mechanism to monitor other protocols that are used within the SOA. Well that is exactly how the agentless deployment from JaxView monitors the SOA.
Don't get me wrong there are cases where you need to have an agent or there is a need for a proxy for other enforcement of policies such as authentication and authorization but in general an agentless approach has much less overhead than any other approach. Here are some reasones why agentless approach is more efficient.
- Platform Independent - Obviously since nothing is installed on the server there is no dependance on what platform the server is installed on
- No change to Provider or Consumer - Again since this is managing and providing SOA visibility by monitoring out of band traffic there is no change that occurs to either the consumer or the provider. You can actually move intor production within minutues instead of days or weeks
- No Load - No Latancy - Since the monitoring is done on the network and only out of band traffic this adds virtualy zero latency or load to the system as a whole
- All Protocols - By dissecting all tcp protocols this deployment can provide visiblity into SOAP, REST, JMS, JDBC, RMI etc.
- Service Discovery - This is the best way to autodiscover rogue services in the SOA environment. If a service is being published and someone is trying to access it then this will discover it. In agent based solution they will only be discovered if there is an agent on the server the service resides on.
You can read more about this deployment at one of our customer sites in the case study here.
AA
Tuesday, July 29, 2008
JaxView Case Study In Agentless Visibility
We just released a case study that talks in more detail about the advantages of managing the service environment without the use of agents or proxies. You can download the pdf here
AA
AA
Thursday, July 10, 2008
Visibility into REST Services
Ok so we've just added REST service visibility into JaxView when deployed as an agentless sniffer. Why is this important?
Many organizations are moving are building REST services especially in high load environments. As we all know SOAP is great and is a standard way for service message communication. This comes with a price tag especially when the payload of the messages increases. For every message a big chunk of the message are the tags associated with SOAP tags. This overhead does create a scalability and network traffic issue for most organizations. That is why in some cases more and more architects are moving to REST. Here is more informantion on JaxView's support for REST services here.
AA
Many organizations are moving are building REST services especially in high load environments. As we all know SOAP is great and is a standard way for service message communication. This comes with a price tag especially when the payload of the messages increases. For every message a big chunk of the message are the tags associated with SOAP tags. This overhead does create a scalability and network traffic issue for most organizations. That is why in some cases more and more architects are moving to REST. Here is more informantion on JaxView's support for REST services here.
AA
Monday, February 18, 2008
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/
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/
Monday, January 21, 2008
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
Wednesday, December 26, 2007
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
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
Subscribe to:
Posts (Atom)
