我们一直认为MES/EAP进入下一个阶段的分水岭，应该是Brooks提出FactoryWork/StationWork 2.X的时候。在那之前，MES是终端式Curses风格（用过Curses程式库的应该都知天命了），EAP是GW/SDR作为主流。FactoryWork/StationWork带领大家进入了另外一个世界，以CellWork作为中间件（MessageBus），服务（Services）和事件驱动（Event Driven），改变了所有人开发的方法，搭配上当年最红火的VB6，成为了主流。
我们最近发现，还有人的EAP依然沿用StationWork的大部分设计，因为C#代码中出现了：
public EMLibrary(ref COEAPData xData, WriteToScreenFuncDele xFunc, ref VB6.Collection colInterface)
VB6.Collection ? .NET的Collection不用，要用20年前的库？
以下的更经典：
private TxReplyResult FCGetTxReplyResult(COClosure xTag)
Tx =Transaction
xTag = Stationwork/WinSecs, 给开发人员任意储存任何想要传值的参数设计。
我们回头再看FactoryWork/StationWork的设计，不得不佩服老外的设计，经过30年依然经得的起考验。
近几年，很多中国本土的厂商都一窝蜂的选用了Java（J2EE）作为MES的BackBone，一堆大谈Spring的人，估计连Beans是什么都不知道，更不可能去思考MES到底适不适合用J2EE的方式来实现。大型MES的设计是有其特殊考量的。
能够提供用户客制化的方式一直是半导体MES很重要的一个环节。传统的做法主要是使用事件驱动（Event Driven）结合状态机（State Machine）和服务（Services），让用户或集成商可以实现客制化代码。后期则是使用场景（Scenario）和工作流（WorkFlow）的方式来实现。今天我们来探讨一下，两者上有什么不同？
使用场景（Scenario）/工作流（WorkFlow）的做法最简单直接粗暴，一根肠子直接通到底，考虑以下的场景：
WorkFlow1 {
WaitForCarrierArrived
CheckMaterialCondition
TrackIn
DownloadAndSelectRecipe
EquipmentStart
WaitForDataCollection
DoDataCollection
WaitForCarrierCompleted
TrackOut
}
最大的问题就是，要有一个线程/程序来一直等着，如果系统写的不好，就牺牲了“负载均衡”和“冗余容错”。好处是简单直观，不容易出错，系统成本低。
而事件驱动（Event Driven）的写法如下：
WaitForCarrierArrived {
CheckCurrentState
CheckMaterialCondition
TrackIn
DownloadAndSelectRecipe
EquipmentStart
}
WaitForDataCollection {
CheckCurrentState
DoDataCollection
}
WaitForCarrierCompleted {
CheckCurrentState
TrackOut
}
每一个事件都会触发单一代码，每一个代码中都要检查是不是在对的状态，才能做对的事。例如在没有收到WaitForCarrierArrived，这时候就必须要检查是不是在对的状态，才能做DoDataCollection，而Scenario/WorkFlow则会直接跳过。
事件驱动（Event Driven）方式的最大缺点就是开发不人性化，开发人员根本无法直观的知道下一步要做什么，在执行上，由于不确定是哪一个服务（负载均衡）执行，所以要除错，要开一堆的日志（或是用Elastic类的工具）。但最大的好处就是“负载均衡”和“冗余容错”。
事件驱动（Event Driven）用互联网程序员懂的话说就是Node.js的方式。
我们在设计系统的时候，不论是EAP或是MES，其实都需要兼容两种方式。而大部分传统的半导体MES/EAP主要支持的是事件驱动（Event Driven）的方式（例如FactoryWork/StationWork），这个时候TAG就异常的重要了，如何把上一个Event执行的结果储存在TAG中，让下一个事件（Event）发生时知道上一个状态的结果。这个TAG的设计，应该是从WinSecs的Transaction中开始的（至少在我经验中）。
不管是使用场景（Scenario）/工作流（WorkFlow）或是事件驱动（Event Driven）最关键的就是如何保证“事件”的顺序，通常大部分的MES都会加入一个队列（Queue）来保证事件的顺序。近年来，厂商都转向开源的队列，这样保护了客户的权益，而不是在未来变成孤儿（当然有些厂商依然用自己的写的队列，在稳定性和未来维护性，我做为客户，我会有所担心）。
总而言之，没有对或错的设计，或是哪一种方式比较好，主要看哪一种方式最适合客户的场景。
