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.
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.
I primarily drew up these diagrams for discussion of the architecture, poke holes in it, or otherwise. Which speaking of, if any readers have input, question, or are curious please type up a comment and I’ll answer it ASAP.
As the effort continues there are some other great how-to write ups I will be putting together. Everything from unit testing, mocking (with moq), how to setup test services, test services, and other elements of the project. I’ll have all this coming, so keep reading & let me know what you think of the design so far, subscribe via e-mail (look to the metadata section below), or grab the RSS for the blog (see below also).
Great job, Adron.
My only comment after looking at your architecture (with the intent to poke holes) is to question the complexity for a read-only site. As a lover of technology and someone w/ keen interest in all of the different aspects of your architecture, the complexity is interesting, but I would question whether, in a real-world scenario, with time constraints, budgets, are you decreasing the chances of success. Food for thought. I’ll keep reading along.
I’m actually concerned about this too (the complexity), as it has the dreaded redundant architectural pieces. I’ll elaborate more in Pt II that I have coming and layout some of the code I’m putting down for it. Also to note, this is actually a real world scenario, that will most likely be going to production in about 5 months. 🙂 So we will definitely see if it holds water – this boat could still sink and I have to do a complete redesign. Thanks for the comment Kirk! I look forward to additional feedback as I post more! -Adron
It’s hard to evaluate without some notion of the overall size of the data, it’s rate of change, complexity of allowable query, typical size of the data response, etc.
From your diagram, I gather you want to maintain a complete set of aggregated data in your cache. If this is the case, why not decouple it completely from the application (it’s just “the data repository”) and have the replication mechanism be completely separate.
You might want to check out this video from lynn langit were he talks about async willing of queue from multiple sources to fulfill a request: http://www.slideshare.net/lynnlangit/windows-azure-platform-2626957
I’m digging Lynn’s material, thanks for the link Marty.