proxy

Using Network-Side Scripting to Convert Microsoft Smart Quotes to HTML Entities 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... posted @ Monday, November 02, 2009 3:03 AM | Feedback (0)

Using Network-Side Scripting to Implement Mock API Endpoints 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... posted @ Monday, October 05, 2009 4:00 AM | Feedback (5)

What is server offload and why do I need it? 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... posted @ Wednesday, June 17, 2009 4:07 AM | Feedback (4)

A client is still a client even when it's on the space station 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... posted @ Friday, November 14, 2008 3:08 AM | Feedback (0)

Understanding network-side scripting 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... posted @ Friday, October 31, 2008 5:26 AM | Feedback (9)

8 things you can do with a proxy 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... posted @ Wednesday, October 08, 2008 4:27 AM | Feedback (0)

The Concise Guide to Proxies 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... posted @ Thursday, October 02, 2008 5:01 AM | Feedback (2)

The third greatest (useful) hack in the history of the Web 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... posted @ Monday, September 08, 2008 4:13 AM | Feedback (1)

Working around client-side limitations on custom HTTP headers 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... posted @ Wednesday, August 06, 2008 4:07 AM | Feedback (1)

Application Delivery: Loose-Coupling for Legacy Apps 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... posted @ Tuesday, March 11, 2008 9:49 AM | Feedback (0)

You say "Late", I say "Delayed" 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... posted @ Tuesday, March 04, 2008 9:33 AM | Feedback (0)