Friday, October 28, 2005

A very good question answer session related to Architecture

We would appreciate any guidance you may have to offer on the following

  • From experience are there any particular areas that need attention up-front that might be overlooked?
Long discussion; will need a separate session for this.

  • Security – what measures have you taken to ensure that the application is secure?
Application security is not a short term task. Like other software development activities it should be practiced through out the SDLC.
In our mode of development, application security is a continuous process. Our process includes…
  • Application Threat modelling: At the beginning of project, we did application threat modelling. During this process we have identified and quantified the application threats and have established a security document. We encourage our developers to go through the check list on periodic basis

  • Establishment of secure development standards and team training

  • Verification of code security during peer reviews

  • What is authentication method is used?
We are using our own custom authentication mechanism. We have developed a generic portal application in which we can host our ASPX files. This portal provides mechanisms for application level user authentication and per resource authorisation. This portal provides role based security mechanism. Administrator can define different application roles and respective functions (web forms) associated with this particular role along with rights (can read, can edit etc). Then users can be associated with one or many application roles.
All passwords are stored in database after they are properly hashed with a salt.

  • How do you handle security - re: different levels of access to areas of the system?
Explained above.

  • Is a single user id used to access the main database?
Yes, during development phase. For testing phase we have proposed to create different users at database level with different sets of rights based upon high level user role (like FX trader should have right to access FX related tables).
In beginning we decided to create db users against every user in our application. But this dramatically reduces the possibility of connection pooling. So we dropped this idea. Other way around can be, create db users for particular role (there can be many users attached to a role). Authenticate a user using db user with minimum rights and then switch to db user who has enough rights to access data according to his rights.
There can be many possibilities. Please search for Microsoft Patterns and Practices.

  • If a single user is used, does it have restricted database access?
Explained above.

  • How is auditing handled?
None yet. We are currently evaluating procedures for it.

  • Portal Layout and Site navigation – what methods do you use to control site-layout?
We are just using CSS based application design.
I would highly recommend you to use Master pages and themes/skin features provided by ASP .NET 2.0. I wish we had this feature in ASP .NET 1.1.

  • Scalability – the application should scale to 500 users. What Load testing do you do and what tools do you use?
We are practicing standard routines to make the application scalable. Currently we haven’t done any load testing. The option that we have debated is to involve third party services who have the infrastructure and experience in this domain.

  • Testing of components / web application
Internal procedures are being followed like in case of QA, developing test cases, test case execution, bug reporting and rectification cycle. In case of developers we conduct peer reviews and unit testing.
We are not currently deploying any Test driven development approaches.

  • How do you achieve database independence? We have a large number (~ 100) of Oracle PL/SQL stored procedures which would have to be rewritten in Transact SQL.
We have developed our own database access layer making use of the design of ADO .NET. On database level, we strongly discourage placing business logic. We only create stored procedures for Querying and DML operations using standard SQL. There are scenarios where we needed to impart business logic in stored procedures, but this is very rare.
You will be using ADO .NET 2.0 which provides built in mechanism to achieve database independence. It provides creation of different objects (like connections etc) based upon factory pattern. It has some other exciting features which can be used to make an application more scalable. These features may include asynchronous reads and promote-able transactions etc

  • How do you achieve Multilanguage, multi locale, multicurrency support?
Currently our application is not multilingual and multi locale. However it is multi currency. However these features have been initially thought through and require a separate discussion thread.

  • How do you control paging?
Currently we are not, but when in future we will need it, we will do it at stored procedure level instead of at presentation tier. We have decided this while considering scalability issues.

  • Is anyone at Lahore using Visual Studio 2005 or planning to use it in the future?
At Lahore office, nobody is using it officially. At personal level, some team members of inBanking including myself have been using Visual Studio 2005 since its CTP releases. About future plans, I can’t answer this. You have to ask higher management/architects who are responsible for such decisions.

  • With Visual Studio 2005 Microsoft offers either the Team Suite or Visual Source Safe 2005 which of these will you be using and why?
Not a question for me, but if I am ever asked, I will vote for Team System. I have advocated this above.

  • Do you run the application under IIS 5.0 or IIS 6.0?
We are developing and testing our application using IIS 5.0.

  • Does the application only run under Internet Explorer or is it Browser independent?
We have recently run a cycle to make our application available in latest versions of four major browsers (MS IE, Fire Fox, Opera and Netscape).
We have also established a document explaining areas to focus on to make a web application (such as ours) browser independent. This document is currently in construction phase.

  • What were the main difficulties that you had to overcome in the development of the inBanking and ePOS products?
