PETRI中间件规范目前的问题以及解决方案探讨V.doc

PETRI中间件规范目前的问题以及解决方案（征求意见）
PETRI中间件与应用（包括SQL语句、SHELL脚本）的界定问题。
总的来说，PETRI中间件有两个大的关键功能，一个是用于日常的维护工作，使用PETRI中间件的建模，将SHPETRI中间件规范目前的问题以及解决方案（征求意见）
PETRI中间件与应用（包括SQL语句、SHELL脚本）的界定问题。
总的来说，PETRI中间件有两个大的关键功能，一个是用于日常的维护工作，使用PETRI中间件的建模，将SHELL，SQL，命令行等将流程组合起来，成为一个日常维护的工具，另外一个，是与应用进行交互，一方面强制应用按照PETRI的方式建模，另外一方面，能够监控应用的状态。
不管是用于哪个方面，中间件和应用之间，都存在一个界定的问题，总的来说，中间件管”做什么”，应用负责”如何做”，也就是说，流程的流转要靠中间件来实现，而不是由应用来负责。目前的规范有一些定义不清楚的地方。
NewToken()滥用的问题。
如果按照上面的方式建模，实际编写程序，T0为程序交互的应用，T0判断完奇偶以后，到底令牌流转到哪儿？这个时候还需要应用NewToken()来解决：
也就是说，NewToken到P1 ，则令牌流转到P1，NewToken到P2，则令牌流转到P2。（实际NewToken可以往任意库所新增令牌）这样就违背了使用中间件规范流程的设计初衷。
变迁的输出问题。
规范没有规定变迁的输入和输出，导致厂商在实现带条件的有向弧实现方式上不同。
模型的验证问题。
使用PETRI中间件来建模，一个很大的好处是能够对模型进行验证。验证目前的建模是否满足有界、安全、弱活性、可逆性等要求。但是目前规范对这一部分基本没有定义，究其原因，主要是因为PETRI的建模太过灵活，不同的场景有不同的验证要求，规范没有对其做一些整理。
有界性、安全性验证：
PETRI的库所可以用于表达资源或者表达状态（当然也可以在一个模型中，某些表达资源，某些表达状态），不管是资源还是状态，系统都需要满足有界性的要求，对于全部库所都用于表达状态的模型，需要满足安全性的验证。
对于PETRI中间件，除了某些日常维护工作中的特定场景下需要用资源建模外，其他都应该是状态建模。
可逆性的验证
可逆性是指系统从初始状态开始运行，最终会回到初始状态。那么对于常驻的进程，在不发生异常退出的情况下，模型是应该满足可逆性的。应该校验常驻进程的建模，至少有一个分支，会回到初始的状态。
解决方案探讨
系统建模部分。
模型的原子属性：对于逻辑上不允许存在并行情况的模型，定义为原子模型，对于逻辑上可能存在并行情况的模型，定义为业务模型。需要与应用交互的模型（与应用交互都只能是单线程操作，不可能存在并发），都属于原子模型。与SHELL，SQL等交互的模型，可以为原子模型，也可以为业务模型。
解决问题：区分原子属性用于对模型系列校验。
模型的常驻属性：对于业务上需要实例持续运行的模型，定义模型具有常驻属性。
解决问题：常驻属性用于对模型的可逆性校验。
建模时变迁的输出配置。
对于变迁输入输出，在建模部分没有做出规定