OSGi在应用时具备了典型的微核系统的特点，但对于实际项目/产品型的应用而言，这个微核有些过于底层了，为什么这么说呢？
对于实际项目/产品型的应用而言，何谓其微核呢，应该说其脚手架或开发平台才是它的微核，而并非仅仅是OSGi框架，当然，也可以将自己的脚手架或开发平台以Fragment-Host的方式绑定到OSGi的System Bundle上去，但这样的做法无疑有些evil了，TPF诞生的最主要的目的就是形成一个应用级的微核的概念，使得我们在管理实际的项目和产品时，能够将脚手架和实际的业务应用模块分离管理，让脚手架也变成微核，这样在管理时就可以做到对应用系统的统一管理，而同时保持一个含应用意义的微核（也可以认为是开发平台）的稳定运行，在具备了TPF的情况下，就可以将应用系统从部署上分为脚手架和应用系统，而在管理上也可以单独对应用系统进行管理，如启动应用系统、停止应用系统，同时避免应用开发人员对脚手架无意的修改。
在本篇文档中将介绍TPF提供的功能、TPF实现的方法以及TPF的下载地址。
功能
TPF以web形式来管理TPF中的插件，该web管理端提供了以下功能：
l 插件的安装
在插件的安装上TPF支持两种形式：
n 手工输入插件的地址
可用于实现位于服务器上的目录形式的插件的安装。
n 选择插件文件
可用于实现远程安装插件至服务器或安装服务器上的插件，这些插件必须是zip或jar格式的。
上传至服务器的路径在TPF的cn.org.osgi.tpf.webconsole的MANIFEST.MF中指定。
l 插件的管理
TPF仅管理通过TPF Web管理端安装的插件，通过install方式在OSGi console中安装的插件TPF将不进行管理。
TPF支持插件的启动、更新、停止、卸载的管理。
l 插件MANIFEST.MF修改的支持
TPF支持修改插件的MANIFEST.MF文件的内容。
l 应用系统的管理
TPF具备了应用级微核的概念，因此TPF可支持应用系统的管理，其实意思就是可以统一的对通过TPF部署的插件进行管理：
n 统一的启动TPF中的所有插件；
n 统一的停止TPF中的所有插件；
n 导出TPF中所有的插件的配置。
这个功能使得只需要在一台机器上完成了应用系统的部署后，可以通过导出配置来生成TPF启动时的插件配置文件，这样在其他机器上再部署时就不需要再通过插件管理端来部署插件了。
l 远程应用系统的状态查询
TPF支持查询远程部署至TPF的应用系统的运行状态。
l 远程应用系统的管理
TPF支持管理远程应用系统的状态，可停止和启动远程的应用系统。
实现方法
TPF的最重要的功能是要实现应用级微核，要实现应用级微核，就要让TPF知道哪些是应用系统的插件，只要知道哪些插件是需要列入TPF管理的就行了，对于这个问题TPF通过在其web管理端安装插件时将插件的信息写入至一个tpf.system.plugins文件来实现，通过这样的方法就可以使得TPF知道哪些插件是要管理的，TPF将记录这些插件的id、启动顺序、插件位置、插件名称以及插件的状态，当再次启动OSGi应用时，TPF将通过此文件来加载插件，此处要注意，这些插件并不是OSGi框架直接加载的，而是通过TPF来加载的，这样有助于TPF来控制插件的启动过程、保持插件原有状态等。
在实现了应用级微核概念的基础上，TPF基于OSGi的API实现了像插件的安装、启动、停止、更新、卸载这些管理功能，基于文件操作的方式实现了对于Manifest.mf的修改。
在远程系统的状态监控和管理上，TPF基于OSGi.org.cn的axis封装模块实现了与远程的OSGi应用通讯从而获取远程OSGi应用的状态并进行管理。
下载
暂时还未把TPF归入开源的project中，感兴趣的同学可以先从以下地址下载源码和可运行版本：
源码：
http://www.bluedavy.com/opendoc/TPF-Source.zip
可运行版本：
http://www.bluedavy.com/opendoc/TPF-dist.zip
等将来把TPF归入到OSGi.org.cn的开源项目后，大家就可以通过svn来共同发展TPF项目了。
后续版本
目前版本的TPF对于大家来说也许主要是webconsole部分的功能，而且更多的也许是，TPF在后续主要需要增强的是插件启动的控制上的管理、提供系统依赖的图形化的分析以及远程TPF应用的图形化的监控和管理等等。
另外TPF在代码级别也还有很多可完善的地方，在实现上也许可以不专门出现一个tpf.system.plugins，而是通过在MANIFEST.MF中扩展出一个属性来实现应用级微核的概念，还有像将TPF的远程管理剥离开，以便不需要的话就可以不安装此插件。
在TPF得到了一定的完善后，将会把它贡献给OSGi Bundle Repository。