Microsoft Transaction Server Frequently Asked Questions

• Microsoft Transaction Server version 1.0

SUMMARY

This article contains the answers to frequently asked questions about Microsoft Transaction Server.

MORE INFORMATION

 1. Q. Are there any updates to Transaction Server version 1.0?

    A. Service Pack 2a is the latest update to Transaction Server version
       1.0. For information on how to obtain Service Pack 2a, please see
       the following article in the Microsoft Knowledge Base:

       ARTICLE-ID: Q150929
       TITLE     : How to Obtain Transaction Server 1.0 Service Pack 2a

 2. Q. A package accesses all resources through a single identity, so you
       lose client identity checking at the resource level. Is this a
       problem?


    A. From a design perspective, you can put user authorization checking
       anywhere. In fact, you can put it everywhere. Impersonation leads
       to just that. Consider a three-tier application of clients, middle-
       tier, and databases. Putting authorization everywhere is extremely
       hard to design and manage.

       If you want to make three-tier applications easier to design, you
       have to ask whether you can authorize locally rather than globally
       and still maintain security. The answer is yes. If you control your
       servers and not your clients, authorization must happen on the
       server. You authorize users when they enter the middle-tier. Then
       you authorize the middle-tier applications at the database. This
       model works regardless of whether you control both the middle-tier
       and the databases, or just one.

       This authorization model is much easier to design and manage, and is
       a natural fit with the three-tier model. The server applications
       authorize users at entry to the middle-tier. The database tier
       authorizes server applications. Because user authorization only
       occurs on entry to the middle tier, n-tier applications are feasible
       to design and manage as well.

       This model makes sense because you dramatically reduce authorization
       complexity at each tier. Besides being easier to design and manage,
       the model is also more efficient. For example, suppose 1,000 users
       access a database. Because 1,000 unique identities are present,
       1,000 connections are necessary. However, if those 1,000 users
       access 10 server applications that access the database, only 10
       unique identities are present. With some intelligent management of
       connections, far fewer connections are required, resulting in
       greater efficiency. Microsoft Transaction Server has intelligent
       management of database connections built-in, so components running
       in Microsoft Transaction Server can take advantage of it
       transparently.

 3. Q. I have a component accessed by two users. This component can call
       another package, but I only want one of the users authorized to do
       so. Because impersonating the client is not recommended, how do I do
       this checking?

    A. This seems like a problem until you look at the details. It is easy
       to assume the need for two packages, A1 and A2, one for each user.
       That way you can authorize A1 to use package B while disallowing A2
       from using the package. However, this is not necessary if you
       consider security as part of the design of your components. For
       example, suppose package B reads and writes important data. Package
       A wants to use package B for this reading and writing, but the
       design of package A calls for restricting some users to just
       reading. Simply design the package A component in question with
       security in mind. In this example, its functionality would be
       partitioned into read-only and write operations. If some interfaces
       are read-only, you can assign different roles to those interfaces,
       allowing different levels of access. This makes programming security
       management unnecessary, because Microsoft Transaction Server does it
       for you.

 4. Q. All components in a package run under the same identity. If
       Transaction Server controls the authority of the components, can't a
       programmer add an "evil" component to circumvent that authorization?

    A. Yes, but this is a problem outside the Microsoft Transaction Server
       security model. No security model can prevent you from allowing
       someone to bypass security. The security is model is only
       responsible for disallowing those who you say are disallowed. In
       this case, the bad programmer was authorized to install and
       configure his or her "evil" component on your server. Once you allow
       someone to do something "bad," you cannot stop that person; you can
       only audit him or her. Suppose you are responsible for important
       data. If someone writes a server application that uses that data,
       you are the one who denies or grants him or her authorization. You
       need to be sure that application can be trusted before you grant it
       authorization. In fact, unless you have a solid foundation of trust
       with the supplier, you should insist on controlling the application
       and the server on which it resides. These are simply policy issues.

 5. Q. Because Transaction Server does not impersonate, am I losing
       auditing information each time I cross a package boundary?

    A. No, you are not losing auditing information when you cross package
       boundaries. Microsoft Transaction Server gives you access to your
       original and direct creator, and the original and direct caller.
       This is all the information necessary for auditing. You can obtain
       this information using the SecurityProperty interface on your
       context.

       It is important to distinguish between authorization and auditing.
       Authorization allows you to control who is allowed to do what. For
       example, you may want to allow Bob into your application and deny
       Ben. It is the responsibility of the authorization mechanism to
       enforce this. However, if you grant authorization mistakenly, or if
       someone who has authorization abuses it, or if someone finds a
       security hole in your application, authorization is circumvented.
       Because you effectively allowed someone to do a dirty deed, your
       only recourse is to ensure that you have a record of him or her
       doing it. It is the responsibility of the auditing mechanism to
       provide this record.

 6. Q. Does Microsoft Transaction Server supply automatic auditing?

    A. No, but this feature is being considered for the future. It is
       possible to program auditing now by using the information supplied
       by the Microsoft Transaction Server SecurityProperty interface.

 7. Q. When a package is exported, are the package properties pre-set when
       the package is installed on another computer?

    A. Yes. Determining and setting properties is one of the key tasks in
       package deployment. By pre-setting package properties, the
       administrator of the package can control how components and users
       interact with each other.

 8. Q. Can packages include components that update data in sources other
       than databases?

    A. Yes. Sources of data for package components are known as Resource
       Managers. Although a broad range of database products can serve as
       Resource Managers, at this time there is no capability for non-
       database products (such as a Microsoft Excel spreadsheet) to serve
       as a Resource Manager. This limitation does not prevent you from
       building components that use non-database sources, as long as you
       are aware of the lack of transaction coordination that will occur
       with these components. This allows you to exploit the Distributed
       Component Object Model (DCOM) facility of Transaction Server in a
       non-transactional environment.

 9. Q. Can packages include components that do not support transactions?

    A. Yes. Transaction processing is only one part of the Microsoft
       Transaction Server programming model. Packages whose objectives do
       not include transaction processing can still take advantage of
       DCOM and Transaction Server’s process level security system. In
       this case, Microsoft Transaction Server is being used to manage
       object instances and object lifetimes. Microsoft Transaction Server
       can do this even when no transactions are involved.

       Applications that access transactional Resource Managers can
       simultaneously access non-transactional Resource Managers. The non-
       transactional resources will not be rolled back if the transaction
       aborts. If there is a requirement for data synchronization, the non-
       transactional Resource Manager must have some way to cope with this
       situation. The work a component does is only transaction-protected
       if the Resource Managers that the component uses are transactional.
       To support transactions, the Resource Manager engine must support
       logging (or some equivalent mechanism) to rollback aborted
       transactions. The Resource Manager engine must also support either
       OLE transactions or the XA two-phase commit protocol. These two-
       phase commit protocols permit the Resource Manager engine to
       coordinate the transaction outcome with the Microsoft Transaction
       Server Transaction Manager. The "Microsoft Distributed Transaction
       Coordinator Resource Manager Developer’s Guide" describes how an
       existing Resource Manager can be enhanced to work with OLE
       Transactions. You can obtain this document from ftp.microsoft.com
       using anonymous ftp. The Resource Manager Developer’s Guide and a
       sample Resource Manager are located in the Bussys/Viper directory of
       the ftp site.

       The resource Manager client library must provide a means for the
       Resource Manager engine to be enlisted in a transaction. To achieve
       the best performance, the client library should be implemented as a
       resource dispenser. The documentation necessary to develop a
       resource dispenser will be contained in the Microsoft Transaction
       Server SDK, available in March 1997.

