Case Study: Demo Networking Financial System

Besides understanding the more mundane aspects of C# and the .NET framework, you need to be well familiar with .NET REMOTING, Database (MS SQL), .NET Cryptography, SOAP, XML, ASP.NET and ADO.NET to follow this article and the corresponding code easily. Familiarity with the financial world is advantageous.

Objective

• The advent of C# and .NET has alleviated the design and development of applications to a completely new and MUCH BETTER!! Platform.
  
• In this article I will discuss some of the design and development issues that one might consider when using .NET framework for developing Network affiliated applications.

The sample application is developed with the following issues in mind:

• Develop reusable components including the REMOTING and Cryptography modules;
  
• Provide easily configurable framework for local network access and develop components that could easily be reused to develop web services and applications accessible over the internet; and
  
• Provide a framework that better addresses performance and post release maintenance and enhancement issues.

Technology Coverage

• The implementation of the sample has touched almost all aspects of C# and .NET. These mainly include:
  Serialization, Marshalling By Value and By Reference (MBV and MBR), Call Contexts, Threading, Events, Delegates, Reflection, Custom Attributes, Unsafe code (for including C++ style memory access), Remoting, Cryptography, UI and Configuration.
  
  
• For obvious reasons of space and for the sake of avoiding repetition, the detailed account of the underlying technology behind the code is not discussed. The discussion focuses on the design and implementation issues surrounding the overall framework of the application.

Overall Layout

• The application contains three major components; namely; Client side components, Server side components (remote objects) and secured Transport and Messaging components.
  
  
• The overall relationship between these components is depicted below:

The components are organized in the following assemblies:

Client Side Components

• NefsWIndowsClient: This is a Multi Document Interface (MDI) assembly that includes the main user interface routines and helper objects, namely; Event Monitor, Event Manager (in NeFsModuleManager.cs file), Menu Builder and other utilities in NeFsWinUtilities.cs file.
  
  
• NeFsClientDataAccessComponent: This assembly includes objects that easily map the underlying data access routines to the user interface. (More about it latter in the Data Access design section) .

Remoting and Cryptography

• NeFsCryptography: The assembly includes the main RSA and Message Digest 5 (MD5) based crypto service provider. It also includes public/private key manger that allows the user to generate and manage public/ private keys used to digitally sign messages during encryption and enable to verify decryption processes for message-key integrity during channeling messages across the network.
  
  
• NeFsSerializableLogicalObjects: The assembly contains Serialisable and Call Context objects. These objects are included to enhance client-server communication.
  
  
• NeFsRemoting: The client/server channel sink and formatter providers and the corresponding channel and message formatter sinks are included in this assembly. In addition to this, the assembly also includes an interface that is used as a metadata by the client to identify the underlying accessible methods and fields of the remote object.

Server Side Components

• NeFsServer: This is an executable console program that initialises the server.
  
  
• NeFsAnalytics: This assembly contains the basic option pricing models included in the sample application. These are: Trinomial option pricing model for pricing American Options, Monte Carlo Simulation and Black Sholes pricing models for evaluating and pricing European type options.
  
  
• NeFsDataAccess: This assembly includes the underlying data access objects and methods.
  
  
• NeFsRemoteObject: This assembly includes the underlying remote object. The object is a MBR object. It is currently configured as a WellKnown object. It could easily be configured to be either Client Activated or Singleton.

Other Helper Classes

• NeFsTrace: Provides Console, Windows Event Log and File based trace outputs.
  
  
• NeFsUtility: Provides I/O manipulation, random generator and secret key comparer helper methods.

The User Interface (NefsSystem.WindowsClient)

• The user interface is organized into different controls mapping to the services provided by the server. The main object of the current exercise is to show how accessing remoting components could be accomplished using .NET framework. The GUI is designed with this object in mind.
  
  
• The interface includes two different levels of access menus. The first level enables the user to administer users, manage keys, manage configuration and allow to login to the system. The second level provides a direct access to the main application components of the remote server.
  
  
• The relationship amongst the different components of the user interface is managed using tailored classes NeFsEventArgs, NeFsEventMonitor, NeFsEventManger, BuildMenu, MenuArgs,and NeFsGraphicHelper. I will leave the details for you to go through it as most of the stuff is very straightforward.

The Remoting and Cryptography Assemblies

These assemblies are written as an independent component and can easily be plugged into other networked applications that make use of the secured Remoting architecture of the .NET framework.

• The remoting component includes the following client/server classes:

• The .NET framework remoting architecture largely influences the implementation of these classes.
  
  
• The sink and format providers implement IClientFormatterSinkProvider,IClientChannelSinkProvider and IServerFormatterSinkProvider, IServerChannelSinkProvider of .NET respectively.
  
  
• The corresponding client channel and formatter sinks implement IClientFormatterSink,IMessageSink,IClientChannelSink,IChannelSinkBase interfaces. While the corresponding server side sinks implement IServerChannelSink interface.
  
  
• The implementation of the classes is largely the same across both client and server. For the sake of illustration I will discuss the server side code in brief below:
  
  
• When the server is initialized via NeFsServer.exe application it picks the following runtime information from the configuration file (NeFsServer.exe.config) :
  o TraceFile, TraceLevel, PrivateKeyFile, the sink provider (NefsServerChannelSinkProvider), the NeFsServerFormatterSinkProvider custom formatter and either SoapServerFormatterSinkProvider or BinaryServerFormatterSinkProvider. Either formatter can be used alternatively in this context if the system is run on local network.
  
  
