Uppsala Master's Theses in Computing Science 166
2000-03-20 ISSN 1100—1836
The Design and Implementation of Scalable and Distributed Map Based Information System
Johan Isaksson
Information Technology Computing Science Department
Uppsala University Box 311 S-751 05 Uppsala
Sweden
This work has been carried out at IQDev
Dragonvägen 20A 757 56 Uppsala
Sweden
Abstract
The MBISystem has been developed to provide a platform for distributed and scalable map based information systems. A distributed GIS application puts many requirements on the design to achieve high performance and throughput. The Three-tier software architecture overcomes the limitations of the traditional two-tier architecture and increases performance, flexibility, maintainability, reusability, and scalability, while hiding the complexity of distributed processing from the user. The main advantages of three-tier development pertain to scalability since it is a tool for total system performance optimization. We recognize that MTS is a good technique, providing necessary infrastructure, but also several benefits in terms of scalability, reusability, security, transaction management, and database management. For small environments, however, MTS does not fully scale down since components under MTS produce a high execution overhead. Designing the application for best performance has been very much an issue of keeping resource usage low through resource sharing, fine tuning ADO parameters, and keeping the amount of state-keeping information low. A GIS application adds the complexity of handling map images efficiently since this issue has a great impact on the total application performance, limiting other efforts made to increase the performance.
Supervisor: Eric Kjellberg Examiner: Roland Bol Passed:
Contents
1 INTRODUCTION………. 6
2 OBJECTIVE……….……….…..………...………7
2.1 Basic Functionality…..………..………....………..………..7
2.2 Application requirements………..………...……….7
2.2.1 Graphical Interactivity………..………..………7
2.2.2 Distribution of platform components………..………..………... 7
2.2.3 Availability…….………..………..……….. 7
2.2.4 Scalability………..………..………..………..7
2.2.5 Performance………..………..………..…………. 8
2.2.6 Wide area of application………..………..………... 8
2.2.7 Flexible design………..………..………..………. 8
2.2.8 Extendibility………..………..………..………….. 8
2.2.9 Security and reliability………..………..………..……… 8
2.2.10 Easy to use………..………..………..…………...8
3 TECHNIQUES AND TOOLS………..………..………. 9
3.1 Two-tier architecture does not scale………...……….9
3.1.1 Smart Client………..……….…………..………...…9
3.1.2 Smart Server………..……….………..…………..…… 10
3.1.3 The Mixed Solution………..……….…………..……… 11
3.1.4 Conclusions………..………..…..…………...…… 11
3.2 Three-tier Architecture………..……….. 11
3.2.1 Abstracting data access logic………..………..…………...…… 12
3.2.2 Improved security………..………..……… 12
3.2.3 Fewer database connections………..………..……… 13
3.2.4 Minimize licensing costs………..………..……… 13
3.2.5 Design and performance………..……….…… 14
3.2.6 Problems with the Three-tier Architecture………..……… 14
3.3 MTS – Microsoft Transaction Server…….………..………..……….…. 14
3.3.1 Transaction activity………..………..……….………..……. 15
3.3.2 Apartment Treading………..……….………..………..…… 16
3.3.3 Just-in-Time Activation………..………..………….. 16
3.3.4 Resource Pooling………..……….…… 17
3.3.5 Connection lifetime………..……….. 17
3.4 COM and DCOM………..………..………. 17
3.5 ADO………..………..………..………..…….. 18
3.6 Microsoft Visual Basic……….……..……….….………… 19
3.7 SQL Server………….……..………..………..…..… 20
4 PERSISTENT DATA MODEL AND DATABASE DESIGN………..…………..………… 21
4.1 Data Model………..………..……….…..……… 21
4.2 Physical database schema………..………..… 23
4.3 Database table details………..………..… 25
4.3.1 Map table………..……….…………..… 25
4.3.2 TypeDef table………..………....… 25
4.3.3 TypeAttr table………..………..………..… 26
4.3.4 Location table………..………..………..… 27
4.3.5 Point table………..………..… 27
4.3.6 PointAttr table………..………..………..… 28
4.3.7 TextAttr table………...…..………..… 29
4.3.8 PictureAttr table………..………...………. 29
5 SERVER TIER………..………..………..………… 31
5.1 General Module - modGeneral………..……….……..… 31
5.2 General Utility Class - gUtility………..………..… 31
5.3 Transactional Server Package – MBISystemServerTr………..……… 32
5.4 Non-Transactional Server Package – MBISystemServerNonTr………..…… 32
5.4.1 Functions specific to the MapFetcher Class Module………..………..… 33
5.4.2 Functions specific to the InfoPointFetcher Class Module………..….. 33
5.4.3 Functions specific to the PointFetcher Class Module………..……….… 33
5.4.4 Functions specific to the TypeAttrFetcher Class Module………..…….. 34
5.4.5 Functions specific to the TypeDefFetcher Class Module………...…..…… 34
5.5 The Design pattern………..………..……..… 34
5.5.1 Record-oriented fetch operations………..……….…..… 34
5.5.2 Insert and Update………..………...……..… 36
5.5.3 Delete………..………..… 37
6 EXTERNAL DESIGN……….………..………....… 38
6.1 Record-oriented objects………..………...… 39
6.2 The InfoPoint object……….…..……….… 39
6.3 Set-oriented objects………..……….. 39
6.3.1 Returning data……….………..………..… 40
6.4 Point Attribute inheritance………..………..………..………… 41
7 INTERNAL DESIGN………..………..……… 42
7.1 MTS Resource Pooling……….………..………...…. 42
7.1.1 The solution………..………..……….. 42
7.1.2 MTS Context Object………..………..……... 43
7.2 ADO Recordset and use of database cursors………..………..……….... 43
7.3 Record-oriented fetching………..………..………...…. 44
7.3.1 MakeObject function………..………..……….. 45
7.3.2 Resulting Recordset………..………..………... 45
7.3.3 The complete code of Point.GetByKey………..……….… 45
7.3.4 Status variables………..……….…… 46
7.3.4.1 intState variable………..………. 46
7.3.4.2 blnDirty variable………..………..………... 46
7.3.4.3 blnToBeDeleted variable………..………..………… 47
7.3.5 SetNew function………..………. 47
7.3.6 Delete function………..………..………. 47
7.3.7 Accessing and changing data in objects………..………..…… 48
7.3.8 SetProperties function………..………..… 48
7.3.9 GetProperties function………..……….… 49
7.4 Set-oriented fetching………..………..………..………… 49
7.4.1 Build Collection………..………..… 50
7.4.1.1 Add function………..………....… 50
7.4.1.2 CreateRecordset function………..……….… 50
7.4.1.3 FilterField function………..………..… 52
7.4.1.4 The result………..………....… 52
7.4.2 Returning an ADO Recordset………..……….… 52
7.4.3 Returning an Array………..………...…. 53
7.5 The InfoPoint object………..………..………..……….…. 53
7.5.1 DisplayLocation state………..………...… 54
7.5.2 Fetching all InfoPoint objects for a Map………..……… 55
7.5.2.1 Method chosen for the GetAllPoints operation……… 55
7.5.3 Fetching all attributes for a Point………..……… 56
7.5.3.1 Using JOIN………..………..………… 57
7.5.3.2 Using multiple Recordsets………..……….…..…. 57
7.5.3.3 Using Stored Procedures………..………...…….. 57
7.5.3.4 Multiple SQL-queries………..……… 58
7.5.3.5 Comments………..………...… 58
7.5.4 Method Chosen for the GetAttributes operation……… 58
7.6 Managing PointAttr-, TextAttr-, and PictureAttr objects………..………..……. 62
8 ERROR HANDLING………..………..… 66
8.1 So far, what has been done? ………..………..……… 66
8.2 Error sources………..………..………..……….… 66
8.2.1 Database errors………..………..………..… 66
8.2.2 Input data errors………..………..………..… 67
8.2.3 Inter-tier communication errors………..………..……….… 67
8.2.4 Bad implementation of GUI………..………..………...…… 67
8.2.5 Internal errors………..………..………. 67
9 GRAPHICAL USER INTERFACE………..………..……….……… 68
9.1 Communication with Information tier………..………..……… 68
9.2 Supported functionality………..………...………..… 68
9.3 Basic components………..……….………..……….. 69
9.3.1 MBISystem UserControls………..………....… 69
9.3.1.1 UcrPoint UserControl………..……….… 69
9.3.1.2 UcrMap UserControl………..………..… 70
9.3.1.3 UcrInfo UserControl………..………...… 70
9.4 Event handling and component communication………..………..… 70
9.5 GUI state at startup………..………..……….… 71
9.6 Loading Map………..………..………..………..…… 71
9.7 Modifying objects in the Map collection………..……….… 72
9.8 Modifying objects in the TypeDef collection………..………..… 72
9.9 Modifying Point object………..……….…..… 73
10 DEPLOYMENT STRATEGIES………..………..………..… 75
10.1 Fat Server………..………..………...……… 75
10.2 Fat Client………..………..………....………… 76
10.3 Physical three-tier implementation………..………..……….… 76
10.4 Network deployment………..………..………...……..… 77
10.5 Internet deployment………..………..………..… 77
11 CONCLUSIONS………..………..………..………. 80
11.1 Did we meet Functional Requirements?………..………….. 80
11.1.1 Graphical interactivity………. 80
11.1.2 Distribution of platform components………. 80
11.1.3 Availability………. 80
11.1.4 Scalability and the role of MTS……….… 80
11.1.5 Performance……….……… 81
11.1.6 Wide area of application………..….. 82
11.1.7 Extendibility………..… 83
11.1.8 Security and reliability……….……… 83
11.2 Design weaknesses and possible improvements………. 84
11.2.1 The database……….. 84
11.2.2 Identifiers………..… 85
11.2.3 Going for Stored Procedures………...……. 85
11.2.4 The Server-tier & ADO………..………. 86
11.2.5 Returning and handling the resultset……….……….. 87
11.2.6 The map image………..………. 87
11.3 Extending the functionality………..…….. 88
REFERENCES………..………..……….…..……….. 90
ACKNOWLEDGEMENTS………..………..……… ..… 91
APPENDICES A1 GENERAL BASIC MODULE API REFERENCE………..……….… 92
A2 MBISYSTEM API REFERENCE………..………..…….. 94
A.2.1 Properties common for record-oriented objects……….… 94
A.2.2 Functions common for record-oriented objects………...………. 94
A.2.3 Class Module Map………..……….…..………. 95
A.2.4 Class Module TypeDef………..…………..………..………. 97
A.2.5 Class Module TypeAttr………..………..………..……. 98
A.2.6 Class Module InfoPoint………..………..……….…………. 99
A.2.7 Class Module Point………..………..……… 101
A.2.8 Class Module PointAttr………..………..………..………… 102
A.2.9 Properties common for Collection Class Modules………..……..…… 103
A.2.10 Functions common for Collection Class Modules………...…… 104
A.2.11 Class Module MapCol………..………..……… 104
A.2.12 Class Module TypeDefCol………..………..……… 105
A.2.13 Class Module TypeAttrCol………..………..……… 105
A.2.14 Class Module InfoPointCol………..………..……… 106
A.2.15 Class Module PointAttrCol………..………..………… 106
A.2.16 Class Module PointCol………..………..………..………… 107
A.3 GUI USER GUIDE………..………..……….…… 108
A.3.1 Contents………..………..………..… 108
A.3.2 To close the Information Window………..………..……… 108
A.3.3 To open a Map………..………..……… 108
A.3.4 To close a Map………..………..………108
A.3.5 Performing a simple search………..………..…………..………… 108
A.3.6 To create a new Map………..………..……….…… 108
A.3.7 To modify an existing Map………..………..……… 109
A.3.8 To delete an existing Map………..………...………… 109
A.3.9 To create a new Type………..………..……… 109
A.3.10 To modify the name of a Type………..……….…...…109
A.3.11 To delete a Type………..………..……….…… 110
A.3.12 To modify a Type Attribute………..………..…… 110
A.3.13 To delete a Type Attribute………..………...……… 110
A.3.14 To create a new Information Point………..………...……..…110
A.3.15 To modify the location of an existing Information Point……… 111
A.3.16 To modify the data of an existing Information Point………..… 111
A.3.17 To delete the location of an Information Point………..………….……… 111
A.3.18 To delete an Information Point………..……….….. 111
1 Introduction
Distributed computer systems play an important role among today companies business environments. Every aspect of the modern corporation—marketing, manufacturing, finance, and customer support —relies on its information technology assets. Today, many companies are providing services to their customers over the Internet. This has been fueled by the widespread availability of low-cost computers and access to global connectivity. Therefore, applications are used by a large number of people around the world who are connected to many applications and data servers via slow links. These characteristics create application requirements that strain the capabilities of traditional application architectures. Two-tiered applications that process their business logic either on client machines or in databases become quite slow when they receive heavy usage.
However, the transition to three-tier (or n-tier) development has come with some cost. The
development time increases because of the complexity of adding another tier. Fortunately, middleware such as MTS has been developed to automatically handle the details of application infrastructure, such as thread management, and the details of COM.
This new technology gives extended opportunities in the GIS (Geographical Information System) business area. Typical for GIS applications are the heavy information load, and the typically longer development time, because of the added complexity when handling the map image and location-bound information objects. Now, the new technology helps solving these problems, making it easier to create good GIS applications for large, distributed environments and many users, yet keeping the developing time on a reasonable level.
The MBISystem has been developed as a tool for presenting location-bound information. It expands map-market opportunities by making it quick and easy for anyone to create its own Information system or to access a map from any application, by integrating MBISystem components using ActiveX technology.
Therefore, MBISystem significantly reduces map integration costs and is expected to substantially increase the use of maps. It reduces the development time, which in turn increases the turnover of electronic map components. MBISystem makes it possible create applications that are independent of the geographical areas in focus, making it cost-effective to develop generic solutions for worldwide use. The MBISystem database can be quickly updated or expanded as new map details become available or as needs change.
But what are maps, especially on the Internet, useful for? MBISystem can be used for spotting of houses and properties for sale or let, map-based info service (e.g. local communities or city guides), tourist information (and - booking), and route planning. In other words, the options are numerous, and it helps making pages more alive and useful to the surfing community.
The MBISystem application uses a logical, three-tier, component-based architecture. The software is composed of component DLL:s, and allows a number of different deployments. Thus, MBISystem is flexible, and can be adapted to almost any environment. The key infrastructure services are the Component Object Model (COM), which provides the basic mechanism for component interaction, and Microsoft Transaction Server (MTS), which provides an execution environment for scalable server applications.
The application is built to be scalable. A scalable application is an application that may be installed in different environments, able to support an increasing number of users. It should not have to be rewritten for large environments, and it should not require excessively expensive hardware in small environments.
A truly scalable application is able to handle all different environments. It can be installed as a stand-alone application on single computer, on a LAN for a handful or perhaps a few hundreds of users, and a WAN or Internet for several thousand of users. The application should not have to be rewritten when going from one environment to another and the increased hardware level should be approximately proportional when increasing the capacity of the application. When adding resources such as servers, processors, sites and others to the application, it should be possible to reorganize it and distribute it, so it’s possible to take full advantage of the new resources. But, it should never be necessary to rewrite it! Therefore, scalability means the capability to scale up to larger environments, but also the capability to scale down to smaller.
As you can see, a scalable application is very flexible. Building an application for scalability means that we can guarantee that it is useful for a wide area of application, as long as the functionality makes the requirements. In other words, the concept of scalability includes many criteria for good multi-user platforms.
The MBISystem uses a unique structure of the information objects. This solution makes it easier to create unique Information systems, specially adapted to customers’ own use. Since the application should be able to support search functionality, the structure makes it easier to perform these operations, and therefore these operations will be less expensive, i.e. more scalable. Also, it increases efficiency of the update processing for an existing Information system.
This very first version of MBISystem is not a full-scale application; it is a prototype platform, for further development. It consists of a component-based, three-tiered architecture, supporting the basic functionality for map presentation. A simple Visual Basic interface as been developed, appropriate for desktop-, and LAN environments. The aim is, however, to increase the application and also support web-based clients. The
system can be adapted to such an environment, by adding a Java- or script- based client, supported by IIS (Internet Information Server).
This report thoroughly describes and motivates tools and techniques used. The general
implementation pattern is described, but interesting details in the implementation are described in greater detail. In the end of the report, there is a section describing the weaknesses of current design. This includes identification of bottlenecks and recommendations on how these weaknesses are overcome.
2 Objective
The aim for this project is to implement a scalable and distributed client/server platform for an interactive map based information system. However, during the work, we also put the focus on design issues general for three-tiered, distributed, and scalable application. The objective is not to produce a full scale application, including features for real “.COM” applications. The focus is to build a good platform for further develoment that can be extended in functionality meting what reality calls for. Lower layers are emphasized, while GUI is kept simple, offering access to the basic functionality of the platform.
The application must fulfil a number of requirements, putting constraints on the development process.
These requirements are fundamental when choosing the design of the platform and the methods and tools for the implementation.
2.1 Basic Functionality
The basic idea of this application is to create an information system based on a map. The information is connected to points on the map. The user can get information from this system by clicking on these points, or by using a search function. The information is presented on the screen. The information is fetched from an underlying database. It must be possible for a user to add, remove or update information in the database.
These operations should only available for certain authorized users.
2.2 Application Requirements
This section describes the requirements on the MBISystem application.
2.2.1 Graphical interactivity
The Map system should allow graphical interaction with the user. For example, when a user click on an Information object, displayed on the map image and the information will be displayed on the screen.
2.2.2 Distribution of platform components
The application should be designed and implemented to adapt to a wide range of environments and deployment alternatives. The application should be built in such way that the system administrator or integrators have the flexibility to deploy the application in many different ways. This flexibility will ensure that the application will continue to be useful as machines and network infrastructure change.
Therefore, it must be possible to distribute components of the platform between multiple physical machines. The application must be able to adapt to many different environments such as stand-alone desktop application, LAN, Intranet and Internet application.
2.2.3 Availability
In the stand-alone desktop environment the application only need to be available when this single user needs it. On the contrary, the Internet environment demands essentially 100% availability. Therefore, the application must be built for very high availability.
2.2.4 Scalability
Except for the stand-alone application, the Information system must be able to support a large number of users simultaneously. It is not really possible to predict when users will use the application. Also we don’t know how many users will connect simultaneously. The application must be able to handle a surge in clients connecting to the application. Also, we must assume that the client will be using the application during a long time, including long times staying idle. Therefore the application must be able to handle two types of increased volume: the application must be able to scale as demand from users increase, and the application must also be able to handle high volume periods. It must behave as if used as a stand-alone
desktop application. Also, it must not be prohibitively difficult to administer a large and distributed application, compared to administer a small stand-alone application.
2.2.5 Performance
Since the application enables graphical interactivity for the users, response time must be good – on the order of seconds at the user level. When designing the application we can make one important assumption.
The fetch operations are the must commonly used operation. The information stored in the Information system is very seldom changed compared to the number of fetch operations.
2.2.6 Wide area of application
It must be possible to adapt the information system to a wide area of information, both considering the contents and information media. The platform must enable user to customize each Information system (i.e.
map with information objects) to its specific needs.
2.2.7 Flexible design
The application must be able to adapt to many different environments. It must support, or by adding functionality, be able to support different environments such as stand-alone desktop, LAN, Intranet, and web-based environments. Therefore, the platform must be able to support different interfaces.
2.2.8 Extendibility
Components and objects of the application must be reusable and extendable, i.e. they must be general so they can be used in different contexts, but also easy to extend so that new functionality can be added.
2.2.9 Security and reliability
The demand on security and reliability are not of highest vitality; performance is more important. However, It must be easy to set different permission levels on the platform functionality. For example, not all users should be permitted to perform changes to the Information system, i.e. the user should not be allowed to access Insert-, Update- and Delete- functionality. Preferable, there should be at least two different levels, grouping the users into two categories: Administrator, and Customer1. The Administrator user has access to all functionality of the platform, i.e. he/she is allowed to make transactional operations (Insert, Update, and Delete) and perform ordinary search operations. The ordinary user (the Customer) is only able to perform search operations. Typically, there are only a small number of users that have the Administrator permission level, while most of the users have the lower Customer user level.
Later, it should be easy to extend the number of permission levels. Also, it should not be hard to modify the access rights for an existing permission level.
Reliability on the transactional level is does not have highest priority. A lost transaction is not a crucial error. The aspect of reliability that is of high importance is availability.
2.2.10 Easy to use
Not only the user’s graphical interface must be intuitive and easy to use; the programmer’s interface to the application must be easy to use.
1 The name Customer does not necessarily mean that the user actually is buying something. The name implies that this kind of user is a “external” user, using the services provided by the application (“Consumer of Services”).
3 Technique chosen
MBISystem was built using the three-tier architecture with following tools and technologies (all products of Microsoft®):
• The Microsoft® Visual Studio® development system - The Visual Basic® development system 6.0 - ActiveX® Data Objects (ADO) 2.1
• Microsoft Windows NT® Server 4.0 Enterprise Edition - Microsoft Transaction Server (MTS)
• Microsoft SQL Server™ 7.0 Enterprise Edition
• COM and DCOM.
In following sections these tools and techniques are discussed. The discussions include motivations on why these tools were chosen and their obvious benefits for this application.
3.1 Two-tier architecture does not scale
In order to understand the real advantages of the three-tier design we must first describe the traditional two- tier approach of the client/server model. The first sections describe different approaches of the two-tier architecture. We will find that all these approaches have several problems. We then describe how the three- tier approach can solve these problems.
The most common way of constructing a client/server application is to divide the application into a server and a client part. Suppose you have one central database. The database is capable to checking permission, data integrity and transaction integrity. It’s also capable of executing business logic.
Different kind of client programs may connect to this database and use its services. The placement of functionality, including so called business rules2, is a weakness in this model. You may place most of the functionality in the client (Smart Client) or in the server (Smart Server). You may also divide it between the client and server (Mixed Solution). There are drawbacks with all these alternatives.
3.1.1 Smart Client
The smart client approach stores business rules and logic in the client application. All data access logic is also found in the client. This approach utilizes all resources at the client level and frees precious resources at the server for data service, as shown in Figure 3.1.
The primary disadvantage of this approach is the distribution of functionality on the clients. The server will be unloaded, but the functionality is spread over a large number of physical machines. Updating the functionality would require redeployment of the entire client application, or at least the supporting DLL’s (Dynamic Link Libraries) on every client machine. This is not always easy. First of all it is imperative to find them all. Secondly, they must be changed in same way in every application. Also, the clients may demand a higher hardware level available on each machine. Therefore, it is critical that the hardware level is sufficient to handle the load that is being placed on each client.
2 A business rule is involves the so-called business logic. The business logic is the heart of the application, defining the actual functionality. Business objects are the core of the application design, performing the business rules. With Visual Basic, business objects are instances of Class Modules that are designed to represent the real-world “objects” with which the application is dealing.
Fig 3.1
The smart client approach
3.1.2 Smart Server
The smart server approach consolidates all the business and validation logic onto a central server. The advantage is obvious; the update/redeployment problem is avoided. Instead of updating the logic on each client, it must only be done once in the server. Only such modifications that would affect the contract between client and server would make reinstallation necessary3. Another advantage is that users no longer have permission to update the database tables. Therefore, no user can by mistake perform what should only be part of a transaction, forgetting to perform the other parts. However, with most of the functionality placed on the server, every request to the database will spend more resources. Server resources are often scarce, so managing them conservatively will gain a lot. With all the rules implemented as stored procedures and triggers, the server will soon be low on resources as the number of users increase.
Every client connecting to a central server needs its own database connection – two clients cannot share the connection. Every connection between a client computer and a database server like Microsoft SQL Server will demand server resources. For every connection the database server will consume memory.
In the case of Microsoft SQL Server every configured connection needs 37 KB of server memory.
Configuring the connection is already done when the user logs in to the database. In addition, every client logged in needs threads, processes and cache memory for data and temporary results. Compared to other databases, Microsoft SQL Server is quite modest in its memory demands, but if the number of users increases, a lot of memory must be reserved for connection configuration.
Fig 3.2
The Smart Server approach
3 Changing the contract between client and server should “never” be done, so rule control is immensely improved when all the rules are collected in one place.
Physical two-tier Implementation: Fat Client
Server tier Server tier SQL Server
GUIGUI
Client
Server Informatíon tier
Informatíon tier MTS
Physical two-tier Implementation: Fat Client
Server tier Server tier SQL Server
GUIGUI
Client
Server Informatíon tier
Informatíon tier MTS
Physical two-tier Implementation: Fat Server GUIGUI
Informatíon tier Informatíon tier
MTS
Client
Server Server tier
Server tier SQL Server
Physical two-tier Implementation: Fat Server GUIGUI
Informatíon tier Informatíon tier
MTS
Client
Server Server tier
Server tier SQL Server
3.1.3 The Mixed Solution
Dividing the functionality between the client and the server is possible. This division allows each piece of the architecture to focus on its core strengths. This approach is illustrated in Figure 3.3.
Once again, there are disadvantages to this approach. The update/deployment problem also occurs as in the smart client approach. In addition, the logic is distributed throughout the application at many levels, making it very difficult to maintain without good documentation. Even with documentation, it is most likely that both the client and server structures must be altered to upgrade the application.
Fig 3.3
The two-tier mixed approach
3.1.4 Conclusions
The architectural examples discussed are examples of the traditional two-tier design. This may be a very efficient design under certain conditions. For example, if the application not will need significant updates in the future, and the clients can handle more sophisticated applications, a two-tier smart client may be exactly what is needed. On the other hand, when the server machine is powerful or the number of clients will be limited, and even when the logic occasionally needs to be updated, the smart server is an option. However, the conditions favoring the two-tier approach may not occur. Business logic may be located in a combination of the client and the server application, but it may also be independent of both the client and the server. In this case, components that are independent of both the client and the server shall be used. These components can define all business services. This approach is called three-tier, n-tier or multiple-tier client/server architecture.
3.2 Three-tier Architecture
The three-tier solution is logically partitioned into an Application tier, reusable business rules and database services. All business services are placed inside small components that provide services to both the client application and the server application. These components are implemented as COM (Component Object Model) objects. They may be access from the client application using the DCOM (Distributed Component Object Model). Figure 3.4 illustrates the basic three-tier architecture and shows that these components can be distributed, running on multiple servers in the network. These components can also be placed on the application server if necessary. This approach is very modular, each component object providing different services to the application.
User Services are assembled in the Application tier. User Services deal with the interaction between the user and the application, as well as the preparation of data for user requirements. User Services are responsible for:
• receiving data input from users,
• packaging user input for further validation or server processing,
• data formatting,
• reporting,
• managing user preferences.
P h y s i c a l t h r e e - t i e r I m p l e m e n t a t i o n
S e r v e r t i e r S e r v e r t i e r S Q L S e r v e r
G U I G U I
I n f o r m a t í o n t i e r I n f o r m a t í o n t i e r
C l i e n t
S e r v e r S e r v e r M T S
P h y s i c a l t h r e e - t i e r I m p l e m e n t a t i o n
S e r v e r t i e r S e r v e r t i e r S Q L S e r v e r
G U I G U I
I n f o r m a t í o n t i e r I n f o r m a t í o n t i e r
C l i e n t
S e r v e r S e r v e r M T S
The Application tier allows user to access the application and to communicate with it. It communicates with rest of the application through the middle tier. The middle tier is the business rules holder and contains most of the functionality of the application. It is responsible for:
• business rules and logic,
• data validation,
• data access logic,
• transaction support.
The database services are placed in the third tier, called Server tier. The Server tier is responsible for the management of stored data. Here is the database, but also components that communicate with the database. These components isolate the rest of the application from details of database communication.
The responsibility of the security and integrity of the application is shared between the Information tier and Server tier. The information tier will check the users’ permission to execute operations of Information tier objects, while the Server tier will check the logged in objects’s permission to access data and possibly to execute database stored procedures. The Information tier will protect the integrity of the application by making sure that high level operations follow a prescribed pattern. The Server tier will protect table integrity and referential integrity within the database. Together they share the responsibility for transactional integrity.
Fig 3.4
Three-tiered architecture
3.2.1 Abstracting data access logic
The ability of Server tier to conceal implementation details about how database connectivity is being made is a very useful element of three-tier applications. Databases can be accessed in many different ways. The appropriate API of the database server, OLE DB, ODBC or any object models designed for simplifying the process of accessing database resources can be used. Also, new approaches are being developed all the time, thereby exposing the application to a obsolescence risk if the method of data access that is used, no longer is supported.
Using component objects, the actual implementation logic is placed in the component and by providing consistent public interfaces to the client and the server, the entire method of data access is concealed from the rest of the application.
3.2.2 Improved security
In the two-tiered architecture the database is the primary guardian of security. Different users receive permissions to do Select, Update, Insert and Delete in different tables and to execute stored procedures.
The three-tiered architecture offers a better solution. Instead of users logging on to the database, it is better to let the Information-tier objects log in to the database server, using their own identities. Users will not be permitted to operate directly on the tables. Only application objects are given such permissions. Instead the users are allowed to execute the components of the Information tier.
Internet Deployments
Server tier Server tier SQL Server
Server Server
Informatíon tierInformatíon tier
MTS Browser
Browser
Client
IIS
ActiveX Control / Java Applet Internet Deployments
Server tier Server tier SQL Server
Server Server
Informatíon tierInformatíon tier
MTS Browser
Browser
Client
IIS
ActiveX Control / Java Applet
Since the users are not permitted to operate directly on the database, we are protected from data inconsistency caused by any user. All operations on the database are done through the Information-tier objects. These objects implements operations that are “safe”, i.e. every operation follows a certain pattern maintaining the consistency of the database.
3.2.3 Fewer database connections
One result of this is fewer database connections. Few components will log in rather than many. Fig 2 shows how users log in to an Information tier server, and this server logs in to a database server, using its own identity rather than the identity of the user. Several clients may share the same connection to the database.
Thus, the load on the database server is considerably reduced. The database then gains the capability to support a larger number of simultaneous users.
Fig 3.5
Three-tier architecture means fewer database connections, through connection pooling. It also means increased security because only Information tier objects are allowed to log in.
But what happens if the number of users increase? Even with a three-tiered architecture, a database cannot handle indefinitely number of connections. The solution is to add servers in order to improve capacity. The good thing with well-implemented three-tiered solutions is that this can be done easily.
3.2.4 Minimize licensing costs
If the architecture is implemented across multiple physical machines, we have the option of moving the Information tier objects off the client workstations and on to a central application server machine. We might do this by putting the objects in an ActiveX EXE server and using DCOM, or we might put them into an ActiveX DLL server running within Microsoft Transaction Server.
By centralizing the Information tier objects on a separate Application Server machine, we've also centralized all the database interactions. This means that the clients don't need to have any direct access to the database, only to the application server.
This has a couple of benefits. First of all, we may have simplified the client desktop - since we don't need to install and maintain ODBC drivers and data connections out there. Also, suppose we have 100 client workstations: then we would have to buy 100 client licenses for our database. By using a centralized set of data services, we can let the clients share the connections to the database, thus reducing the number of client licenses that we need to purchase. Since most database vendors charge licensing on a per connection basis, we can save on licensing costs.
Information tier
Server tier Users
Connection Pool Shared Connections
Database
Users are logging in via Information tier objects State-keeping objects Information tier
Server tier Users
Connection Pool Shared Connections
Database
Users are logging in via Information tier objects State-keeping objects
3.2.5 Design and performance
One advantage to implementing three-tier design is that the modifiable components can be reused as libraries in a variety of applications. Another advantage is that deployment and updating are much simpler because the components only need to be implemented in one location (or just a few locations) on the network.
However, in the two-tier model, the entire application exists as two processes, one running on the client and the other running on the server. Three-tier (or multiple-tier) architecture changes this structure significantly. Elements of the application run in at least three processes, maybe even more, depending on the way the components are designed.
3.2.6 Problems with the Three-Tier Architectures
A three-tier, component-based architecture alone does not produce an efficient distributed application. High- performance, scalable, reliable server applications require a sophisticated infrastructure. One problem with three-tier architecture is simply a matter of network traffic. Instead of a single communication between client and server, there is communication between client and component, server component, and perhaps even component to component. This will obviously increase network traffic and reduce network response time.
This is not the only problem, however. All clients will be working with the same components. In the two- tier architecture, when every client was interacting with the server directly, it didn’t usually pose much of a threat. After all, large database servers such as Microsoft SQL Server and Oracle are designed to be scalable. Unfortunately, the components are not usually scalable to the same degree that the database servers are. This means that if implementing this design on a network with a very large number of users, the components will almost certainly create a bottleneck in the application. Therefore it is important to build components that scale. In many cases, this can be difficult.
Another problem is that while it is possible to define true atomic transactions at the data services level, there may be a need to have the same functionality in the business services level. There may be a group of components, designed to be used together. When any one component is used, it must be in progress (enlisted) in a transaction with other components. Each object sends its own independent data modification requests to the server, so these transactions cannot be enforced at the data services layer.
In order to overcome these problems, we need to implement support for complex transaction processing. This is a difficult work, adding a great deal of complexity to the design. Except for this functionality, we also need functionality for general data flow, not being part of the application as such.
Traditionally, application developers have needed to develop most of the code required to manage server processes, threads, database connections, and other resources, as well as security, administration, and other infrastructure code. The actual business logic is typically a small portion of the total application.
Infrastructure code is extremely complex and difficult to implement in a scalable fashion.
Middleware is a category of system software that provides infrastructure code to help build distributed applications. Standard middleware is the glue that enables independently developed components to work together to create distributed applications. Middleware masks the underlying system complexity from application developers and is a key enabler for the three-tier component-based application architecture.
Developers will also need to be able to access existing data and applications, regardless of the type of host system. Thus, a second enabler of the application architecture is interoperability services between the selected middleware and existing systems, such as standard interprocess communications protocols or application gateways.
Finally, developers will need access to development tools that facilitate use of the application architecture and middleware services. For example, tools might be able to generate framework code for components automatically, reducing the amount of hand coding that the developer needs to do. Debugging and troubleshooting tools are needed to help isolate problems occurring somewhere in the distributed application.
3.3 MTS - Microsoft Transaction Server
In the previous discussion, two primary complications in the three-tier design were identified: the inability of objects to effectively scale and the inability of objects to enlist other objects in atomic transactions.
Microsoft Transaction Server (MTS) was created to address these problems. According to marketing literature MTS is "a component-based transaction processing system for developing, deploying, and managing high-performing, scalable, and robust enterprise, Internet, and intranet server applications." To express it simpler, MTS makes developing distributed applications easy. Using MTS can save a lot of unnecessary work. In the Visual Basic, MTS components wrap up distributed application technologies into a package, insulating the developer from the complexity of the underlying implementation.
MTS is part of the Windows DNA4 initiative. Windows DNA is a framework for building three-tier, component- based applications that can be delivered over any network. The goal of Windows DNA is to unify PC, client/server, and Web-based applications around this common application architecture, which is suitable for applications of any size. Windows DNA is a strategy to writing applications using Microsoft technologies and products. Microsoft's goal is to provide the platform, component technology, application infrastructure, interoperability services, and tools needed to write all three tiers of the applications. The primary
technologies and products influencing the Windows DNA programming model are COM, MTS, UDA, ASP, DHTML, MSMQ, and COMTI.
MTS is an important technology for building an efficient distributed three-tier application. First of all, MTS can be used to manage all multi-tier considerations for a component architecture. In other words, MTS will provide support for sophisticated threading and multi-user support in the components. Secondly MTS extends transaction support from the Server layer into the Information layer. MTS makes it possible to enlist various components into true and reliable transactions.
To provide scalability to a component, MTS provides all services to manage multiple users, scaling resources, and other issues central to scalability. With the two-tiered client server approach, back-end databases such as Microsoft SQL Server™ or Oracle typically managed scalability, handling such things as managing connections, pooling threads, and monitoring transactions. With MTS the scalability issues are addressed by providing a standardized infrastructure or application framework. MTS acts as an Object Request Broker (ORB), automatically managing the creation and allocation of objects and threads.
In addition to supporting scalability, MTS supports transactions across objects. While Visual Basic has always been able to handle transactions with the BeginTrans, CommitTrans, and RollbackTrans methods, there has never been an easy way to coordinate nested transactions. MTS handles all of the details of nested transactions. The result is exposed in a single property no matter how complex it may be.
Another advantage of MTS is security. MTS defines a security model called package security. This approach allows the developer to assign a user identity to packages. This makes it possible for packages to act as virtual users. The packages can be thought of as a logical grouping of users. The package identity is given rights to perform any required activities on the underlying data sources. Then each network group user or group is given access to the components in the package as needed. This gives a great advantage.
Instead of managing security at many tiers throughout the application, MTS manages the security at the package level. This makes the administration much easier, as database security is only managed by granting access to the packages. The packages then act as a user filter to allow only qualified users into the database.
MTS resides on Windows NT Server and acts as a container for Information-tier components. By instantiating Visual Basic–created objects inside MTS, they automatically get access to all of MTS's services, exposed as a set of properties available to the component. This means that MTS manages the details of object lifetime, threading, transactions, and security.
MTS works well together with relational databases such as Microsoft SQL Server, Oracle, and Sybase.
MTS can also handle transaction between objects under Microsoft Windows and other environments, for example Unix.
The components installed in MTS are COM components, compiled to DLL’s. Consequently they will run in the same process as their clients. The client will always be a process that runs under the control of MTS.
These components can be built in any language capable of making COM components. In this project we have chosen to implement the MBISystem in Visual Basic5.
Coding the components to work with MTS is a jump-start on future technologies. MTS is the first part of the COM+ initiative that provides a distributed application framework for Microsoft Windows. Consequently, any components that are created for MTS are ready for COM+.
3.3.1 Transaction activity
MTS acts as a Transaction Processing Monitor (TP-Monitor). MTS creates, executes, and manages
transaction-processing applications and ensures that all of the requirements of a transaction are met. If all of the requirements of a transaction are not met, the transaction will fail to complete. MTS requires that all transactions adhere to a set of four general characteristics6 that must exist in order to complete the transaction. The characteristics are as follows (the ACID characteristics):
• Atomic. Either the transaction will complete in its entirety, or it will fail in its entirety. No element of a transaction will complete without the rest of the transaction.
4 Windows Distributed interNet Applications architecture
5 See section 3.6 Microsoft Visual Basic
6 Often called the ACID test.
• Consistent. A transaction is consistent if it resolves system and data state the same way every time and always leaves data in a state in which its integrity has been preserved.
• Isolated. Isolation is the ability to hide the work performed by one transaction from all other transactions.
• Durable. The result of a transaction must be a permanent modification to the database. It must be durable and fault tolerant to system failure.
The TP-Monitor model of MTS is build on a simple for form of the X/Open DTP model7. In MTS
environments, applications use the MS DTC transaction manager to coordinate transactions. MS DTC runs as a Windows NT service and is responsible for ensuring that all parties in the transaction are notified of the outcome (commit or abort) and coordinating recovery from failures. Each server machine in a distributed system can have a transaction manager. MS DTC uses OLE Transactions protocol (instead of the X/Open protocols) to communicate with other transaction managers or to local resource managers. The resource manager makes sure that the ACID characteristics are guaranteed, and consists of functionality to commit updates to a resource, roll back changes in the case of an aborted transaction, and recover from system failures.
Resource dispensers are another part of MTS that can choose to participate in transactions. Resource dispensers manage non-durable state that can be shared – for example database connections. They expose two sets of interfaces: an API for applications when using resources, and the other is used to connect with the MTS Resource Dispenser Manager (DispMan). DispMan provides resource pooling for the resource dispenser, and ensures that resources supplied by the resource dispenser are correctly enlisted in transactions. MTS supports two resource dispensers that are visible to developers. The ODBC Driver Manager is a resource dispenser for ODBC database connections. The other is the Shared Property Manager (SPM), which is used for shared data.
MTS-managed processes exhibit a behavior known as failfast. Failfast behavior means that if the MTS component detects an error in its internal data structure or a problem with one of the objects under its control, it immediately terminates the process. When the MTS process is restarted, it does not try to re- create the state of the object. Instead, MTS relies on the fact that transactions using those objects will time out and then abort. This design protects MTS and its components from data corruption.
3.3.2 Apartment Threading
A component contains many methods and resources that are accessible from client applications. However, in a single-threaded component, once a client connects to the component and automates it, only one thread execution is allowed to access the functionality of the component. This means that once a client automates an instance of a single threaded component another client can’t use the component’s resources. Either another instance of the component must be loaded or the client must simply wait for the component to become available.
The apartment-threading model of components divides a component into apartments, each providing the functionality of a single method of the component. Although only one thread can execute inside of an apartment (i.e. method), every apartment gets own thread, allowing multiple clients to use the component as long as they are using different methods of the component.
MTS manages the calls to the individual apartments of the component. The developer makes calls to the MTS components in exactly the same way as it makes calls to a single-threaded component. MTS manages the process of resolving these requests as well as the process of one apartment calling another apartment.
3.3.3 Just-in-Time Activation
When working with standard components, a client application will create an instance of the component and hold that instance open during the process of the working with the component. The component is held open and occupied through the duration of this entire cycle, which might include many method calls to the component. This means that the resources occupied by the component are held even during significant amount of idle time.
When MTS manages components, a client call to create an instance of a component does not necessarily allocate those resources immediately. MTS will create an instance of the component only when necessary, preferring to route the request to other running instance of the component that are currently servicing other client requests. When components must be loaded or threads created, this will occur “just-in-
7 The X/Open is part of The Open Group. The X/Open DTP model was introduced in 1991 and encompasses the standard features of most TP-Monitors.
time” to satisfy a client request. This means that a component may actually be loaded and unloaded many times during the time that a client application presumably holds that component open.
3.3.4 Resource Pooling
Components use more resources than just memory. For a component to perform its work, it may need other resources such as threads and database connections. These resources can be very costly in terms of system resources. For example, when a client application or component attempts to retrieve data from a database server such as Microsoft SQL Server, it must do so through a database connection. Since database connections require a lot of memory8 on the SQL Server, the number of connections is restricted by the server configuration.
Unfortunately, clients rarely use database connections as efficient as they should. To keep the application more responsive, database connections are often acquired early and released only when all database processing is complete. This means that the state of the database connection is often idle, wasting capacity that could be used by another client.
MTS manages all database connections as well as other resources, allowing them to be pooled and used more efficiently. Rather then each component requiring its own threads or database connections, these resources are managed by MTS, allocating them to components when needed, thus reducing idle time and increasing the maximum utilization of each resource.
3.3.5 Connection lifetime
With MTS resource pooling, the actual lifetime of ODBC connections created and released is controlled by MTS. In managing connection lifetimes, MTS takes into account whether a connection is in use and/or associated with a transaction in progress (enlisted). MTS does not terminate in use or enlisted connections, but moves them into the Unenlisted Inventory category once their associated transaction ends. MTS terminates not in use, unenlisted connections if they remain unused longer than their timeout interval—a property initialized by the ODBC driver when the connection is created.
3.4 COM and DCOM
MBISystem implements the business objects of the middle tier as COM components. This isn’t absolute requirement, but in Windows environment it is almost necessary. When using Microsoft Transaction Server it is a must. Today it is very rare that for a Windows program or a Windows tool not to be able to communicate with COM components.
COM (or Component Object Model) is simply a specification that describes the way that objects look on the outside and how they communicate with each other programmatically. If an object is COM compliant, it will expose interfaces that can be used to access the functionality of the object.
Each interface contains methods. Some of these methods provide the functionality of the component.
Other methods provide the ability to call other components or to expose additional functionality to callers.
MTS components are COM compliant and are written as in-process objects. This means that when they are called by a client application, they run in a process environment provided by MTS, not their own process space.
To sum up, COM offers five main advantages:
• Binary compatibility. Any programming language that can create structures of pointers and explicitly or implicitly call functions through pointers can create and use COM components. COM components can be implemented in a number of different programming languages and used from clients that are written using completely different programming languages. COM ensures complete binary compatibility between the client developed in Microsoft Visual Basic and the components developed in other languages, such as C++ or Java.
• Cross-platform interoperability. Developers need to write COM components for a specific platform, such as Windows NT or UNIX. A COM component written for a specific platform will not run on another platform, but can communicate with COM objects running on other platforms. A COM component can be built for many platforms, including Windows 95, Windows NT, Macintosh, and UNIX.
8 In the case of SQL Server, the connection needs 37 KB of server memory, just to connect. In addition, every logged in client needs threads, processes and cache memory for data and temporary results.
• Location transparency. Location transparency means that a component can be called by a client in one way, regardless if the component is in the same process, in a different process on the same computer, or in a process on a separate computer.
• Code reusability. COM offers an enhancement of the DLL technology. COM components contain classes that expose groups of methods, through which clients interact with objects. Because these interfaces are documented, many clients can reuse code that implements those interfaces.
• Version control. COM components are said to be self-versioning. Interfaces implemented by classes are static and, once defined, cannot change. New functionality can be added to a COM component by adding a new interface to a class while still supporting old interfaces. The implementation of an old interface can be changed without affecting clients that already use the class.
DCOM extends the functionality of COM by allowing components to communicate remotely via LAN, WAN, or the Internet. Therefore, ActiveX is no more than another representation of a DCOM object. ActiveX controls are designed to facilitate distribution of components over the Internet and provide integration of DCOM components into Web browsers (specifically Internet Explorer). DCOM-based applications can also take full advantage of Microsoft NT security mechanisms. DCOM is a necessity when using MTS (and also IIS), since both these technologies relies on DCOM for remote communication.
3.5 ADO
The ActiveX Data Object model (ADO) exposes an interface to the OLE DB object model. The OLE DB object model consists of functionality through COM interfaces that are not Automation compatible. This means that OLE DB cannot be used directly from many programming languages and tools including Visual Basic. Therefore ADO defines an application-level programming interface. All ADO interfaces are dual interfaces, so any COM-aware programming language or tool can use them.
Microsoft has introduced several object models for data access over the years. DAO consists of Automation objects for accessing the Microsoft Jet database engine used by Microsoft Access as well as ISAM and ODBC databases. RDO consists of Automation objects for accessing relational ODBC data sources. These technologies are supported by Visual Basic 5.0 and 6.0. However, while these technologies will continue to be supported, ADO is where future development efforts will be focused.
The ADO object model is shown in Figure 3.6. As already mentioned, ADO is built on top of OLE DB object model and is similar to the OLE DB object model. Unlike DAO and RDO, the ADO object model is not hierarchical. All objects except for Error and Field objects can be treated independently. This feature makes it easy to reuse objects in different contexts. It also means that often there are several ways to accomplish a particular programming task.
The Connection object represents a unique session to a data source. Connection is essentially a combination of the Data Source and Session objects in OLE DB. Connection objects expose an Execute method that gives the ability to perform simple tasks with a minimal amount of effort. Alternatively, Connection objects can be attached to Command and Recordset objects, which also offer methods to access data from the data source.
Command objects in ADO are equivalent to OLE DB Command objects – both provide a way to prepare and execute parameterized commands against the data source. Preparing a command saves a processed form of the command that can be executed quickly on demand. A Command object has a Parameters collection, which contains one or more Parameters objects, each representing a command- specific parameter. ADO Command objects are available only when the underlying OLE DB provider implements OLE DB Command objects.
Recordset object is the heart of ADO. Like OLE DB Rowset objects, they represent tabular data from a data source. Connection and Command methods that return data from the data source. Connection and Command methods that return data from data source return read-only Recordset objects that can be accessed sequentially. More flexible Recordsets can be created directly by the programmer, connected to Connection and optionally Command objects, and populated by calling various Recordset methods.
Recordsets support a variety of options for controlling the amount of data received from a data source at a given time. Other available options control the type and duration of locks placed on the underlying data source and specifies when updates are applied to the data store.
Recordsets objects logically consist of sets of rows and columns. At any given time, a Recordset refers to the set of columns of the Recordset are accessed through its Fields collection, with one Field object for every column. Associated with every Recordset is a cursor. The cursor in a Recordset indicates the current position in the Recordset and determines what row will be returned next. ADO supports several cursor types, ranging from simple forward-only cursors, to cursors that makes it possible to move to any row, to cursors that makes it possible to view changes made by other users when moving through the Recordset.
Fig 3.6
The ADO object model
Although ADO Recordsets offer access to only one row of data at a time, this does not mean that a
Recordset must access the underlying data source every time the cursor moves. Internally, a Recordset can cache multiple rows of data. This caching capability is an important part of building scalable distributed applications. A disconnected Recordset is simply a Recordset object that has been dissociated from its Connection object. Disconnected recordsets do not retain locks on the underlying data source. Instead, all the data for all the rows are cached with the Recordset. If a Recordset is modified and the changes are saved back to the data source, OLE DB checks each modified row for conflicting updates in the data source – in other words, it checks each modified row whether someone else has modified the row since the Recordset was cached. If so, a conflict is reported to the application so that it can decide what to do.
A client-side cursor engine for disconnected recordsets is provided. ADO also provides a very efficient service for marshaling recordsets between machines, over either the Internet or an intranet. This means that a server application can generate a set of data and copy it to a client application and the client application can browse data as if were connected to the actual data source.
Early versions of ADO and OLE DB scale poorly in multithreaded clients that use connection pooling.
These shortcomings can greatly affect the performance of MTS components. Microsoft Data Access Components (MDAC) 2.0 or later contains fixes for this problem.
3.6 Microsoft Visual Basic
Microsoft Visual Basic is a fast and easy way to create applications for Microsoft Windows. Visual Basic provides a complete set of tools to simplify rapid application development. The "Visual" part of the name refers to the method used to create the graphical user interface (GUI). Rather than writing numerous lines of code to describe the appearance and location of interface elements, the GUI can be built using prebuilt objects, simply dragged and dropped into place on screen. The "Basic" part refers to the BASIC (Beginners All-Purpose Symbolic Instruction Code) language. Visual Basic has evolved from the original BASIC language and now contains several hundred statements, functions, and keywords, many of which relate directly to the Windows GUI. The language provides tools that have the power to accomplish anything that can be accomplished using any other Windows programming language.
The Visual Basic programming language is not unique to Visual Basic. The Visual Basic programming system, Applications Edition included in Microsoft Excel, Microsoft Access, and many other Windows applications uses the same language. The Visual Basic programming system, Scripting Edition (VBScript) for Internet programming is a subset of the Visual Basic language. Visual Basic has many useful tools.
Some of them are:
• Data access features to create databases and front-end applications for most popular database formats, including Microsoft SQL Server and other enterprise-level databases.
• ActiveX™ technologies to use the functionality provided by other applications, such as Microsoft Word processor, Microsoft Excel spreadsheet, and other Windows applications.
• Internet capabilities make it easy to provide access to documents and applications across the Internet from within the Visual Basic application.
Connection
Command
Recordset Fields
Errors
Parameters Connection
Command
Recordset
Fields Errors
Parameters
