Mutual Authentication (2-way SSL)

I had to look into this today for a project I am working on. I found this blog which I think explains the concept very nicely.

One Way and Two Way SSL and TLS

Progress

It has been a while since my last post about Project Sputnik and so a quick progress report is definitely due.

I haven't had much free time to work on the project in this last month due to work activities and personal commitments. Same old same old, right?

That said, I have coded up the DAL layer for each database table in a basic form, and tested each unit. So, essentially, I now have a complete DAL for the project that performs the basic CRUD functionality. As I code up the BL and UI layers I expect that some of the DAL functionality will need to be honed in certain areas to provide extra functionality.

From here on in it is a Business Logic focus for me. For the next few weeks at least ...

Project Sputnik Solution Structure

A couple of posts ago I mentioned I would upload some screen shots of the Solution. Well here they are. Finally.

This shows the projects with the solution. You can see all the elements required, DAL Interface, the DAL, BLL, Concrete Classes and finally the Thick Client (WinForms app).

 

Focussing on the DAL, here are the DAL classes (one for each table in the DB)

 

 

And finally, the concrete classes (one for each entity)

 

 

 



Progress Update 2

The thick-client test harness I mentioned in the previous post was actually a "copy / paste" of the main Assets Form from the existing WinForms app into the new solution. The purpose of this was to prove the BL and DA layers actually provide the services that the final application(s) will need.

One thing that came out of this test was the fact that the old app has all the BL within the forms, so this logic had to be stripped out of the UI and then the (somewhat thinner) form coupled up to the BL layer. As I said this is just a test harness so this UI is not production code whereas the BL and DAL are.

I'm happy to report that the test form behaves as it should. However, I now need to do the same work with the exiting Asset Maintenance form so that I can test the BL and DA layers support creating new and updating existing Asset entities.

Rich Client UI

Moving on to the UI the final step in proving the traditional n-tier and DAL architecture is to have a WinForms application that references only the Business Logic layer. Throughout this p.o.c. I have only coded up the reading part of the DAL CRUD operation, the reason for that being one of brevity. I could of course go back and code up the full operation if I so desired, but in this case the p.o.c will remain just that.

I created a WinForms app and added a ListView control to Form1, setting the properties to detailed view and adding two columns. I then added a handler for the Load method of the form as shown below and added the code to read the assets from the database and display them on the “grid”.

using System.Collections.Generic;
using System.Windows.Forms;
using BL;

namespace UIAssetTestHarness

{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, System.EventArgs e)

        {
            // Load the grid with the asset data
            BLAssets assets = new BLAssets();
            List<UIAsset> assetsList = assets.GetAssets();
            foreach (UIAsset asset in assetsList)
            {
                ListViewItem item = new ListViewItem(asset.AssetTag);
                item.SubItems.Add(asset.Description);
                lstAssets.Items.Add(item);
            }
        }
    }
}

And that’s it. If I were to pursue this p.o.c any further it would be to code the BL layer as web services and have the UI consume those. I’ll be doing that later on.

Architecture Diagram 2

Here's an updated architecture diagram for Project Sputnik now that I am clearer in my own mind how I'm going to proceed.

It’s all gone quiet …

Apologies for the lack of recent posts. I've been travelling abroad over the last few days during which time I have had the pleasure of the company of a highly skilled Tech/Geek/Nerd friend.

Inevitably, during our travels, there were architctural discussions and even a brief coding session to prove concepts.

At last I have made my decision about the architecture, partiularly around the DAL, and now I think I am ready to move on. I will put my thoughts and plans into words and post again soon.

DAL Deliberations

Let me explain why the deliberations on the DAL are taking me some time to get through. This is what keeps going around in my head when I think about the structure of the DAL.

If I build the DAL as a web service, it will be globally accessible in a (programming) language neutral way and will support re-use and loose coupling. Great. However, it could end up being too complicated and slow and in addition multiple BL services would then depend on ONE service which sort of defeats the object of SOA (in a pure SOA architecture the services are independent).

So, should I pursue a pure SOA architecture and split the database into several (smaller) databases, one for each BL service and then have each BL service have its own Data Access logic? Surely this will lead to code duplication?

So then I head this way:
I should forego the pure SOA architecture and create a single data access DLL (the DAL) that would be referenced by each BL service. That way I would not have any duplication of Data Access code and given that there is a single database then any change in the database or DAL would result in a change to just the DAL (and maybe a BL service that required it). My BL would be decoupled from the database.

However, the same arguments could be said for making the DAL a service and not a DLL – each BL service would reference the DAL service (instead of a DLL). Equally, a single DAL DLL could end up being too complicated and slow.

And so round and around I go. I’m not normally this indecisive …

Architecture Diagram

I'm still pondering the architecture for Project Sputnik, but I am am settled on a (fairly classic) four-layer/tier solution (diagram below).

Still not decided on how the DAL will be structured though. I may draw up the different structures that I am considering and then share them all before I finally settle on one and move on.

Architecture

For the last couple of days I have been thinking about the architecture for Project Sputnik. It is important that I get it right so that it doesn't bind the development to a particular path or style but rather lends itself to casual stop-start, flexible development whilst providing a solid, scalable, adaptable structure to build upon.

That may seem like a lot of buzzwords thrown randomly about to make it sound like I know what I'm talking about, but that isn't the case. My time is precious & I will be developing this in my free time so rather than waste time developing, ripping up & restarting then re-developing, I want to do it only once.

I am particularly focussing on the data-access aspect of the architecture right now. I would like to get a single point of access if possible, even if the DAL comprises multiple classes, but a single place to work on/tweak/adapt for differing data providers would be ideal. My concerns about this concept though are around performance, particularly in a many user scenario.

I will continue my deliberations and research for now.