I have seen some confusion regarding how the Deploy method (including some posts on MSDN forums http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1474&SiteID=1) in an event handler is used. I felt a description of the Deploy method's "role in the universe" would be useful. Parts of this description are in the product documentation but split in various places.
When ProcessManagerProxy.DeployProcess is called on an RfidProcess, the Deploy methods are called on all the event handlers in it. The Deploy method is like setup for an event handler. When StartProcess is called later on, the instantiated event handler can assume the setup or "Deploy" has already been done.
The out-of-the-box SqlServerSink's Deploy method sets up the database schema required for the event handler to use later on. It also gives permissions for the RfidUsrAcc to post to the database that it has created. The permissions bring up an interesting aspect. DeployProcess runs under the credentials of the caller. The caller (if you are using RfidManager, the credentials under which RfidManager is executing) is impersonated inside BIztalk Rfid Server where the DeployProcess is executed. The idea is that setup usually requires higher privieleges than normal execution. Thus in the case of SqlServerSink creating a database and schema requires higher privileges (create database etc.). Whereas just posting events requires fewer privileges (insert into a particular table). When a higher privileged user calls DeployProcess, her credentials are used to setup the user. The higher privileges are used only during DeployProcess (again DeployProcess is done before a process executes) thus giving us better security. RfidUsrAcc (under whose identity the event handlers execute), can have just the privilges required to do their work (in this case post to a table).
Let me take another example where Deploy will be useful. Let's say an event handler writes all the events it sees to C:\Data\Somefile.xml (some file) to be more concrete. The Deploy step of the event handler creates the file and gives permissions to RfidUsrAcc to write to it. Without deploy, RfidUsrAcc we would have had to give file create privileges to RfidUsrAcc for C:\Data. This would mean all RFID processes (and providers) will have the same privileges. Instead, if an Administrator on the machine (or any user that has appropriate privileges to create the file) calls DeployProcess, and the Deploy method sets up the file, RfidUsrAcc can just have write permissions to this one file, thus locking down what RfidUsrAcc could do.
Attached is some code that illustrates the above example. Note processRuntimeUser in the code is the same as RfidUsrAcc.
EventHandlers have an Init method. The Init is called each time the event handler is executed and is like a constructor for the event handler (unlike Deploy which is like Setup). Just like event handler methods, it executes under the RfidUsrAcc identity. In the attached example Init could have opened the file.
Note: The identity under which Biztalk RFID service runs in called RfidSvcAcc (whether it's a local account or a domain account). The identity under which event handlers execute (and providers also) is called RfidUsrAcc. On Windows XP, these two are the same. On Win2k3, they are different because we host the event handler in IIS worker processes.
Note: RfidManager calls DeployProcess automatically when a user tries to start a process from it. If the DeployProcess fails, it is silently ignored. There is no explicit way to say DeployProcess from RfidManager. RfidClientConsole exposes DeployProcess though.