Application Architecture RRS feed

  • Question

  • User1402990982 posted

    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..




    Wednesday, September 25, 2013 5:44 AM


  • User2019981500 posted

    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

    Design Approach

    There are some facts about the N-tier architecture that should be kept in mind before deciding for this architecture for an application.

    • It normally takes more time to develop. Number of tiers should be decided in accordance.
    • The leveof interaction between different tiers and between components within a tier increases the path of communication, which may affect response time.
    • At the same time, capability of the same application to distribute itself on different processing machines helps make the best use of processing power.
    • For a reasonably complex application where maintainability and enhancements are foreseen, this architecture is just the right one.

    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:

    • An in-process component like a DLprovides faster access
    • An out of process component like an executable (EXE) involves marshalling and un-marshalling in communication with other processes, which affects the communication speed.
    • An in-process component crashes the caller process, in case of a criticaerror
    • An out of process server does not affect caller process directly in case of a criticaerror
    • Services that can instantiate at the time of machine start-up are usefuif their initialization and resource acquisition consumes substantiatime.

    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.

    System Monitor

    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.

    Message Persistence

    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 distributed architecture.

    Data Caching

    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.

    Object Pooling

    This strategy proves usefuin more than one ways as below:

    • Where object initialization or resource acquisition takes time, a pre-initialized pooof objects provides ready availability.
    • If some objects use expensive hardware resources, a managed pooof such objects ensures optimized use of these hardware resources also.
    • Poocan be configured flexibly to best suit its environment and dependent resources at any time.

    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.

    Connection Pooling

    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.

    Error Handling

    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.

    Distributed Transactions

    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.

    Two-Phase-Commit Protocol

    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)

    • A standard based on Unicode, provides globalanguage support.
    • Standard of data interchange across different platforms.
    • Text based syntax readable by humans as well as  computer.
    • Flexible and extensible, new tags can be added without affecting existing document structure.

    SOAP (Simple Object Access Protocol)

    • Lightweight and simple XMbased protoco
    • Used to communicate between applications via internet
    • Can be used with various internet protocols like HTTP, MIME, SMTP and a wide range of applications
    • Language and platform independent
    • Remote Procedure Calls (RPC) is used for communication between objects like DCOM and CORBA. Firewalls and proxy servers usually block this kind of traffic posing security and compatibility issues. SOAP is a good alternative for working across firewalls in web applications.

    XMand SOAP are widely accepted platform and language independent standards for data interchange and communication between applications via Internet.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 25, 2013 6:20 AM