proxy
There are 14 entries for the tag proxy
Managing a datacenters is often like managing a multi-generational family – you’ve got applications across a variety of life stages that need to be managed individually, and keeping costs down while doing so is a concern.
Those who know Don and I know we have a multi-generational family. Our oldest son is twenty-three and “The Toddler” is, well, almost three. There’s still “The Teenager” at home, and there’s also a granddaughter in there who is, well, almost three, so we’ve got a wide variety of children across which we have to share our limited resources.
Each one, of course,...
There’s a rarely mentioned move from 1024-bit to 2048-bit key lengths in the security demesne … are you ready? More importantly, are your infrastructure and applications ready?
Everyone has likely read about DNSSEC and the exciting day on which the root servers were signed. In response to security concerns – and very valid ones at that – around the veracity of responses returned by DNS, which underpins the entire Internet, the practice of signing responses was introduced. Everyone who had anything to do with encryption and certificates said something about the initiative.
But less mentioned was a move to leverage longer...
Deep packet inspection is useless when you’re talking about applications Back in the early days of networking (when the pipes were small and dumb) the concept of “Deep Packet Inspection” started to bubble up the network stack. Deep Packet Inspection describes the ability of a networking device to fully inspect an Ethernet packet; essentially it’s the ability to examine the data in the payload that’s actually being transported across the network. This is a Very Good Thing because it allows myriad networking devices to perform interesting and useful functions like sniffing out malicious activity (attacks, attempted...
You can address the problem of converting smart quotes – and any other content - in your application if you control the code. What if you’re using third-party software for which you do not have the code? Or what if it is your code but the “defect” is so low on the priority list that you won’t get to it until the year 2020?
Dealing with Microsoft smart quotes is a fact of life for developers. Almost every developer out there has a server-side script/function they use to strip them out of user-generated content and replace them with web-friendly HTML...
Steve (apparently yes, we are on a first name basis) offers up his thoughts on developing APIs for the Cloud in “A Cloud Tools Manifesto.” While the inclusion of the word “manifesto” in the title raised quite the stir (“Manifestogate” is still fresh on the minds of many cloud-oriented people), what really caught my eye is his inclusion of a “mock endpoint” primarily for testing of API based integration and development. This is something that’s increasingly important not just to cloud but to Web 2.0 and social networking sites that provide APIs via which other sites and client applications can...
One of the tasks of an enterprise architect is to design a framework atop which developers can implement and deploy applications consistently and easily. The consistency is important for internal business continuity and reuse; common objects, operations, and processes can be reused across applications to make development and integration with other applications and systems easier. Architects also often decide where functionality resides and design the base application infrastructure framework. Application server, identity management, messaging, and integration are all often a part of such architecture designs. Rarely does the architect concern him/herself with the network infrastructure, as that is...
While I was at SD Best Practices in Boston last month I got to talk to a lot of engineers, developers, and architects about their environments and about what F5 does for application delivery. One of the developers glibly told me he wasn't sure we could help him out because his environment was the international space station. Yeah, how cool is that? Now that's cloud computing. Another architect, who turned out to be a friend of a friend who I've conversed with but never met in person said the same thing, but...
We all understand the lines in the sand (or the architectural diagram) that separate client-side scripting from server-side scripting. It's very clear that client-side scripting, e.g. JavaScript, VBScript, ActionScript, executes on the client while server-side scripting, e.g. PHP, ASP, executes on the server. But what about network-side scripting?
"There is no such thing!" might be the first response to this question, but I beg to disagree. Programmable proxies, a la F5's BIG-IP Local Traffic Manager, that provide a scripting language such as iRules, are simultaneously client-side and server-side, with the best definition to describe their placement in architectures being network-side...
After having recently discussed all the different kinds of proxies that exist, it occurred to me that it might be nice to provide some examples of what you can do with proxies besides the obvious web filtering scenario. This is by no means an exhaustive list, but is provided to show some of the more common (and cool, I think) uses of proxies. What's really awesome is that while some of these uses are available with only one type of proxy (reverse or forward), a full proxy can provide all these uses, and more, in a single, unified...
We often mention that the benefits derived from some application delivery controllers are due to the nature of being a full proxy. And in the same breath we might mention reverse, half, and forward proxies, which makes the technology sound more like a description of the positions on a sports team than an application delivery solution. So what does these terms really mean? Here's the lowdown on the different kinds of proxies in one concise guide. PROXIES Proxies (often called intermediaries in the SOA world) are hardware or software solutions that sit between the client and the...
Developers have an almost supernatural ability to workaround restrictions, even though some of the restrictions on building applications delivered via the web have been akin to a kryptonite. Like Superman fighting through the debilitating effects of the imaginary mineral, they've gotten around those restrictions by coming up with ways to implement functionality and improve the behavior of browsers and thus web applications anyway. The first greatest hack was giving HTTP state. The second? Cookie-based persistence. The third? The CNAME trick. THE PROBLEM The reason the "CNAME trick" came about was a limitation on browser connections...
One of the most well-kept secrets in technology is the extensibility of HTTP. It's one of the reasons it became the de facto application transport protocol and it was instrumental in getting SOAP off the ground before SOAP 1.2 and WS-I Basic Profile made the requirement for the SOAP Action header obsolete. Web browsers aren't capable of adding custom HTTP headers on their own; that functionality comes from the use of client-side scripting languages such as JavaScript or VBScript. Other RIA (Rich Internet Applications) client platforms such as Adobe AIR and Flash are also capable of adding HTTP...
How to apply SOA principles to traditional web application architecture I promised kudos and comments last week for Ronald Schmelzer's ZapNote on the requirement for a service proxy in SOA implementations and so I shall right now. While Ron didn't come right out and say it, a major reason the service proxy is an essential component of a successful SOA implementation is that it protects the concept of loose-coupling, a primary foundational principle of SOA. Loose-coupling is generally applied to consumer-producer relationships and essentially requires that there be no code or logic on the consumer (client) that binds it tightly...
The language of application delivery and SOA finally meets in the middle Ronald Schmelzer at ZapThink wrote a recent ZapFlash titled, "Why Service Consumers and Service Providers Should Never Directly Communicate." Yes, I agree, the title is way too long, but you should read it anyway. The basic premise of this one is that there is a need for a service proxy to protect your investment in SOA. I'll save my kudos and comments for another post, but in general I agree with Ron and his vision of SOA and the need for a proxy/intermediary to prevent the loss...
