SOA vs Cloud Management

At the SOA world conference a colleague asked me a simple question. What is the difference between SOA and Cloud management?

Its an intersting question. After thinking about it a bit I wasn't able to find much difference. SOA is an architecture that allows you to create a set of services that can be used in many differenct business processes. Basically loosley coupled and built for reuse. Cloud is a set of API's that for the most part perform the same functionality. Therefore, management of them is also very similar.

You need to understand the same basic things

1. Securing the cloud services and API's
2. Measuring performance and availability of these API's and services
3. Measuring usage and SLA's for the cloud
4. Be able to trouble shoot when something goes wrong with the consumer accessing those services.

These are the same management issues that we face in the SOA world. So if you're looking to manage your cloud don't look further than any SOA management tools out there.


AA
http://www.managedmethods.com/

Visibility into SOA platforms

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

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.

• 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

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

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

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/