10. Q. Can a client component run on a Windows 95 system?

    A. Yes. A client component can run on the Windows 95 operating system.
       However, the computer running Transaction Server requires Microsoft
       Windows NT 4.0, which means that all objects that take advantage of
       transaction support or any of the DCOM features must be located on
       computers running Windows NT.

11. Q. Can Transaction Explorer’s Security features be accessed
       programmatically, or are they only set through the Explorer?

    A. All process level security features are set through the Explorer.
       Component level security can also be implemented by enabling
       authorization checking on a component.

12. Q. What determines the privileges that are available for a role?

    A. Privileges are set through the Windows NT security system. As the
       package administrator, you can establish roles and assign users and
       groups to that role. Any privileges that have been assigned to users
       or groups through Windows NT security will also be available through
       the Transaction Server security system.

13. Q. If a component is configured as Requires New, does the Transaction
       Server perform deadlock detection?

    A. Yes. The following are two possible scenarios:

        - Exclusive Lock: If the data is exclusively locked by the calling
          component, and the sub-component tries to update it, the
          underlying database management system will detect the deadlock
          and abort the offending component.

        - Non-Exclusive Lock: When the sub-component is not trying to
          update, the blockage will be detected by either the Activity or
          Transaction timeout.

        In either of these scenarios, Transaction Server will ensure that
        all of the ACID transaction properties are enforced.

14. Q. Are there two distinct logs maintained for Transaction Errors, one
       for Transaction Server and another for the Resource Manager?

    A. If the Resource Manager is SQL Server, then there is only one log,
       because both Transaction Server and SQL Server are using Microsoft
       Distributed Transaction Coordinator (DTC). If the application is
       accessing an ODBC Resource Manager, there will be two error logs.

15. Q. Does Transaction Server run on a computer running Windows NT
       Workstation, or does it require Windows NT Server?

    A. Transaction Server will run on either system; however, Windows NT
       Server is recommended as the platform for deploying packages.

16. Q. Is there a way to view the objects without the hierarchy in the
       Explorer?

    A. Yes. The hierarchy can be turned off by clicking Hierarchy on the
       View menu in the Explorer. When the hierarchy is not displayed, you
       will only see folders and objects that have been added to the run-
       time environment.

17. Q. Can I add components with different threading models in the same
       package?

    A. No. This limitation exists because components with different
       threading models cannot be part of the same activity or transaction
       within a single application server process (ASP).

       If you need to mix VB and VC components in the same package, you
       must identify the VC components as single-threaded. You can
       configure components with different threading models so that they
       can be part of the same activity, or participate in the same
       transaction. To do this, add all apartment-thread aware components
       in one package and all single-threaded components in another
       package.

18. Q. Why can the Explorer set the transaction properties to "Does not
       support transactions?"

    A. This option exists because the person using the Explorer should
       be the administrator, and this option provides more flexibility.
       This option allows the ease of implementation for DCOM that the
       product offers, regardless of the use of transactional resources.

19. Q. Can I group components that don't have transaction capabilities in a
       package and use the Transaction Explorer to set their transaction
       properties to "requires a transaction," so that they can work in one
       transaction?

    A. Simply being in a package does not mean that the components will be
       grouped together in a transaction. This is more of a logical
       boundary than a physical one. You can only really group the
       components together from the client through ITransactionContext, or
       from the component through IObjectContext. Grouping components that
       are not capable of backing out work they do as transactional will
       not ensure that work is done properly. Components that update
       resources must be capable of backing out that update, to ensure data
       integrity within the transaction.

20. Q. Is it possible to call CoGetCallContext from a Transaction Server
       server component, and from that call be able to impersonate the
       client?

   A. Yes. However, impersonation will reduce the usefulness of connection
      pooling of ODBC database connections.