3. Windchill技术架构总览
Windchill 从 R10 之后逐步演进为以 Java EE 为底座、以 B/S 为主入口、同时保留 C/S 富客户端能力的混合型 PLM 平台。理解它的技术架构，关键不是记住“用了哪些框架”，而是看清一次用户操作从浏览器或客户端发出后，请求如何穿过 Web 层、业务逻辑层与数据层，最终落到 Oracle 或 SQL Server 数据库，并把结果原路返回。这条路径决定了性能瓶颈通常出现在哪里、集群该如何部署、以及为什么某些操作必须走 Method Server 而不能只靠 Servlet Engine。
一、Java EE 分层：从 Web 容器到业务容器
Windchill 的 Java EE 架构可以概括为四层：客户端层（浏览器、Windchill Workgroup Manager、Creo 内嵌浏览器）、Web 层（Servlet Engine，通常部署在 Tomcat 或 WebLogic 中）、业务逻辑层（Method Server，运行在独立的 JVM 中）、数据层（Oracle/SQL Server 数据库与文件仓库）。Web 层负责 HTTP 会话、认证、页面渲染与静态资源分发；业务层负责对象模型、生命周期、权限、版本、工作流等真正的 PLM 逻辑；数据层负责持久化与文件存储。
需要特别注意的是，Windchill 的“Java EE”并不是把所有逻辑都塞进一个 WAR 包。Servlet Engine 与 Method Server 是两个独立进程，通过 RMI（远程方法调用）通信。这种拆分让业务逻辑可以独立于 Web 容器进行集群扩展，也让长时间运行的任务（如批量发布、工作流推进）不会阻塞 HTTP 线程。
二、B/S 与 C/S 混合访问模式
Windchill 同时支持两种访问模式，它们共享同一套业务对象模型，但入口不同：
- B/S 模式：用户通过浏览器访问
http://<server>/Windchill/，请求由 Servlet Engine 处理，页面通过 JSP/JSF 渲染。适合查询、审批、浏览、轻量编辑等场景。 - C/S 模式：用户通过 Windchill Workgroup Manager 或 Creo 内嵌的 Windchill 连接，直接调用 Method Server 暴露的远程接口。适合大批量 CAD 文件检入检出、结构编辑、本地缓存同步等重操作。
两种模式并非互斥，而是互补。例如工程师在 Creo 中完成装配后，通过 C/S 通道检入模型；项目经理在浏览器中通过 B/S 通道审批变更请求。二者最终都落到同一套 Method Server 业务逻辑上，因此权限、版本、生命周期状态保持一致。
三、Method Server 与 Servlet Engine 的协作机制
Servlet Engine 收到请求后，并不会直接操作数据库。它先完成会话校验、参数解析，然后通过 RMI 把业务调用转发给 Method Server。Method Server 内部维护对象缓存、事务上下文和数据库连接池，执行完业务逻辑后把结果序列化返回。Servlet Engine 再把结果渲染成 HTML 或 JSON 返回给客户端。
这种协作带来三个实际影响：第一，Method Server 是真正的性能核心，它的 JVM 堆大小、缓存配置、线程池直接决定系统吞吐；第二，Servlet Engine 可以水平扩展多个节点，但 Method Server 集群需要共享缓存协调；第三，任何绕过 Method Server 直接改数据库的操作都会破坏缓存一致性，属于严禁行为。
四、部署形态与关键参数
在典型的三层部署中，Servlet Engine 与 Method Server 可以同机也可以分离。同机部署（单机版）适合开发与测试，生产环境通常采用“Web 节点 + Method Server 节点 + 数据库节点”分离部署。以下是一组常见的示例配置参数，用于说明各层关注点：
| 组件 | 关键参数 | 示例值 | 作用 |
|---|---|---|---|
| Servlet Engine | 最大线程数 | 200 | 控制并发 HTTP 请求上限 |
| Servlet Engine | 会话超时 | 30 分钟 | 避免长时间空闲会话占用内存 |
| Method Server | JVM 堆大小 | -Xmx8g | 决定对象缓存与并发事务容量 |
| Method Server | RMI 端口 | 1099 | Web 层与业务层通信入口 |
| 数据库 | 连接池上限 | 100 | 防止过多连接拖垮数据库 |
五、一次典型请求的完整路径
以“在浏览器中打开一个已检入的 CAD 文档详情页”为例：浏览器发起 GET 请求 → Servlet Engine 校验会话并解析文档 OID → 通过 RMI 调用 Method Server 的 getDocumentDetails → Method Server 检查缓存，未命中则查询数据库并加载元数据 → 返回对象属性与文件下载链接 → Servlet Engine 渲染 JSP 页面 → 浏览器展示。若同一文档在 C/S 端被 Creo 检出，Method Server 会更新对象状态并通知缓存失效，下一次 B/S 访问即可看到最新版本。
理解这条路径后，就能解释很多现场现象：为什么 Method Server 重启期间浏览器会报“服务不可用”；为什么大批量检入时 Web 页面响应变慢；为什么调整 JVM 堆比调整 Tomcat 线程数更能改善吞吐。架构认知最终要落到部署、调优与排障的具体判断上。