The MTS Architecture |
|
|
|
In the new architecture, an MTS component connects to the Rules Engine via the Remote Rules Service. The Rules Engine acts here as a server. MTS components are COM-components that can be involved in distributed transactions. These components can be written with Visual Basic, C++ or any language that is adapted to write COM components.
Architecture combining MTS Components and the Rules Engine To connect to the Rules Engine, an MTS component uses an ODBC Data source. This data source must have been set up for the Remote Rules Service. You must use one of the following API's: ODBC, OLE-DB, ADO, or JDBC. Refer to the USoft Remote Rules Service API Help for more information on these subjects. Within the MTS architecture, the Rules Engine appears as a database connected via the Remote Rules Service API. The actual database, however, is the RDBMS that the Rules Engine connects to. Therefore, the Rules Engine must tell MTS that this RDBMS also participates in the distributed transaction. To allow the RDBMS to participate in the distributed transaction, the Rules Engine needs to: connect to the RDBMS either with an ODBC connection, or with an MS SQL Server connection. If you want to connect, for example, to an Oracle database, you must use an ODBC for Oracle driver that supports MTS. This driver is delivered by Microsoft with the installation of MTS. Please refer to your MTS documentation for details. To improve performance: •Set the connection pooling for the USoft Remote Rules Service API to ON. •Set the timeout to 600. Without connection pooling, a Rules Engine will be created for each new database connection. This takes quite a long time. With connection pooling turned on, after a component releases its Rules Engine connection, this connection can be re-used for another component. Restriction: With distributed transactions, the Rules Engine cannot handle deferred constraints directly. See Also |
|
