|
An Overview of Borland MIDAS:
Multi-tier Distributed Application Services Suite
Solutions for middle-tier application server developers
 Overview
Borland MIDAS Feature Set
Remote DataBroker
Business Object Broker
ConstraintBroker
Summary
Appendix A - Cost benefit of thin client architecture
Overview
Borland MIDAS: Multi-tier Distributed Applications Services Suite provides developers with a suite of advanced components, servers, and core technologies for multi-tier application development. These services enhance those provided by Microsoft with Windows NT 4.0 and DCOM.
Borland MIDAS provides the ability to deploy distributed business objects with a feature set that includes:
- High server availability with fail-over safety
- Load balancing
- Distributed datasets and transaction processing
- Thin client applications
- Automatic database constraint propagation
- High-speed database connectivity
These features have been architected to work individually or in conjunction with each other, and support operating system and industry standards.
Borland MIDAS includes the following technologies that complement the feature set of Delphi 3 Client/Server :
- Remote DataBroker
- Business Object Broker
- ConstraintBroker
This white paper will examine how each of these technologies in Borland MIDAS operates. For further information on Windows NT and DCOM, refer to the white paper titled "Building Scalable Applications with Windows NT and DCOM," located on Borland's Web site at www.borland.com. For further information on multi-tier architecture, refer to the white paper titled "Why multi-tier?" also located on Borland's Web site.
Borland MIDAS Feature Set
The following diagram outlines the entire Borland MIDAS architecture.
Figure 1: Borland MIDAS architecture multi-tier made easy
Let's examine the individual components of Borland MIDAS in some detail.
Remote DataBroker
The Remote DataBroker gives Delphi 3 developers the ability to create distributed database applications. These applications have a number of characteristics:
- They are built in multiple tiers a client tier, middle tier, and a database tier.
- The middle tier may consist of many physical machines and many different application servers.
- The applications developed for the client are "thin-client applications."
The term "thin-client application" may have two definitions. One is that the client-side technology only makes a small footprint on the client machine. In the case of the Remote DataBroker, the client only requires a 140K DLL. This needs no manual installation or configuration, as it can be automatically configured with Delphi Web deployment capabilities. The second is that the client application has no embedded business rules-the client is simply a GUI to the data. The only coding that is directed at the client interface is for presentation effects.
Using Borland MIDAS and Delphi, developers can create a thin client application that supports both of these definitions. All of the business rules are coded into the middle tier application and using Delphi Package technology, the footprint on the client is very small.
A thin client application has a number of benefits. A thin client requires little or no installation, configuration, and maintenance. Most often, the software that needs to be installed, configured, and maintained is the database client connectivity software. The Remote DataBroker technology bypasses this step for the clients and places that burden only on the application server, reducing the installation, configuration, and maintenance to one machine. See Appendix A for a discussion on the cost benefits of this model.
Let's look at the technology behind the Remote DataBroker. The technology can be separated into three distinct sections: the client, the data transfer protocol, and the server.
In its most basic form, the client makes a DCOM request to the server.
Figure 2: DCOM request
The server processes the request by gathering the data and packaging it into a DataPacket. The DataPacket is the protocol used to transfer the data from the server to the client.
Figure 3: Server creates a DataPacket
Once the Remote DataBroker has gathered the data, the result is sent back to the client.
Figure 4: Result returned to client
When the client receives the DataPacket, it becomes available for usage via the ClientDataset component. The client portion of the Remote DataBroker consists of Delphi components (TClientDataset and TRemoteServer) and a single supporting DLL (DBCLIENT.DLL). The supporting DLL (only 140K) provides connectivity to the middle-tier application servers, which in turn provide connectivity to a variety of databases, including Oracle; Borland InterBase; Microsoft SQL Server; IBM's DB2; Sybase System 10 & 11; Informix Universal Server; file-based databases such as Corel Paradox, Microsoft Access, Borland dBASE, and FoxPro; and any ODBC datasource.
When the data is retrieved from a Remote DataBroker, the data is stored in a ClientDataset. The ClientDataset is a Delphi component that stores the data in memory. This component provides the methods to navigate, sort, filter, and edit the data. Additionally, the ClientDataset provides functionality to save the retrieved data to disk. This allows the user to connect to the corporate network, download data to their local drive, and work on that data at any time. The user can then reconnect to the network and upload the changes back to the application server for processing.
Data concurrency is also addressed in this model. The client components keep a note of the records that have been changed and what that change was. While this provides some additional features such as multi-level undo, it also provides a mechanism to request just the changed records, or the delta, from the original set.
For example, a dataset that includes 100 records has been sent to the client. Suppose one of the records appears as follows:
| NAME |
AGE |
OCCUPATION |
| Joe |
41 |
Accountant |
The user makes a change to the OCCUPATION field. When the program calls the ClientDataset method of ApplyChanges, the following records get sent back to the application server. (Note: This is a conceptual simplification)
| KEY |
NAME |
AGE |
OCCUPATION |
UPDATE TYPE |
| 1 |
Joe |
41 |
Accountant |
Original |
| 1 |
NULL |
NULL |
Sr. Accountant |
Modify |
Where KEY is a unique identifier within the client dataset to match updates with originals, and the UPDATE TYPE is a single byte flag to indicate the type of operation.
When the changed data is received by the application server, it is applied to the database. Due to the connectionless model, there could have been a large time delay between the client requesting the data and the client posting the changes. An advanced mechanism is needed to support this type of connectivity. The Remote DataBroker will take the new records and attempt to locate the matching record in the database by searching on the primary key, or optionally all fields. When the record is found in the database, all columns are compared to determine if the record has been modified since it was originally retrieved. If a column has been modified, an error event will occur and the developer will have an opportunity to resolve the conflict.
When the error event occurs, the developer will have access to an error code and the data that caused the error. The data consists of the original record, the modifications, and the now-current record. Taking from the example above, if another user modified the data prior to this update, the error event would provide the developer with a dataset similar to the following:
KEY |
NAME |
AGE |
OCCUPATION |
RECORD_TYPE |
1 |
Joe |
41 |
Accountant |
Original Values |
1 |
NULL |
NULL |
Sr. Accountant |
Modified Values |
1 |
Joe |
42 |
Accountant |
New Values |
With this information, the developer can determine that the changes made to the record will not affect the new changes and can change the post to include the existing values in the database. In this case, there is no concurrency problem.
In some situations, however, the developer cannot determine what to do ahead of time. Using the above data, for example, had the OCCUPATION field been changed after the original retrieval but prior to the posting of the modifications, the developer cannot likely determine which data is correct. In situations like this, the developer has the option of sending the error set back to the client for processing. If another user changed the OCCUPATION field to "Tax Accountant," then the user that made a similar change would need to see the existing value, and make a decision to overwrite or cancel the update.
While these features make data handling and data access easy, the Remote Data Module provides the COM and DCOM interface to surface this data to DCOM clients. The Remote Data Modules provide all of the implementation necessary to make the application a DCOM server. All that is required of the developer is to enter the SQL statement that gathers the data and expose that data. Exposing the data in Delphi is as simple as right-clicking the data access component and making a menu selection.
With the release of Borland's JBuilder, the Remote DataBroker technology will be extended to Java. This will provide the ability to create distributed business objects in either Delphi or JBuilder. These servers can support either Delphi or Java clients irrespective of where the server was developed. More information will be available upon general availability of JBuilder.
Business Object Broker
One of the benefits of a multi-tier environment is the ability to distribute processing across multiple servers. With standard DCOM, the client must recognize the server's name when it attempts to connect to the application server. This creates two potential problems:
- What happens if that machine is not operating correctly?
- What if that application server is already overloaded with other user requests?
Traditional implementations of DCOM do not attempt to answer these questions. However, the Business Object Broker
and OLEnterprise technology make great steps towards solving the problem.
The Business Object Broker
and OLEnterprise can bring load balancing and fail-over safety to any OLE Automation Server (COM Server) or DCE/RPC server. They can do this independently of the development tool used to create the application server, provided the application server either supports OLE Automation or is a DCE/RPC server.
There are four main components to this technology:
- Business Object Broker
- Object Factory
- Object Agent
- Object Explorer
The Business Object Broker provides the global registry where an application server will make its registry entries. This is the location where the client application will look to get a connection to one of the application servers on the network. The Business Object Broker will return one of the server machines that has the requested application server installed and registered, to the requesting client.
The Object Factory is used by the server. The Object Factory is both an RPC server and an OLE Automation client. It acts as a proxy OLE Automation client, representing the remote client. When a remote OLE request is made, the request is passed as a remote procedure call from the Object Agent on the client machine to the Object Factory. The Object Factory reissues the original OLE request on behalf of the remote client application. When a remote request is made for an RPC server, the request does not go through the Object Factory. Instead, the Object Agent and the RPC object communicate directly.
The Object Agent is used by the client. The Object Agent is both an OLE Automation server and an RPC client. It acts as a proxy OLE Automation server, representing the remote server. When a remote request is made, the request is passed to the Object Agent.
If the request is for a remote OLE object, the Object Agent packages up the request and uses the RPC to forward the request to the Object Factory on the server machine. If the request is for a remote RPC object, the Object Agent reads the interface definition from the Registry and dynamically builds an RPC request, which it sends to the server.
The Object Explorer is a browsing utility that enables users to explore the enterprise and dynamically view objects and services. The Object Explorer also provides import and export facilities that enable clients to share and reuse objects. The object developer uses the Object Explorer to export (or publish) an object.
The Explorer can search through local, remote, and global registries for enterprise objects. When an object is selected, the Explorer automatically imports all information required to enable access to the object and loads it into the user's local registry.
Figure 5: The Object Explorer provides a graphical view of the available objects.
For example, there are two servers on the network, "Server A" and "Server B." Each of these machines has an application server, called PurchaseOrders, installed and registered. When a client requests that the PurchaseOrders automation server be loaded, the Object Agent will request the location of one of the application servers from the Business Object Broker. The Business Object Broker will search the global registry for all of the machines that have registered the requested automation server, PurchaseOrders. The Business Object Broker will select one of the server machines from the list of servers that has that business object and return that information to the Object Agent. The Object Agent will in turn make the call to that server machine, creating an instance of the PurchaseOrder application server. If the Business Object Broker selected "Server A," then the client would have created PurchaseOrder on Server A. The next time that a user makes a request for the PurchaseOrder object, the process is repeated, but depending on the load of the servers, the client may be handed a reference to Server A or Server B.
The logic currently used to determine which server the client will reference is based on a random algorithm. Borland is currently developing technology that will take this to the next logical step, which will base the server selection on the CPU usage, I/O, etc. of the machines and the physical distance. This will further improve the load balancing across the enterprise.
The approach that Borland is using to provide the load-balancing and fail-over features has been recommended by Microsoft in their white paper, "DCOM Technical Overview."
"DCOM also allows efficient referrals from one component to the other. If a component holds a reference to another component on a separate machine, it can pass this reference to a client running on a third machine (refer the client to another component running on another machine). When the client uses this reference, it communicates directly with the second component. DCOM short-circuits these references and lets the original component and machine get out of the picture entirely. This enables custom directory services that can return references to a wide range of remote components.
Example: A "broker" component keeps track of a pool of 20 server machines running identical components. It measures the current load on the servers and detects when servers are added or removed. When a client needs a component, it connects to the "broker" component, which returns a reference to a component on the server with the lowest load. DCOM automatically connects the client to the server; the "broker" component then gets completely out of the way."
Figure 6: The Business Object Broker for load balancing and fail-over safety
The global registry can also include DCE and RPC servers running on UNIX or mainframes. These application servers can be entered into the global registry and can be called through a COM interface from any client application. This provides the ability to build the client once, regardless of the server's platform.
In summary, the Business Object Broker provides all automation server developers with dynamic load balancing and fail-over safety. These features ensure that there will be consistent performance and high availability. The result is that the end user has faster applications and is more productive.
ConstraintBroker
One of the major tenets of good database design is that data integrity rules should be centralized in the database. By centralizing the validation rules, developers are assured that no matter which client application is updating the database, the data will be correctly validated. While this ensures data integrity, it doesn't provide the complete solution. Specifically, if a client application were to make an update to the database that was invalid, the following events would occur:
- The client application would post the data to the database server.
- The database server would begin a transaction.
- It would then attempt to make the update.
- The update would fail because of the invalid data.
- The transaction would be rolled back.
- The database server would send an error message back to the client application.
- The end user would then be required to correct the data.
- Then the entire process would begin again.
While this method ensures that only valid data is committed to the database, the network is unduly utilized and the end user has to wait for this response, decreasing productivity.
A common technique used to minimize these drawbacks is for the developer to reprogram the data integrity rules into the client application. By doing this, the network is only utilized when sending data that is most likely correct (triggers and stored procedures often aren't reprogrammed). Additionally, the end user would get a quicker response to invalid data, thereby increasing productivity. However, this solution has drawbacks.
The drawbacks to reprogramming the integrity rules into the client application are twofold. First, the developer must duplicate effort in implementing these rules. Second, and more important, when changes are made to the database, all applications that include those rules in the clientside must be updated, redistributed, reinstalled, and reconfigured.
The ConstraintBroker technology is an ideal solution allowing developers to maintain integrity rules in a central location, while providing responsive data-entry applications that minimize network traffic.
The ConstraintBroker works in conjunction with the Remote DataBroker. As described above, the Remote DataBroker will take a client request for data, query the database for the data requested and forward that back to the client. When the ConstraintBroker is enabled, the Remote DataBroker will additionally query a Data Dictionary for the constraints and include these constraints with the data. The Data Dictionary is a table that stores data validation and presentation rules. This table can reside in any database supported by the Borland Database Engine (BDE).
The ConstraintBroker provides the developer a simple and automatic method of distributing integrity rules with the data. The dynamic nature of the rule propagation positions the developer to easily maintain much of the application. For example, when a rule changes in the database, the developer simply needs to update the Data Dictionary. After the Data Dictionary has been updated, the Remote DataBroker can make a single function call to make updates internally. When a client makes a request for that data, the new rules are propagated to the client without reprogramming, recompiling, redistributing, reinstalling, or reconfiguring. So taking from our example above where the user entered invalid data, the events are as follows:
- The client application would attempt to post the data.
- An error would occur immediately, notifying the user of the invalid data.
- The user would make the correction and attempt to post again.
Here, the user gets a very quick response to invalid data entry. Neither the network or the database server were involved with recognizing invalid data. Once the data has passed the constraints test that has been provided to the client, the record will be sent to the database server for final validation.
The Data Dictionary also includes facilities to add custom constraints and custom error messages. This provides additional flexibility for application specific rules. For example, data integrity rules may indicate that for this application, only values greater than 100 can be entered. This would appear in the dictionary, as shown below.
Figure 7: Adding custom constraints and error messages
The management tool used to update and maintain the dictionary is the SQL Explorer. The SQL Explorer is the information center for database management; it supports the creation and modification of tables, aliases, stored procedures, triggers, and integrity rules through interactive SQL.
The SQL Explorer makes database administration easier and more intuitive than using a separate nonintegrated tool. It can present schema information from Oracle, Borland InterBase, Sybase, Informix, DB2, MS SQL Server, and others. Using SQL Explorer, the developer can also issue SQL statements, view data, and make edits.
Figure 8: The SQL Explorer is an integrated tool for administering SQL and PC databases.
By providing the advanced capabilities of the ConstraintBroker with administrative tools, Borland is providing a powerful and easy way of maintaining database structures and integrity rules for distributed applications.
Summary
As today's computing infrastructure gets larger, more decentralized, and generally more complex, IT organizations should be looking for the technologies that provide solutions immediately. Microsoft has made good progress with DCOM, and promises to further this with new developments in the future. However, with Borland MIDAS, Borland is providing the advanced solutions to build, deploy, and maintain distributed applications within this standards-based environment today!
Borland has been well known for its high-quality compilers and Rapid Application Development (RAD) environments. However, it is one thing to be developing with a RAD tool for building single applications; it is another to have RAD for distributed systems. With Borland MIDAS and our development tools, Borland is delivering RAD for distributed systems.
- The Business Object Broker
delivers load balancing and fail-over with no additional coding or effort.
- The Remote DataBroker makes it easy to build middle-tier business objects while maintaining great ease and flexibility for distributing the data to client applications.
- The ConstraintBroker eases maintenance costs by centralizing data integrity rules for client applications while providing simple mechanisms to enforce these basic rules on the client to reduce network traffic.
As Borland moves forward with these technologies and others, the common goal will be to provide leading-edge technology that allows developers to quickly develop and integrate new systems into existing systems. By delivering on this goal, organizations can be assured that your existing knowledge and work will be leveraged, providing a highly competitive advantage.
Borland will also be extending these services in the near future to support Java clients and Java servers. Through this level of integration, Borland is helping developers and IT organizations to bridge systems, standards, and the Internet while maintaining a consistent set of tools and services to allow for true Rapid Application Development across the enterprise.
Appendix A - Cost benefit of thin client architecture
The following information is based on Gartner Group's analysis from the studies, "A Guide for Estimating Client/Server Costs" and "Client/Server: A Study of Usage and Benefits."
- The average number of clients per C/S application is 700.
- The median number of clients per C/S application is 50.
- On average, end users spend 4 days per year configuring their desktop systems.
- The burdened labor rate is $224 per day.
The results of this analysis show that annual installation, configuration, and maintenance for an average workgroup application costs $44,800 ($224/day X 4 days/year X 50 clients). For a large enterprise C/S application with hundreds of users, the costs can soar beyond $600,000 ($224/day X 4 days/year X 700 clients).
Since the DataBroker technology removes configuration from the end-user's workstation, using Remote DataBroker application servers can reduce the amount of end user work required by a significant margin. Taking a conservative estimate of only reducing each individual's work by 1 day per year, this results in a savings of $11,200 per 50 users ($224/day X 1 day/year X 50 clients).
|
MIDAS
