Application components for application logic (presentation, business, and data logic) can be built and maintained by specifying declarative rules and using application flow diagrams. Changing business and application rules results in new and/or modified source code. One product that can build such applications is Vision Builder from Vision Software. A complimentary tool for Visual Studio 97, Vision Builder enables declarative construction and maintenance of Visual Basic and Java components. Also, Vision Software has optimized their tools for Microsoft Transaction Server and SQL Server. The Vision Software Web site is at http://www.vision-soft.com.
Before creating Microsoft Transaction Server components with Vision Builder, it is first helpful to see how to build business rules. The first stage of building an application with Vision Builder is to create a data model or work from an object model. There are two ways to build this model:
The next stage of building Microsoft Transaction Server components is to capture the business rules of the application. Business rules automate complex multitable transactions. Business rules can range from simple (constraints on object values and referential integrity), to complex (multitable rules involving external objects, such as mail and workflow servers). Business rules are closely aligned with business policies and practices and are captured graphically using Business Rules Designer. Business rules allow full automation of business logic into Microsoft Transaction Server components. An example of a business rule is: The aggregate of an order is all Order Line Item amounts combined with their freight, taxation and handling charges.
This business-logic automation uses a process called application targeting that produces optimized components for Microsoft Transaction Server and SQL Server. Business rules can also be converted into objects, such as SQL Server stored procedures. With application targeting, developers can choose and implement the ideal deployment architecture for each application without having to rewrite the entire application.
To begin setting rules, the user only needs to specify a name, the deviation, and how to validate the deviation. A derivation rule can aggregate values spanning multiple objects. When you instantiate this rule in relevant Microsoft Transaction Server packages, it is automatically reused across all relevant transactions and processes. The deviation can be anything, even an external OLE object to perform a previously defined computation.
Vision Builder can also capture business rules. It can automatically manage the dependencies between the objects and rules.
While setting the rules, the developer can embed workflow rules. This can be very simple, such as sending an e-mail message to a specific manager based on a transaction, or more complex, such as a multitable constraint that restricts the number of transactions allowed in the system. The rules can also involve calling external COM/DCOM objects, which allows integration of other sources of data and reuse of existing objects by an organization. To change your application at any time, you only have to change these business rules.
The third stage is to handle special cases. There are cases when declarative business rules may not be sufficient to capture all the business logic of the application. As a result, Vision Builder's declarative applications are designed to be extensible and customizable. This means you can extend any of the rules in the objects by including custom procedural or object code. This code can be written in any language and encapsulated as ActiveX objects, which are then invoked from Business Rules Designer. Alternatively, you can capture custom code in Business Rules Designer that can be written in Visual Basic.
An advantage of the declarative approach to development is that you don't have to wait until the end to see how your system behaves. Vision Builder includes a Server Manager Wizard for constructing Microsoft Transaction Server components with correct interfaces and partitioned business logic. The actual network and data I/O is more easily optimized by the system because it has a comprehensive view of the entire business logic and can do global optimization.
Server Manager detects any objects that have changed since the last deployment and only rebuilds those objects. This removes the overhead of rebuilding all components at each deployment. In addition to creating server-side components, you can use Vision Builder Application Designer to create client-side application components that can be used to test and debug the Microsoft Transaction Server components. Rule-tracing code is also embedded in the components for easy debugging of the business logic at a business-rules level.
Vision Builder displays a message telling you if the process was successful or if not, what you need to change to correct the problem. During deployment, Microsoft Transaction Server components are generated as Visual Basic .vbp, .bas, and .cls files in a folder called repository_name_SQLSERVER_SCRIPTS (where the .mdb file is located).
At this point, the necessary files exist for Visual Basic 5.0 to compile these components into ActiveX objects that can then be registered with Microsoft Transaction Server. These components are optimized for Microsoft SQL Server and RDO version 2.0. Before you can use them, use Explorer to register the components with Microsoft Transaction Server.
A Microsoft Transaction Server component is a reusable piece of code and data in binary form that is built following the rules defined in the Component Object Model. Components provide specific functions within a business process. For example, a Sales package might include a component that determines if customers are within their credit limit. Explorer assembles components into packages and registers them with the Microsoft Transaction Server run-time environment. Developers use Explorer to:
The Explorer interface depicts how the items in the run-time environment are organized. Packages are installed on computers, contain components, and define roles. Components define interfaces and methods. Folders contain items that have been added to the run-time environment. You can use special purpose windows to view transaction and trace message information.
To navigate the hierarchy, double-click an item in the right pane to expose its contents. You can also expand an item in the left pane to display the contents in the right pane.
A package is a set of components that perform related application functions. All components in a package run in the same MTS server process. A package is a trust boundary that defines when security credentials are verified. It's also a deployment unit for a set of components. You create packages with Transaction Server Explorer.
A component is a discrete unit of code built on ActiveX technologies that delivers a well-specified set of services through well-specified interfaces. Components provide the objects that clients request at run time.
An interface is a group of logically related operations or methods that provides access to a component object.
A role is a symbolic name that defines a class of users for a set of components. Each role defines which users are allowed to invoke interfaces on a component.
A user is a Windows NT domain account. It can be a domain user or group. Each user has a unique security identifier (SID) that identifies the user and can be used for security purposes.
Select the computer (server or Windows NT workstation), where you want to deploy the component; it will be part of a package. By grouping components into packages, you define the boundaries for a server process running on a server computer. For example, if you have two components, one for purchasing and one for sales, you can separate these functions by installing these components into separate packages.
You create packages by adding them to the Packages Installed folder of a computer in the Explorer hierarchy. You can build an empty package and then add components, or you can install a prebuilt package. A prebuilt package consists of a package file and the component files (.dll and .tlb) associated with the package. You can add packages by using the Package Wizard or by dragging a package file (.pak) from Windows NT Explorer and dropping it into the right pane of Transaction Server Explorer.
Add components and associate security roles to make the package functional.
The default selection is Interactive user - the current logged on user. The interactive user is the current Windows NT user on the computer running a package. To select a different user, click This user and type the user and password for a specific Windows NT user or group.
The password you enter is not validated until the package starts in a server process.
| Level | Description |
| Default | Use for the Windows NT Server Authentication service, which is Connect. |
| None | No security checking occurs on communication between this package and another package or a client application. |
| Connect | Security checking occurs only for the initial connection. |
| Call | Security checking occurs on every call for the duration of the connection. |
| Packet | The sender's identity is encrypted to ensure the authenticity of the sender. |
| Packet integrity | The sender's identity and signature are encrypted to ensure the authenticity of the sender and to ensure that packets haven't been changed in transit. |
| Packet privacy | The entire packet, including the data and the sender identity and signature, is encrypted for maximum security. |
With the package now installed, you can add components by dragging a DLL from Windows NT Explorer to the right pane of Transaction Explorer while the Components folder is open. Installing in this way has the same effect as clicking Install new component(s).
This is the property sheet for a component:
The General tab displays general information about the selected package, such as the name, description, and ID of a package. The ID is a unique number generated when you create the package.
The Transaction tab contains the transaction-attribute setting for the component. Transaction Server uses this attribute during object creation to determine whether the object should be created to execute within a transaction and whether a transaction is required or optional. The transaction attribute can have one of the following values:
Most Transaction Server components are declared as either Supports transactions or Requires a transaction. These values allow an object to execute within the scope of its client transaction. The difference between these occurs when an object is created from a context that doesn't have a transaction. If the component transaction attribute is Supports transactions, the new object runs without a transaction. If it's declared as Requires a transaction, Transaction Server automatically initiates a transaction for the new object.
Declaring a component as Requires a new transaction is similar to using Requires a transaction in that the component objects are guaranteed to execute within transactions. However, when you declare the transaction attribute this way, an object will never run inside the scope of its client transaction. Instead, the system creates independent transactions for new objects. For example, you can use this for auditing components that record work done on behalf of another transaction regardless of whether the original transaction commits or aborts.
Specifying Does not support transactions ensures that an object context will not contain a transaction. This is the default setting and is primarily intended for use with COM components that predate Transaction Server.
You can also set a transaction attribute at development time using Visual Studio values defined in Mtxattr.h. You can specify these values in an .odl file to encode them into the component type library—the standard descriptions of data types, modules, and interfaces that can be used to fully expose objects with ActiveX technology. Visual Basic automatically generates a type library and developers must use Microsoft Transaction Server Explorer to set the transaction attribute.
After the component is built, Microsoft Transaction Server Explorer builds the package file to deploy the components. The package contains information about the components and roles (security) of a package. When you create a prebuilt package, the associated component files (DLLs, type libraries, and proxy-stub DLLs, if implemented) are copied to the same directory where the package file was created.
Components that make updates to multiple transactional resources (for example, database records) can ensure that their objects are always created within a transaction. If the object is created from a context that has a transaction, the new context inherits that transaction; otherwise, the system automatically initiates a transaction. An object context is similar in concept to the process context that an operating system maintains for an executing program. The Microsoft Transaction Server run-time environment manages a context for each object.
Components that only do a single transactional update can be declared to support, but not require, transactions. If the object is created from a context that has a transaction, the new context inherits that transaction. This allows the work of multiple objects to be composed into a single atomic transaction. If the object is created from a context that doesn't have a transaction, the object can rely on the resource manager to ensure that the single update is atomic.
The Activation tab allows the developer to set attributes at run time. The default is to allow the component to be managed by Transaction Server. You can also set location parameters:
The Security tab contains the security setting. You can enable or disable checking of security credentials of any client. Set security for all components in a package here.
You can also use Explorer to tune and debug components. For information, see Microsoft Transaction Server Explorer Help. While the debuggers for Visual Basic and Visual C++ can help, Explorer provides the developer with valuable information for ensuring transaction integrity and performance.
