Value adds beyond being a proxy for Google Maps webservice

The proxy classes for Google Maps Webservices have additional functions, besides just acting as a C# interface. Debatably, the most important of which, is the request splitting feature, which is built as part of the distance response caching layer.

First, you need to know what a proxy class is. In this case, we borrow Microsoft’s naming convention to call it a Web service proxy class. A proxy class borrows an interface from a implementation, to stand in for the real thing, to the client. It’s an imposter. Like that service rep you call on the phone, who can’t answer your hard questions. The real thing is her manager, who she keeps asking the answers from. Some say a true proxy is indistinguishable from the real thing during compilation (like you have no idea if the guy you are talking to, at first glance, is the manager initially), which isn’t the case for a webservice proxy (A distinction I’m sure you can argue about like chicken wo a head, with another programmer who cares). Our proxy acts as a stand-in for the compiler, so any code that calls the webservice, uses the same “template” to call the webservice. The diagram shows 4 API’s we created proxies for. But the actual project only implements 3.

This painting is called “Static Dependency Representation of the role of a Webservice proxy”

Second, mistakes happen. The request splitter in version 1 doesn’t use a decorator, as was mentioned before. It does in version 2. Version 1 is just implemented in what they call composition, which is something like a bastard child that no class wishes to claim kinsmanship with.

i Note

Decorators are also stand-ins. But there is no such thing as a “real thing”. It’s a stack of implementations that is supposed to add “value” or special kind of work, to each request, while keeping the same interface.

Kinsmanship for classes, is analogous to tetris. They all have to accept the same shape.

Third, you need to understand how the distance matrix from Google is modeled. When you make a request for distances, it responds in a xml data structure that is supposed to mimic the idea in the figure below, except completely filled.



This is a hypothetical interim response of a request for distances between A, B, C, D, E, F, G, H, I, J. In our scenario depicted here, we already have result cached for C, D, E, F, G. So to save a few cents, we only wish to request the missing items.

Above, you see a situation where part of the request is filled. In the video, it shows how the algorithm sorts through what is missing. So in the code, you will see it attempt to do the action depicted in the video. The black rectangle being a representative of a user’s request for distances. Initially black bc it is assumed that all of it has to be fulfilled by Google. Followed by the program’s search of which distances already exist. Those are marked green. Followed up by a sort of the still missing distances, where the black is aggregated to top left. And search for a large block of to request (blue). And even that request may be too big, so it is split into smaller chunks (red). The DemoDistanceRequestSplitter demonstrates the visualization in the video.

So when you look at the code, this is what it is attempting to do.

Leave a Reply

Your email address will not be published. Required fields are marked *