    |
|||
        |
Distributed Application Design and dbObjects
The database and connection management objects of mvComponents are used within the Data-Centric set of base objects and templates associated with dbObjects. The following figure is provided to give you an overview of how the objects of dbObjects work within the Distributed Application approach to software development. The above figure follows the flow between objects from the client application to the database server, in this case a MultiValue (PICK) Database system. The client application can be a Visual Basic form-based application, an Excel spreadsheet with using VBA macros, or an IIS Web server application using Active Server Pages (ASP) technology. With any UI used, a UI-Centric Business object is instantiated, either a List-based object or an Edit object. These objects are based on a set of templates provided as part of dbObjects and work through the interface and base class object server (VPIUis20.dll). This base class object server does the real work and links to the Data-Centric objects that are placed on an Application Server machine separate from the client machine or Web Server machine. This middle tier is comprised of the Data-Centric Business objects, their associated base class object server (VPIDbp20.dll) and the Database operations objects of dbObjects, which includes the mvDatabase object (VPMVDb20.dll), the generic Database objects (VPDb20.dll), and the communication Gateway server object (VPGwsv20.exe). Any database requests are past from the Server object of the Gateway server object (VPGwsv20.exe) through a Channel object (VPChnl20.exe) to the Vantage mvServer software running on the MVSERVER account of the MultiValue (PICK) Host system. Lets first focus on the client side of the system. The next figure is the Client system portion of the first overall Distributed Application Design figure. Any List object implements the IListServer interface and delegates much of its operations to the IListServer server object as an inherited base class. This is accomplished through containment and delegation because the current version of Visual Basic does not support implementation inheritance. This will change with the future .NET version of mvComponents. The IListServer base object handles most of the UI-Centric behaviors and passes any database access requests to the Data-Centric half of the logical Business object through DCOM calls. These calls go to the ListPersist object on the Application Server system, which is matched to the List object on the Client system. The same architecture applies to the Edit UI-Centric objects, the IEditServer interface class and base objects, and the Data-Centric EditPersist objects. One thing to point out is that the base class objects IListServer and IEditServer depend a great deal on the DynamicArray object of the Power Strings product to manage and manipulate the data in a multidimensional, multivalue format. In the case of the Edit object there can be a hierarchy of parent, child, and grandchild objects that maintain data and their relationships. Each Edit object that acts as a Parent object can have a collection of dependents. The dependent collection holds individual collections of different child objects. As an example, an investor object, acting as a top level parent object, could have a collection of dependent purchased security objects, a collection of dependent IPO conditional offer objects, and a collection of outstanding market order objects. In addition, each security child object could have a collection of purchase objects and a collection of sales objects. A chart of these specific Edit objects might look like the following: These UI-Centric objects provide all of the Business object behaviors needed by the client applications and communicate across the network to the Data-Centric Persistent versions of the Business objects to handle the actual database specific functions of reading and writing data. Next, lets focus on the middleware tier that resides on a Windows 2000 Server or NT Server system. The next figure is the “Application Server” system portion of the first overall Distributed Application Design figure. Any ListPersist object implements the IListPersist interface and delegates much of its operations to the IListPersist server object as an inherited base class. This, like the UI-Centric objects, is accomplished through containment and delegation. The IListPersist base object handles most of the Data-Centric behaviors and passes any database access requests to the mvDatabase object. The same architecture applies to the Edit Data-Centric (EditPersist) objects, and the IEditPersist interface class and base objects. The Edit Persist objects will have a similar hierarchy of parent, child, and grandchild objects that exists in the UI-Centric objects on the client. Each object manages their own interaction with the mvDatabase object for any database service requests. One thing to point out is that these Data-Centric objects are instantiated within a COM+ application if on a Windows 2000 server or they are instantiated within Microsoft’s Transaction Server (MTS) if on an NT system. COM+ or MTS handles object instantiation and pooling, the marshalling of calls between the client process and the object server through DCOM, and it gives the ability to have all Data-Centric database operations run within a Transaction context. This last feature of COM+ or MTS is very important when dealing with Relational Database Systems and using ADO object support and less important when working with a MultiValue (PICK) database source. The mvDatabase object, as describe earlier, acts as a "wrapper" object to the generic Database object and handles the instantiation of the dbSession object and its built-in collection of databases, the creation and adding of a new database object to the collection, the attaching of a specific VDD object definition to the new database object, establishing a connection to the MultiValue (PICK) Host system through the Request object, and the generation of store procedure calls, again, through the Request object. The Request object instantiates a Server object from the connection management Gateway Server (VPGwsv20.dll) and any database operations are performed through a given Channel object (VPChnl20.exe) and through the VPMv20.DLL functions and eventually reach the Host system. In this Distributed Application design the connection management Gateway Server (VPGwsv20.dll) runs as a Windows Service and is configured to pre-open a set of Channel objects and maintain a cache of PICK communication ports to handle requests. By have connections pre-opened and maintained, individual application request can be significantly sped up by not having to go through the actual open and close connection process for each request. This is very important to the non-persistent connection model used by the Distributed Application design or by Web-based applications. Also under this configuration multiple concurrent users can share a PICK communication port thus reducing the overhead and the traditional high licensing costs associated with PICK ports. Next, lets focus on the backend or database server tier that resides on the MultiValue (PICK) Host system. The next figure is the "MultiValue Server" system portion of the first overall Distributed Application Design figure. Here all database requests are routed into the MVSERVER account and the VSSERVER program that automatically runs when a port is logged on to the MVSERVER account. The VSSERVER program and a series of subroutines handle all the protocol operations of the server and either perform the necessary SQL functions or call the appropriate Stored Procedure subroutines. Any resulting data is returned back through the same input/output protocol over the network connection. In addition to the stored procedures written for a specific application there are a number of generic stored procedures available that can be called through methods of the mvDatabase object. These generic stored procedures provide for a number of general Pick/Basic functions such as reading and writing data records on a general basis.
For additional information or to order a copy of mvComponents Suite 2.0 and arrange for a consultant, please send an E-mail to: For VAR requirements and pricing please send E-mail to: |
||
 |
|||
Back to Objects and Services Overview
