|
This month we are going to be looking at deploying our
newly created Microsoft Transaction Server packages, and also at how to go about
configuring a client system to use MTS components. You can in fact, assuming that you have
more than one package, deploy different packages to different computers. Naturally those
computers must all be running MTS or it won’t work, and of course the computers must
be able to communicate with each other, but it can come in handy if you need to spread the
load a bit. You can also split the component parts of a package across different systems,
using a process known as ‘pushing and pulling’. The process works by you adding
components from a package to the Remote Components folder of a server. Before you do this
you will need to have set up a network share that can store the DLLs, type library files
and so on. You can then add each component to the server you want it on, assuming you have
the permissions and accounts setup to do so of course. You’ll find good guidance on
this process in the MTS online help system, which for once actually provides detailed and
useful information on how to set this all up. I know that’s what all Help systems are
supposed to do, but so few actually achieve that goal it is worthwhile mentioning one when
you come across it.
Creating the package
Before you do any of this however, you must first create your package, adding all the
components that are required for it to function. You should at this point also consider
some security aspects, and you may well want to investigate the creation of roles. A role
is the name given (for some reason that completely escapes me) to the group, or groups of
users that are going to be allowed to access the package and its components, or more
specifically, who is going to be able to call a component’s interfaces. This is
important, because it means you can create components with multiple interfaces, and then
restrict the usage of those interfaces to specific user groups. Administrator-type users
might well have access to a completely different set of interfaces and components than a
group of account clerks, for example, although all the components could be residing in one
package. The role security model can be used to check on calls made from outside the
package being called, although they don’t get used on method calls from components
within the same package as they are implicitly trusted. This is something worth bearing in
mind when constructing your components and packages. This security method is known as
Declarative Security, and only works on systems running Windows NT as it uses Windows NT
user accounts.
There is another security method you can employ if you choose, called Programmatic
Security. This works at the code level (surprise, surprise) and is again used to prevent
unauthorised access to component interfaces. You can use both security methods in your
components, choosing the one that seems best suited.
Role play
Bear in mind that security, if you’re running MTS on Windows 95, tends to go straight
out the window. In fact it isn’t supported at all, so if you carry out a role check,
for example, it will always return a success value, regardless of whether it should have
done or not. In order to implement Declarative Security therefore, you first need to
create the roles for each package, and sort out what role is assigned to which component
and interface. You next need to map Windows NT users to those roles, and finally you
enable security, because if you don’t do that no checks will be carried out at all.
You do that by selecting a component, or package, bringing up its Properties dialog,
selecting the Security tab, and then clicking in the Enable Authorisation Checking check
box.
I mention that one specifically as a colleague forgot to do it once, and then spent ages
trying to work out why none of his security checks were working. It never occurred to him
to check if he’d turned it on, because he knew he had. If you ever wondered why
people use checklists for repetitive tasks, that is a pretty good example.
System Package
While I’m on the security kick, I ought to mention the System Package. This is a
package that gets installed by default when MTS is installed on a system. It has two
default roles, Administrator and Reader. As you can imagine, one has slightly greater
capabilities than the other. In fact, the Reader role only allows a user to view objects
in the MTS Explorer, it doesn’t let them do anything to those objects. The reason I
mention this item is because by default no user is mapped to the Administrator role for
the system package. Thus, every person, and their pet of choice, has access to every
object in MTS.
It therefore comes under the heading of ‘A Good Idea’ to map a suitable Windows
NT user account to the Administrator role for the System Package, and to then enable
security on it. Once you’ve got all that done, you can finally turn your hand to
exporting your packages to their systems.
Exporting
This is a simple task, fortunately. Just select the package you want to export with your
right-mouse button, and select Export from the pop-up menu. Fill in path details and the
like, give the exported file a name, and make sure you check the box labelled, "Save
Windows NT user ids associated with roles" in order to include all the user ids that
you had associated with package roles. Hit Export at this point in time, and all your bits
and pieces will go sailing off to wherever you asked for them to be sent. Under the
Package folder that gets created will appear one-labelled "Clients". This will
hold an executable file that is used to configure client systems so that they can get
access to the components and packages that you exported. I mention this because the client
package is always going to direct client systems to the server the package was exported
from, because it is the path that it gets fed by default. If you want it to point to
another server, rather than the one you do your development work on, for example,
you’ll need to modify the path manually to point to the other server.
You can do this by selecting the computer icon from which the package is being exported,
and then clicking on the Action arrow on the MTS toolbar. Select the Properties menu item,
and then the Options tab. You’ll find the Remote server name edit box at the bottom
of the tab in the Replication frame.
DCOM required
The only requirement for the remote client use of an MTS package is that the client system
must have DCOM (Distributed COM) services installed on it. That’s no problem if you
use Windows NT on your clients, otherwise you can find DCOM for Windows 95 on the
Microsoft COM Web site, along with DCOM for Windows 98 – http://www.microsoft.com/com/.
Execute the client component by double-clicking on the executable you created having first
moved it from the Clients folder to the client system, or created a network share perhaps
that gives your users access to the file. A whole bunch of stuff goes off when the
executable is run, files flying hither and thither in a jolly manner, but at the end of
the day the client systems will have newly updated Registries, a new entry in Add/Remove
Programs, and a whole new set of DLLs, type libraries and so on.
That’s basically all there is to it, although as you will discover, there really is
quite a lot to do, and quite a lot that gets done and goes on at both the server and the
client. It is worth persevering however, as MTS is an important component of Windows now,
and will become much, much more important when Windows 2000 finally hoves into view.
For those of you who prefer your visual programming to be of the C++ rather than the
Visual Basic flavour, and who have developed a desire to learn COM, but find it
complicated (or even if you find it easy), I can recommend a book that should be by your
side at all times. Entitled "Essential COM", it is written by the inestimable
Don Box who I had the pleasure of meeting at the European Visual C++ Developer’s
Conference in Amsterdam earlier this year. (Essential COM by Don Box – Addison
Wesley, ISBN 0-201-63446-5.) A great speaker, and a great writer, Don has the ability
to impart his information in a way that makes it understandable, and when what you are
trying to understand are the intricacies of COM programming, you need all the insight you
can lay your hands on, believe me. |
