Last post Sep 25, 2013 06:20 AM by shabirhakim1
Sep 25, 2013 05:44 AM|ragavASPNET|LINK
Thanks in advance
I created Solution for my N- Tier MVC Application AND I am just wondering how to to go for High Level Architecture like creating Components,classss..
Sep 25, 2013 06:20 AM|shabirhakim1|LINK
Here you need to think bit differently like you know type of application and now here are certain guidlines
from microsoft guide
Microsoft Application Architecture Guide, 2nd Edition - MSDN
There are some facts about the N-tier architecture that should be kept in mind before deciding for this architecture for an application.
Identifying Tiers and the Components Within
Design starts by identifying and demarcating different application tiers and their functionality. If there are multiple components within each tier, functionality for each component is identified thereafter. Provision for enhancement and maintainability
is to be kept in mind with each design decision.
Deciding the Component Type
There has to be uniformity at the system leveand a purpose behind choosing the type of a component. Whether it instantiates itself in-process, out of process, is a long running standalone service etc. Once the components ensure compatibility at binary levebetween
themselves they can be developed in the language most appropriate for their use.
Following are some features of different component types:
Identifying Interfaces of the Components
Interfacing between the components and tiers of the system becomes very important in a distributed architecture. An attempt is made that interfaces take minimum impact for any design change. Their thoughtfudesign provides a good foundation to the system
for future enhancements.
Component can expose its functionality to other components through one or more interfaces. Callback interfaces, a kind of interface, can be used for passing notifications from server to subscribed clients.
Generic Design Features
Below is some design features used commonly for a good n-tier application design.
Often a need for a System Monitor arises in a distributed architecture having multiple components. The initialization sequence during system start-up needs to be governed. Whole system should not collapse if there is a runtime error in one of the many components.
Providing a system monitor in such situations helps increase overalsystem resilience and availability. This component controls the start-up of the application and proper initialization of its components. Also at runtime it monitors the running status of each
component. In case a component crashes, system monitor can restart the specific component without bringing the whole system down.
If a separate monitor component is not favored for smaller systems, another way can be used to track the status of components in the system. Each component can have a 'ping' logic associated with it, which returns true to the calling components, if it is
up. Dependent components using the handle of this component can verify the running state of this component by pinging the component periodically. If a component has restarted in between because of some failure, the ping with the previous handle wilfail, indicating
that a new handle needs to be acquired by the dependent component.
If an application crashes during runtime, messages and data being passed from one of its component to the other get lost. Persistence of messages between components needs to be ensured in such cases. Options like that of using a message queue can guarantee
this. Simpler ways of persistence can also be used where message and data during inter-component communication are stored to a flat file.
Use of messaging in a distributed architecture provides asynchronous communication. This ensures that the 2 communicating components remain loosely coupled. Loose coupling is advantageous for easy and independent maintenance of different components in a
This is an important feature that helps improve application performance in a distributed architecture. Data that does not change too frequently, like reference data, can be cached in application levevariables instead of a fresh retrievafrom the database
every time. A frequency can also be set in the application logic to refresh data for example every 15 min. The validity of cached data can be checked against the set time intervabefore using it in such cases.
This strategy proves usefuin more than one ways as below:
Object pooling is preferred for stateless objects that can be used and reused between different clients. A flag in the object can denote its capability to pooitself after use by a client. In case an object becomes unusable because of something that has gone
corrupt internally, a dirty flag can be used to denote it. Such object will be removed from the pool. Even if an object carries state related data, this data should be cleared before restoring the object in the pool.
At start-up the poois populated with minimum number of initialized objects. Client requests are served on a first-come-first basis and new objects are spawned on request tilthe maximum poosize is reached. Once reaching maximum size, client requests are queued
tilan existing object becomes available in the pool.
In larger systems, the concept of Connection pooling can be implemented for database connections. This helps in optimized resource utilization. This feature is more helpfuwhen there is stateless data communication between the system layers and the database.
A pooof available connections is maintained with an upper limit set for the poosize. Connections are picked from the pooto serve a data request and restored back to the poowhen the job is complete. If a new request comes and poohas no available connections,
a new connection is created untithe maximum poosize is reached. If the upper limit is reached, the request is queued up tilone of the connections is available for reuse.
A centraError Logging and Handling component can be provided in a distributed system. It has access to the error - numbers and error messages of each component. Whenever an error occurs, that component reports the error to the centraerror handler. Error
handler that can be in the form of a simple file on the machine or the Event Log (e.g. NT Event Log) logs this error. Severity leveassociated with each kind of error can help determine the required action to be taken.
A transaction is characterized by its ACID properties:
Atomicity: Changes are atomic, following the principle of 'All' or 'None' for a set of operations.
Consistency: Data is moved between consistent states by a transaction.
Isolation: The intermediate operations of a transaction are not visible outside the transaction.
Durable: Once committed, the changes made by a transaction are guaranteed even if the system fails subsequently.
IndividuaResource Managers like RDBMS (SQServer etc.), MSMQ have the capability to perform ACID compliant transactions. The problem arises when we want to attain ACID operations in a distributed environment where a transaction is to be ensured between the
operations of different Resource Managers. It needs additionacoordination.
This gave birth to the concept of a Transaction Controller, which co-ordinates between Resource Managers to implement the two-phase-commit protocoused for distributed transactions. Below is an overview of this protocol. This protocois supported by many software
products like MTS (Microsoft Transaction Server), Websphere (IBM Application Server) etc.
It consists of 2 phases of communication between Transaction Controller and Resource Managers.
When an application initiates a Commit on the Transaction Controller, it in turn asks each Resource Manager if they can guarantee a Commit.
If all the Resource managers reply in affirmative, Transaction Controller asks them to Commit. If any of the Resource Managers replies in negative, Transaction Controller asks alof them to Rollback their transaction.
By responding in the affirmative to first inquiry, a guarantee is obtained from each Resource Manager that they will not faiif they were told to commit later. Resource Managers mostly use a Durable Log File for this.
Security services have to provide some basic functionality as below.
Authentication: When a user attempts to gain access to a computing system, it is first authenticated by its security service through a user ID and password.
Authorization: Once the user is authenticated, need for authorization comes up when the user tries to access any resource within this computing system. Security service determines if the user has been granted the privilege of using this resource.
It is normally handled by associating access controlists with resources, which define a list of authorized users or processes.
Data Privacy and Integrity: It has to be ensured that data sent over an open network has not been modified and is made available only to the authorized users. Security at the leveof data exchange in web applications widely use Secure Socket Layer
(SSL) authentication over network.
Security becomes a major issue in distributed architecture. At application level, login details are taken from a user before giving entry. Additionally each component in the application and the system resources specify their access rights. In Windows NT
a DCOM distributed component can specify its 'Access' as well as ‘Launch' permissions through Dcomconfg.exe. Different types of authentication and cryptography are used to suit particular needs for e.g. DCOM and RPC use Security Support Provider (SSP) libraries
for authentication and message encryption.
So what is next now...?
As the complexity of software applications has increased, platforms supporting distributed multi-tier applications have been widely favored. Web enabled applications having thin clients support this architecture strongly. Enterprise solutions further provide
a way to integrate applications built on different platforms. This has led to wide acceptance of platform and language independent open standards providing easy integration and communication between applications. Below is an overview of some of the latest
technologies and how they fit into the N-Tier distributed architecture.
XM(Extensible Markup Language)
SOAP (Simple Object Access Protocol)
XMand SOAP are widely accepted platform and language independent standards for data interchange and communication between applications via Internet.