作为“中间人”角色的TWAIN，是一种协议。协议规定了成像设备与应用程序的交流方式与语言。用计算机的语言来说，就是TWAIN 定义了软件与特定硬件的编程接口（API，application programming interface）。
TWAIN由三个核心砖头组成。其一是程序员直接编写的，也是图像数据的消费者，即TWAIN“应用程序”（Application）；其二是代表硬件设备的“数据源”，这个源同样是软件，可以理解为是实现了TWAIN相关接口的设备驱动程序（Source）；最后一个也是TWAIN的核心模块，用于管理和协调应用程序与数据源之前的交流，可以称之为基于TWAIN的源管理程序（TWAIN Data Source Manager，DSM）。
三块砖头中的第三个，即DSM是由TWAIN协议的制定者开发并维护的，所以也是100%遵守TWAIN协议的程序。在Windows上，这个文件可能是以下两个文件之一
twain_32.dll：这个文件是TWAIN1.x对应的DLL。根据TWAIN组织于1998年和微软达成的协议，这个文件在Windows 98及以上将随作为Windows系统的一部分安装到系统目录。如C:\Windows\。如其名所示，这个文件只支持32位调用。
TWAINDSM.dll：这个文件是TWAIN2.x对应的DLL。它即有32位也有64位的版本。但是它并不是Windows系统的一部分，而是随着TWAIN应用程序或者TWAIN数据源一起安装的。需要注意的是，TWAIN提供的这个DLL并不需要安装到特定的位置，且同一系统上不同的目录内存在多个同名文件并不会有冲突。在很多情况下，TWAIN应用程序或者数据源（驱动）会将这个DLL放置在系统目录，即 C:\Windows\SysWOW64 (32位) 或者 C:\Windows\System32 (64位)，这样的话其它的程序也可以调用这个文件。某些情况下，TWAIN程序或者数据源也可能将这个文件置于它们可以访问的自己的目录中而不与其它程序共享。
一般一个TWAIN程序，不管是应用程序还是数据源都会（按一定先后顺序）从多个位置去寻找以上两个文件之一。如果所有备选路径都没找到，则TWAIN程序将无法继续运行。
好了，说完了最核心的DSM，再看下其它两位。Source一般由扫描仪厂商开发并维护，而Application则指那些需要集成扫描仪到工作流中的应用程序，这样的应用程序可能是任何一位开发人员编写的。
下图为三个砖头的相互关系，可以清晰看出DSM的核心地位。
正面我们看下这三个砖头是怎么搭在一起工作的。先上图
可以清晰的看出TWAIN的作用域仅仅是Protocol这一层。即TWAIN不在乎一个硬件（驱动层面）到底通过什么方式获取图片，而只管发出相关的配置及命令并等待预期的数据，然后将这一数据返还给应用程序。之后应用程序到底如何处置数据也与TWAIN无关。
简单的说，DSM就是一个翻译官，它负责将应用程序对图像的需求翻译为扫描仪看得懂的指令并将扫描仪返回的数据返回给应用程序。当然这个语言是有限制的，即应用程序只能提出TWAIN支持范围内的需求而扫描仪本身只能按TWAIN的规定来获取数据。在一定程度上，这限制了应用程序和扫描仪双方开发者的想象力，但是对于用一个程序广泛支持多个设备或者一个设备广泛支持多个程序这一大需求来说，这个限制还是合理的。
当然了，如果是一个严格受控的环境，如用户的程序只需要同特定一个型号的扫描仪进行交互且程序需要的很多数据（抑或是性能）也是该设备才能提供的情况下，开发人员完全可以抛开TWAIN来开发。不过，这不在笔者考虑之列。