正负责设计构建一个大型设施（确实有点大）的分布式控制软件系统，目前路线是采用同类型设施控制系统采用的一个成熟框架（ C/S，中间件为 omniORB+ZeroMQ，正在逐步替换掉 omniORB，提供支持 /C++、Python、Java 三种语言的 API，支持 Linux 和 Windows 平台，目前正在为其开发 RESTful API ）
现在设施总体方有个人（搞电子的）说调研了 IT 公司，应该采用 J2EE 架构（我还真不懂这个东西），理由一是客户端在浏览器中运行不需要部署，同时更换客户端机器也可以快速恢复／切换（我认可这个理由），理由二是这个更先进更符合发展趋势（这个理由我倒不完全认同，选什么主要看你干啥子）
但 J2EE 这个方案提议现在未得到多数控制工程师的认同（包括我），猜想主要原因是：
1.搞控制或控制软件的基本都是 C/C++出身（单片机或 ARM 等嵌入式设备控制软件基本在用 C 写，很多工业硬件提供的 SDK 也是 C 的），根本就不懂这玩意
2.以前很多成熟可靠的代码（特别是针对一些专用硬件设备）无法直接复用了，还有就是有些硬件设备提供的 SDK 仅是针对 C 的（我想这个可能也有办法来解决，可能麻烦一点点）
3.有些关键性能指标从目前的 C/S 到 B/S 后是否能够完全满足没验证就心里没底（比如关键状态显示的毫秒级更新周期，波形曲线及时显示等）
现在要我给出一个不采用 J2EE 的理由，我不知道从技术、应用层面咋个说这个理由以使其更充分、可信一点
现在设施总体方有个人（搞电子的）说调研了 IT 公司，应该采用 J2EE 架构（我还真不懂这个东西），理由一是客户端在浏览器中运行不需要部署，同时更换客户端机器也可以快速恢复／切换（我认可这个理由），理由二是这个更先进更符合发展趋势（这个理由我倒不完全认同，选什么主要看你干啥子）
但 J2EE 这个方案提议现在未得到多数控制工程师的认同（包括我），猜想主要原因是：
1.搞控制或控制软件的基本都是 C/C++出身（单片机或 ARM 等嵌入式设备控制软件基本在用 C 写，很多工业硬件提供的 SDK 也是 C 的），根本就不懂这玩意
2.以前很多成熟可靠的代码（特别是针对一些专用硬件设备）无法直接复用了，还有就是有些硬件设备提供的 SDK 仅是针对 C 的（我想这个可能也有办法来解决，可能麻烦一点点）
3.有些关键性能指标从目前的 C/S 到 B/S 后是否能够完全满足没验证就心里没底（比如关键状态显示的毫秒级更新周期，波形曲线及时显示等）
现在要我给出一个不采用 J2EE 的理由，我不知道从技术、应用层面咋个说这个理由以使其更充分、可信一点
1
Select Language