There were many issues and I think it require a separate discussion thread.

  • Are there any pitfalls that you can forewarn us of?
Should be carried out in separate thread.

  • We do not have much information on the ePOS product can you let us know aht it entails

  • We have copies of the TRAPEZE design document (2004) and TRAPEZE functional specification for the inBanking product. Are there more recent versions of these documents? Is the user manual for the product available.
No major revisions has been conducted as yet

  • How do you handle errors within the application?
We have developed our own exception handling and logging framework.
I would recommend you to visit Patterns and Practices section and check out Exception Handling and logging block. I recommend using this application block. We are evaluating switching to it as well.

  • GUI Design/Layout - have you used CSS? How difficult has this been? Should we consider using the new master template system within .NET 2005?
I strongly recommend you to use Master pages and skins/themes.

  • What tool is used to create layout? e.g. Dreamweaver, GoLive etc…
We use Dream weaver MX

  • What points should be borne in mind re: Scalability / Multiple users?
There can be many issues and I think it require a separate discussion thread. We have not documented any practices.
I personally think that such practices should be documented and should be made available at organisation level.

Here I would like to throw some light on what we are keeping in mind to achieve scalability…

  • Open connection only when it is needed

  • Open connection as late as you can

  • Close it as early as possible

  • Identify data which is rarely modified in database and establish data caching policy

  • In ASP .NET 2.0 you can even cache at web controls level

  • Do not place heavy objects in View State

  • Where ever it is possible, use typed datasets

  • Recommended deployment strategies

  • Establishment of session server

  • Establishment of web forms


  • How have you performed stress testing?
We are not currently performing any application stress testing.

  • When bolting onto an existing system that contains business rules logic, and new rules are required (e.g. governing user access in the web system), have these been separated from the main business rules?
Can’t get what you are trying to ask.

  • Does ePOS use the business rules of the underlying system or is it standalone?

  • Is security testing of the application done using automated tools or using 3rd party?
No automated tools are being currently used other then FX Cop. FX Cop is provided as built in feature in Visual Studio 2005. It not only provides mechanism to check the application code for known security issues but also tests the application for scalability issues, naming conventions etc.

  • Was the design of the GUI in-house or passed to 3rd party? Was a static prototype created initially for look and feel?
It is In-house production and there is no third party involvement.


  • How have you handled the control of web interface navigation

  • Turn off browser buttons?

  • Stop right clicking?

  • Expire pages to force a refresh?
Turning off browser buttons: can be done if you start your application in full screen and No buttons mode.
Stop right clicking: can be done quite easily using some java scripts freely available on internet.
Expiring pages: It is a very complex issue. Pages are cached at different levels in their life cycle and these levels may involve IIS itself, ISP, proxy and then at browser. If we set page expiry date in past, page is not cached at most of the levels. This is the only measure we are currently taking. For more information, please google this topic. I would love to hear feed back from you as well.

  • How are your ASP.NET projects organised? What file structure is used in the web app / project / source control?
Application level: All resource files are placed in logical grouping (using folders)
Project: Logical grouping
Source Control: Same as file structure but following the rules asserted by our QE department.

  • Are documents produced via the browser? If so how (e.g. PDF / HTML)?
None yet

  • Are Reports produced via the browser, if so how?
None yet

  • Does any data persist from session to session that is not stored in the main database (e.g. incomplete records)? If so how is this handled?
None

  • Is client side validation (i.e javascript) used or avoided?
I do not advocate the idea of avoiding client side validation. In our application we have used client side validation extensively. But since security rule number one is not to trust any input coming in, hence, we also validate it on server. In ASP .NET we can validate all the inputs by simply calling this.Page.IsValid.
I would highly recommend usage of Regular expressions to validate all the input fields. You should establish a separate infrastructure tier which should not only provide regular expressions to validate integers, doubles etc but also complex inputs where business rules are to be followed (like standards runs 3m, 6m and money short cuts 10m for 10 million etc)


Other pointers of interest:
  • Consider ATLAS (alias of AJAX, for asynchronous XML calls.), updating application UI without page refresh

1 Comments:

Anonymous Anonymous said...

Hey Farukh Ali Farooq, you have a great blog here! I'm definitely going to bookmark you!
I have a business mailing lists site. It pretty much covers business mailing lists related stuff.
Come and check it out if you get time :-)
Best regards!

12:43 AM  

Post a Comment

<< Home