Chapter2
- 2. Syllabus Two tiered client/server architecture Three tiered client/server architecture Stored Procedure architecture
- 3. Two tiered client/server architecture Purpose Two tier software architectures were developed in the year 1980. The two tier architecture is intended to improve usability by supporting a forms-based, user-friendly interface. The two tier architecture improves scalability by accommodating up to 100 users, and improves flexibility by allowing data to be shared, usually within a homogeneous environment.
- 4. Technical Detail Two tier architectures consist of three components distributed in two layers: client and server. The three components are User System Interface (such as text input, dialog, and display management services) Processing Management (such as process development, process enactment, process monitoring, and process resource services) Database Management (such as data and file services) The two tier design allocates the user system interface exclusively to the client. It places database management on the server and splits the processing management between client and server, creating two layers.
- 6. In general, the user system interface client invokes services from the database management server. In many two tier designs, most of the application portion of processing is in the client environment. The database management server usually provides the portion of the processing related to accessing data (often implemented in store procedures). Clients commonly communicate with the server through SQL statements or a call-level interface. Two Tier Architecture
- 7. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services. As compared to the file server software architecture (that also supports distributed systems), the two tier architecture improves flexibility and scalability by allocating the two tiers over the computer network. The two tier improves usability (compared to the file sever software architecture) because it makes it easier to provide a customized user system interface. It is possible for a server to function as a client to a different server- in a hierarchical client/server architecture. This is known as a chained two tier architecture design. Two Tier Architecture
- 8. Two Tier Architecture Usage Considerations Two tier software architectures are used extensively in non-critical information processing where management and operations of the system are not complex. Two tier software architectures require minimal operator involvement. The two tier architecture works well in relatively homogeneous environments with processing rules (business rules) that do not change very often and when workgroup size is expected to be fewer than 100 users, such as in small businesses.
- 9. Two Tier Architecture Maturity Two tier client/server architectures have been built and fielded since the middle to late 1980s. The design is well known and used throughout industry. Two tier architecture development was enhanced by fourth generation languages.
- 10. Two Tier Architecture Costs and Limitations Scalability. The two tier design will scale-up to service 100 users on a network. It appears that beyond this number of users, the performance capacity is exceeded. This is because the client and server exchange "keep alive" messages continuously, even when no work is being done, thereby saturating the network.
- 11. Interoperability. The two tier architecture limits interoperability by using stored procedures to implement complex processing logic. This means that to change or interoperate with more than one type of database management system, applications may need to be rewritten. Two Tier Architecture Costs and Limitations
- 12. System administration and configuration . Two tier architectures can be difficult to administer and maintain because when applications reside on the client, every upgrade must be delivered, installed, and tested on each client. The typical lack of uniformity in the client configurations and lack of control over configuration changes increase administrative workload. Two Tier Architecture Costs and Limitations
- 13. Three Tier Architecture The three tier architecture emerged to overcome the limitations of the two tier architecture. In the three tier architecture, a middle tier was added between the user system interface client environment and the database management server environment. There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers.
- 14. Three Tier Architecture The middle tier can perform queuing, application execution. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. In addition the middle layer adds scheduling and prioritization for work in progress. The three tier client/server architecture has been shown to improve performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach.
- 15. Limitation A limitation with three tier architectures is that the development environment is reportedly more difficult to use than the visually-oriented development of two tier applications
- 16. Three tier architecture with transaction processing monitor technology. The most basic type of three tier architecture has a middle layer consisting of Transaction Processing (TP) monitor technology The TP monitor technology is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client.
- 17. When the capability is provided by third party middleware vendors it is referred to as "TP Heavy" because it can service thousands of users. When it is embedded in the DBMS (and could be considered a two tier architecture), it is referred to as "TP Lite" because experience has shown performance degradation when over 100 clients are connected . Three tier architecture with transaction processing monitor technology.
- 18. TP monitor technology also provides the ability to update multiple different DBMSs in a single transaction. Provides connectivity to a variety of data sources including flat files, non-relational DBMS, and the mainframe Provides the ability to attach priorities to transactions robust security Three tier architecture with transaction processing monitor technology.
- 19. Using a three tier client/server architecture with TP monitor technology results in an environment that is considerably more scalable than a two tier architecture with direct client to server connection. For systems with thousands of users, TP monitor technology (not embedded in the DBMS) has been reported as one of the most effective solutions. A limitation to TP monitor technology is that the implementation code is usually written in a lower level language (such as COBOL), and not yet widely available in the popular visual toolsets. Three tier architecture with transaction processing monitor technology.
- 20. Three tier with message server Messaging is another way to implement three tier architectures. Messages are prioritized and processed asynchronously. Messages consist of headers that contain priority information, and the address and identification number. The message server connects to the relational DBMS and other data sources. The difference between TP monitor technology and message server is that the message server architecture focuses on intelligent messages, whereas the TP Monitor environment has the intelligence in the monitor, and treats transactions as dumb data packets.
- 21. Three tier with an application server The three tier application server architecture allocates the main body of an application to run on a shared host rather than in the user system interface client environment. The application server does not drive the GUIs; rather it shares business logic, computations, and a data retrieval engine. Advantages are that with less software on the client there is less security to worry about, applications are more scalable, and support and installation costs are less on a single server than maintaining each on a desktop client. The application server design should be used when security, scalability, and cost are major consideration.
- 22. Three tier with an ORB architecture Currently industry is working on developing standards to improve interoperability Developing client/server systems using technologies that support distributed objects holds great promise, as these technologies support interoperability across languages and platforms, as well as enhancing maintainability and adaptability of the system. There are currently two prominent distributed object technologies: Common Object Request Broker Architecture (CORBA) COM/DCOM (Component Object Model (COM), DCOM, and Related Capabilities) . Industry is working on standards to improve interoperability between CORBA and COM/DCOM. The Object Management Group (OMG) has developed a mapping between CORBA and COM/DCOM that is supported by several products.
- 23. Three tier architecture… Three-tier applications are much more difficult to build than two-tier apps. The biggest obstacle is that the software tools’ integrated development environments are not aware of the three-tier model. As a result, much more hand-coding is required to write a three-tier application. Three-tier apps are also harder to design, because they are somewhat abstract compared with their more direct two-tier counterparts. Software tool vendors are starting to release new versions for three-tier or n-tier development support, but it's not mature development technology just yet.
- 24. Stored Procedure Concept Stored procedures are user-written structured query language (SQL) programs that are stored at the data base server and can be invoked by client applications. A stored procedure can contain most statements that an application program usually contains. Stored procedures can execute SQL statements at the server as well as application logic for a specific function.
- 25. Stored Procedure Concept A stored procedure can be written in many different languages, such as COBOL, OOCOBOL, C, C++, FORTRAN etc. The language in which stored procedures are written depends on the platform where the data base server is installed.
- 26. Stored Procedure Concept Local client applications, remote Distributed Relational Database Architecture (DRDA), or remote data services can invoke the stored procedure by issuing the SQL CALL statement The client program can pass parameters to the stored procedure and receive parameters from the stored procedure. The client program and the stored procedure do not have to be written in the same programming language. For example, a C client program can invoke a COBOL stored procedure .
- 27. why use Stored Procedure? In previous releases of DRDA, the client system performed all application logic. The server was responsible only for SQL processing on behalf of the client. In such an environment, all database accesses must go across the network, resulting in poor performance in some cases.
- 28. This is a relatively simple model, which makes the application program easy to design and implement. Because all application code resides at the client, a single application programmer can take responsibility for the entire application. However, there are some disadvantages to using this approach. why use Stored Procedure?
- 29. why use Stored Procedure? Because the application logic runs only on the client workstations, additional network input/output (I/O) operations are required for most SQL requests. These additional operations can result in poor performance. This approach also requires the client program to have detailed knowledge of the server's database design. Thus, every change in the database design at the server requires a corresponding change in all client programs accessing the database. Also, because the programs run at the client workstations, it is often complicated to manage and maintain the copies there.
- 30. why use Stored Procedure? Stored procedures enable you to encapsulate many of your application's SQL statements into a program that is stored at the data base server. The client can invoke the stored procedure by using only one SQL statement, thus reducing the network traffic to a single send and receive operation for a series of SQL statements. It is also easier to manage and maintain programs that run at the server than it is to manage and maintain many copies at the client machines.
- 31. why use Stored Procedure? Stored procedures enable you to split the application logic between the client and the server. You can use this technique to prevent the client application from manipulating the contents of sensitive server data
- 32. Processing with Stored Procedures
- 33. Stored Procedure Concept The stored procedure can issue static or dynamic SQL statements. Data definition language (DDL), most data manipulation language (DML), and data control language (DCL) statements can be coded in a stored procedure.