Aggregated Web Services Pt I

I’ve been working through an architecture scenario recently. This is what I have so far. Multiple external web services, some SOAP and some REST, and some data sources in a SQL Server Database, Azure Table Storage, and flat files of some sort. All of these sources need to be accessed by a web site for read-only display. In the diagram below I’ve drawn out the primary three points of reference.

The services that are external; Contract, Table Store, Document, Search, and Help Desk Services.
The Website Web Services Facade, which would be an aggregated layer that then provides the various services via an internally controlled services layer.
On top of that will be the web site, accessing the services from the aggregated layer with jQuery.

Basic Three Tiers
After creating this to get some basic idea of how these things should fit together, I moved on to elaborate on the web services aggregation layer. What I’ve sketched in this diagram is the correlation to architectural elements and the physical environments they would prospectively be deployed to. Again, broken out by the three tiers as shown above.

Website and the respective jQuery, AJAX, and Market/CSS for display.
Web Services, which include the actual architecture breakout; Facade Interface, Facade Aggregation Component, Cache & Non-cached DTOs (Data Transfer Objects), Cache Database/Storage, Caching Process, Lower Layer Aggregation Component, and the Poller Process for polling the external services.
The cache is intended to use SQL Server, thus the red call out to the physical SQL Server cluster.
The last tier, which isn’t being developed, but just providing data is the External Services, primarily shown to provide a full picture of all the layers.