tag:blogger.com,1999:blog-25791015645657734812024-03-13T06:13:00.440-07:00JaxView SOA GovernanceThis blog was created to provide familiarity for companies that are looking to effectively manage their SOA environment with little costJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-2579101564565773481.post-27444229626372187882011-01-10T07:48:00.000-08:002011-06-23T10:00:18.752-07:00Introducing CloudGate API ManagementBoulder, CO (January 10th 2011) – Managed Methods Inc. www.managedmethods.com, the leading provider of cost effective SOA security and governance products, today announced availability CloudGate, a hosted cloud services management solution. CloudGate delivers security, monitoring, provisioning and goovernance of APIs and services deployed in the public and private cloud infrastructure.<br /><br />Please read the rest of the post here<br /><br /><br /><a href="http://www.managedmethods.com/35/news.html">http://www.managedmethods.com/35/news.html</a><br /><br />AAJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com1tag:blogger.com,1999:blog-2579101564565773481.post-14514433126430434382010-06-10T07:26:00.000-07:002010-06-10T07:29:36.258-07:00JaxView Internal Secure Token ServiceHere is a demo of JaxView and its integration with its internal secure token service. This will allow security federation functionality for SOA and Cloud based services for single sign on functionality. Enjoy!!<br /><br /><a href="http://www.managedmethods.com/video/JaxViewSTSDemo/JaxViewSTSDemo.html">JaxView STS Demo</a><br /><br /><br />AAJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-78087402503872682592010-01-28T12:30:00.001-08:002010-01-28T12:31:54.111-08:00JaxView WebCastWe recently did a webcast that includes a demonstration of JaxView. You can download the recording here<br /><br /><a href="http://www.managedmethods.com/trackdown_webinar_a.php">http://www.managedmethods.com/trackdown_webinar_a.php</a><br /><br /><br />AAJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com2tag:blogger.com,1999:blog-2579101564565773481.post-1199554986701937702009-07-28T08:25:00.001-07:002009-07-28T08:47:37.222-07:00SOA vs Cloud ManagementAt the SOA world conference a colleague asked me a simple question. What is the difference between SOA and Cloud management?<br /><br />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.<br /><br />You need to understand the same basic things<br /><br />1. Securing the cloud services and API's<br />2. Measuring performance and availability of these API's and services<br />3. Measuring usage and SLA's for the cloud<br />4. Be able to trouble shoot when something goes wrong with the consumer accessing those services.<br /><br />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.<br /><br /><br />AA<br /><a href="http://www.managedmethods.com/">http://www.managedmethods.com/</a>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-48034691832560729652009-04-24T11:09:00.001-07:002009-04-24T13:14:07.329-07:00Visibility into SOA platformsI just read one of our competitors has finally added support to provide visibility for IBM <span class="blsp-spelling-error" id="SPELLING_ERROR_0">DataPower</span>. How? Well they finally wrote an agent for the IBM <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">appliance</span>. An intrusive agent is how they mange to provide visibility into D<span class="blsp-spelling-error" id="SPELLING_ERROR_1">ataPower</span> mediated services.<br /><br />Well <span class="blsp-spelling-error" id="SPELLING_ERROR_1"><span class="blsp-spelling-error" id="SPELLING_ERROR_2">JaxView</span></span> has been providing visibility into <span class="blsp-spelling-error" id="SPELLING_ERROR_3">DataPower</span> or any other security or <span class="blsp-spelling-error" id="SPELLING_ERROR_2"><span class="blsp-spelling-error" id="SPELLING_ERROR_4">xml</span></span> appliance for the last few years. How? We don't use agents. Our <span class="blsp-spelling-error" id="SPELLING_ERROR_3"><span class="blsp-spelling-error" id="SPELLING_ERROR_5">agentless</span></span> deployment looks at the network traffic to provide visibility metrics and is <span class="blsp-spelling-corrected" id="SPELLING_ERROR_4">independent</span> of protocol or platforms. It supports protocols such as <span class="blsp-spelling-error" id="SPELLING_ERROR_6">JMS</span>, <span class="blsp-spelling-error" id="SPELLING_ERROR_7">RMI</span>, HTTP, REST, <span class="blsp-spelling-error" id="SPELLING_ERROR_8">SSL</span>, JOLT, <span class="blsp-spelling-error" id="SPELLING_ERROR_9">WTC</span>, <span class="blsp-spelling-error" id="SPELLING_ERROR_10">JDBC</span> and any other <span class="blsp-spelling-error" id="SPELLING_ERROR_11">TCP</span> <span class="blsp-spelling-corrected" id="SPELLING_ERROR_12">protocol</span> used by services.<br /><br />And <span class="blsp-spelling-corrected" id="SPELLING_ERROR_5">BTW</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_6"><span class="blsp-spelling-error" id="SPELLING_ERROR_13">JaxView</span></span> is about a tenth of the cost of the so called leaders in the <span class="blsp-spelling-error" id="SPELLING_ERROR_7"><span class="blsp-spelling-error" id="SPELLING_ERROR_14">Runtime</span></span> Governance market. You can download J<span class="blsp-spelling-error" id="SPELLING_ERROR_8"><span class="blsp-spelling-error" id="SPELLING_ERROR_15">axView</span></span> and try it for yourself <a href="http://www.managedmethods.com/">here.</a><br /><br /><br /><br />AAJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-47811220914906071012008-10-14T13:35:00.000-07:002008-10-14T14:04:18.581-07:00What is SOA Management?As we sift <span class="blsp-spelling-error" id="SPELLING_ERROR_0">through</span> the hype of <span class="blsp-spelling-error" id="SPELLING_ERROR_1">SOA</span> this question comes to mind. How do I effectively manage my <span class="blsp-spelling-error" id="SPELLING_ERROR_2">SOA</span>. I would have to say the most effective way to manage an <span class="blsp-spelling-error" id="SPELLING_ERROR_3">SOA</span> infrastructure is to manage it without having to disrupt the <span class="blsp-spelling-error" id="SPELLING_ERROR_4">SOA</span>.<br /><br />There are more than a few <span class="blsp-spelling-error" id="SPELLING_ERROR_5">SOA</span> management vendors out there but for the most part deployment of a <span class="blsp-spelling-error" id="SPELLING_ERROR_6">SOA</span> 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 <span class="blsp-spelling-error" id="SPELLING_ERROR_7">SOA</span> management product. That is a <span class="blsp-spelling-corrected" id="SPELLING_ERROR_8">ridiculous</span> notion in my opinion.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br /><ul><li><strong>Platform Independent - </strong>Obviously since nothing is installed on the server there is no dependance on what platform the server is installed on</li><li><strong>No change to Provider or Consumer - </strong>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</li><li><strong>No Load - No Latancy - </strong>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</li><li><strong>All Protocols - </strong>By dissecting all tcp protocols this deployment can provide visiblity into SOAP, REST, JMS, JDBC, RMI etc. </li><li><strong>Service Discovery - </strong>This is the best way to autodiscover <strong>rogue </strong>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.</li></ul><p>You can read more about this deployment at one of our customer sites in the case study <a href="http://www.managedmethods.com/trackdown_casestudy.php">here</a>.</p><p></p><p>AA</p>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-1815427641574867802008-07-29T08:33:00.000-07:002008-07-29T08:35:05.061-07:00JaxView Case Study In Agentless VisibilityWe 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 <a href="http://www.managedmethods.com/trackdown_casestudy.php">here</a><br /><br /><br />AAJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-89738493626508851582008-07-10T08:03:00.001-07:002008-07-10T08:24:31.583-07:00Visibility into REST ServicesOk so we've just added REST service visibility into JaxView when deployed as an agentless sniffer. Why is this important?<br /><br />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 <a href="http://www.managedmethods.com/22/news.html">here.</a><br /><br />AAJaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-34734455006117352212008-02-18T10:47:00.000-08:002008-02-18T11:04:04.390-08:00Visibility in both SSL and Non-SSL SOAP trafficObviously 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />You can read about how JaxView provides agentless visibility into SSL traffic please read <a href="http://www.blogger.com/www.managedmethods.com/content/49.html">here</a>.<br /><br /><br />AA<br /><br /><a href="http://www.managedmethods.com/">http://www.managedmethods.com/</a>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com1tag:blogger.com,1999:blog-2579101564565773481.post-27948445125774830412008-01-21T08:10:00.001-08:002008-02-07T07:59:44.579-08:00Runtime SOA Visibility Options<p>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.<br /><br />Some questions that come up might include:<br />- How would you know who is accessing this service and how often?<br />- How is the service performing during different times of the day and from different clients?<br />- What faults are being generated and how will these faults, generated by the runtime clients, affect the performance and availability of the service?<br />- How do you enhance your service to generate less faults, or more importantly, less un-accounted for faults?<br />- 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? </p><p>- 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.<br /><br />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. </p><p>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:</p><p>1. <strong>Look at the message flow by looking at out of band network traffic. </strong>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.</p><p>2<strong>. Deployment of a Network Gateway. </strong>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.</p><p>3. <strong>Use of Agents.</strong> 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.</p><p></p><p>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.</p><p></p><p>AA</p><p><a href="http://www.managedmethods.com/">http://www.managedmethods.com/</a></p>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-75260116517400150872007-12-26T07:44:00.000-08:002008-02-07T07:46:10.359-08:00Do 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?<br /><br />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.<br /><br />1. <strong>Adding security directly to the Web service</strong>.<br />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.<br />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.<br /><br />2. <strong>Installing the Security in a handler agent.</strong><br />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).<br /><br />3. <strong>Use an XML Firewall</strong><br />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.<br />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.<br />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.<br /><br />Most XML firewalls also include visibility and monitoring features, so you could also use the firewall to meter and manage your services.<br /><br />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 <a href="http://www.managedmethods.com/">2k</a>. 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.<br />So even if you are putting a single Web service in production, you should think about using an XML Firewall.<br /><br />AA<br /><a href="http://www.managedmethods.com/"><br />www.managedmethods.com</a>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-77293399816409381152007-12-12T06:55:00.000-08:002008-02-07T07:34:34.675-08:00Metric Baselining and Why its importantAs 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br /><br />AA<br /><a href="http://www.managedmethods.com/"><strong>www.managedmethods.com</strong></a>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0tag:blogger.com,1999:blog-2579101564565773481.post-68179968489368916442007-12-06T08:11:00.000-08:002008-02-07T07:30:07.852-08:00Active vs Passive monitoring in SOA ManagementOK, 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 <a href="http://www.managedmethods.com/">JaxView</a> 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.<br /><br /><strong>So what is Active monitoring?</strong> 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.<br />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.<br />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.<br /><strong><br />What is Passive Monitoring?</strong> 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.<br /><br />AA<br /><a href="http://www.managedmethods.com/"><strong>www.managedmethods.com</strong></a>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com2tag:blogger.com,1999:blog-2579101564565773481.post-16444918254102745162007-11-29T10:22:00.000-08:002008-02-07T07:20:22.749-08:00Blue Collar SOA ManagementOK, 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.<br /><br />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.<br /><br />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.<br /><br />What a novel idea!<br /><br />AA<br /><a href="http://www.managedmethods.com/"><strong>www.managedmethods.com</strong></a>JaxView - MMhttp://www.blogger.com/profile/05497590830302808131noreply@blogger.com0