• When initializing the sink provider object we collect the relevant information from the configuration file using a Dictionary object passed to the constructor as shown in the code fragment below.

The channel sink provider initializes the ServerChannelSink using

• When message is passed from the client the ServerChannelSink Processmessage method receives the message and applies the NeFsCryptoService provider methods to decrypt the message and pass it to the ServerFormatterSink Processmessage method that processes the message by invoking the relevant remote methods as is indicated by the transparent proxy object that resides in the client.

• Note that the order of message processing in the client side is the reverse of the order of message processing in the server side.
  
  
• To track the process more easily, a trace object is included. The relevant information of the transport headers, messages and the stream at each point of execution are dumped on the console screen for the server and on the output pane of Visual Studio for the client. Closely examining the output will provide more insight into the working mechanism of the underlying transport and message sinks discussed above.
  
  
• The Cryptography assembly implements four classes. These are:
  NefsCryptoServiceProvider.cs: This class implements the encrypting and decrypting methods using the private/public keys passed to the methods as an argument. The process of encryption and decryption is briefly discussed below for the sake of clarity.

Encryption

• The private key (obtained from the configuration files) is passed to the object during initialization.
  
  
• The NeFsEncrypter method is called by the channel sinks with the stream of data to be encrypted and the public key as shown in the code fragment below.

• The NefsSecuritySigner signs the encoded data. It uses the private key to sign the Xml Document version of the data stream and returns an Xml Element.
  
  
• The signed data is further scrambled using randomly generated bytes obtained from .NETs PasswordDeriveBytes object using randomly generated array of bytes namely; secret key, iteration and ID. These bytes are formatted using RSAPKCS1KeyExchangeFormatter and the public key.
  
  
• The result is stored in tailored objects namely; NefsSignedData and NefsData structure.
  
  
• These wrapper objects will finally be serialized in a stream using .NETs XmlSerializer and returned to the caller channel.

Decryption

• The process of decryption is the reverse of the encryption process.
  
  
• We first de-serialize the NefsSignedData object from the Xmlized stream.
  
  
• Using the RSAPKCS1KeyExchangeDeformatter(prvKey) key exchange deformatter we de-format the keys used to scramble the Xml element. Note that we are using the private key of the encrypters public key that is used to format the key. (If the client and server private/public keys are out of sink we are in trouble. That is why we have the Key Store Manager in place. See below)
  
  
• Using the keys we unscramble the data.
  
  
• We pass the unscrambled data to the NefsSecurityVerifier method to extract the public key and the signed data from NefsSignedData object.
  
  
• We verify data-key integrity and return the decrypted data stream to the caller channel sink.
  
  
• More hands on exercise and observation of the trace output, hopefully, will provide you with more insight into the coding and working mechanism of the crypto process.
  
  
• NefsSignature: is an internal class that provides signing encoded data and verifying decoded stream of data. (The role of this class is as explained above in the encryption and decryption processes).
  
  
• NeFsKeyManager: provides basic object serialization functionality. Using the SoapFormatter of .NET it serializes a hashtable object containing private/public key strings into a file stream. In addition to this it provides Add, Remove and other methods. The class along with the corresponding Key Manger interface at GUI level allows the secret keys of the client and the server to be in sink at all time.
  
  
• NefsScrambler: Provides a simple message scrambling facility. The scrambling is based on cryptic dynamic secret parameters that are generated at the client and server side and exchanged across using the .NET Key exchange formatter and de-formatter classes mentioned above.

Data Access Assemblies

Design Issue

1. The design of the data access component addresses the following three issues:

• Mapping the underlying objects of the relational database to the application objects;
• Optimization of performance within the remote data access context; and
• Provide a framework that will nullify or at least minimize the change in the code and the underlying data access structure due to post-release or enhancement changes in the underlying database.

2. C# and the .NET framework include a number of complex architectures that allow us to integrate data access components to the application in either disconnected or connected fashion to the underlying database.

3. However, I found it a bit daunting when it comes to mapping relational database structure to the more complex data access facilities provided by .NET framework. (HOPE I AM NOT ALONE ON THIS!!!!!!)

4. The option that I followed is depicted in figure 2.

Figure 2: Data Access Component

5. The implementation classes that are mapped to the data tables inherit from the NefsDataEntity abstract class and implement the NeFsDataAttribute class custom attributes. (See Code fragment below)

6. The implementation classes simply get the attribute values and delegate the method execution to the static methods of NeFsDataAccess class.

7. The NeFsDataAccess object using GetAttributes method resolves the arguments of the methods (Load, Update, Save, create Relation etc) and returns that to the caller implementation class which in turn passes that to the client.