本文基于两份内部向笔记（《NRI_ow_plus_Detailed_Guide》与《NRI_ObjectWorks_Framework_Guide》）综合整理，并补充 2008–2023 年间的官方公告、Think IT 公开连载与中文圈招聘/面试信息。我没有访问到 ow+ 的任何内部源码或机密文档（事实上它就是闭源），所以凡涉及”框架内某段代码/某个配置文件”的内容都来自资料综合，不是亲历——这一点先放在最前面。
一、为什么这份解析对 Java 工程师有价值
如果你正在或打算进入对日软件开发行业，几乎绕不开野村综研（NRI，Nomura Research Institute）体系：
- NRI 是日本头部 SI（系统集成）商，承接证券、保险、银行、流通、公共事业的大型基干系统；
- NRI 自有 Java 商业框架 ObjectWorks（内部简称 o3w）与升级版 ObjectWorks+（ow+），从 2000 年代沿用至今；
- 国内大量的对日外包/合作开发岗位（上海、大连、无锡、昆山、北京的不少公司）实际上都在做 NRI 项目的二级承接，理解这套框架等于理解项目的代码组织方式和开发规约。
很多人写过 NRI 框架解析，但能同时把框架机制 + 公开演进历史 + 中文圈生态讲清的不多。这篇就是。
二、框架演进全景
| 阶段 | 年份 | 关键特征 | 公开证据 |
|---|---|---|---|
| o3w（ObjectWorks） | ~2000 起 | 三层架构标准化；屏蔽底层复杂度 | 2008 年 NRI 内部 PPT、Think IT 综述 |
| ow+ R1.0 | 2009-01-13 公开 | Java EE 5.0 底座；STUDIO 工具 + 四张 Excel | mynavi 2009 公告、OSDN 报道 |
| ow+ 多次迭代 | 2009–2017 | 与既存系统集成加强、开发规则强制 | impress.co.jp 报道 |
| ObjectWorks X | ~2018 | 底层切换到 Spring；云原生；10 年 LTS | NRI 公开资料 |
| OW X + SBOM | 2023-06-15 | OpenStandia 提供 SBOM，软件供应链安全 | NRI 官方发布 |
配套基础设施（同期发展）：
- NRI オープンソースマップ（2007/2008 起）：NRI 内部对上万款 OSS 软件做的质量评级，最早公开化、推动 NRI 体系内的 OSS 采纳；
- OpenStandia（2008 起）：NRI 商业化的 OSS 技术支持服务，2023 年起为 ObjectWorks X 提供 SBOM（软件物料清单）支持。
也就是说，NRI 不是”突然拥抱开源”的，而是从 2007 年起就有一条逐步开放的暗线；2023 年的 SBOM 接入是这条线的最新节点。
三、o3w（ObjectWorks）阶段：标准化的奠基者
3.1 解决的问题
2000 年前后，Java EE 规范刚落地，企业级开发有三大痛点：
- 代码风格不统一，外包团队尤其乱；
- 基础设施门槛高：数据库连接池、事务管理器、日志、异常处理，每个项目都要造一遍轮子；
- 大规模团队协作时，质量底线不可控。
NRI 的解法是 o3w（Object 3Tier Infoworks）——把表现层 / 业务逻辑层 / 数据访问层物理隔离，把基础设施封装成标准化 API，把”自由发挥”的空间收窄到最小。开发者能写的代码形态被框架约束得只剩几种，资深架构师和初级程序员写出来的东西结构高度一致。
3.2 与 ParcPlace ObjectWorks 无关
中文圈很容易混淆的两个东西：
- NRI 的 ObjectWorks：Java 时代的 SI 框架，2000 年代；
- ParcPlace ObjectWorks：1990 年代 Smalltalk 的开发环境（后变 Cincom Smalltalk），与 NRI 没有任何关系。
搜索相关资料时建议带上前缀”NRI”或后缀”SI 框架”。
四、ow+（ObjectWorks+）阶段：模型驱动 + 规则强制
4.1 升级动机
2008 年前后 NRI 自家总结（《ITソリューション》2008-08 特集：オープンソースの活用に向けて）：ow+ 之前的纯手写代码越来越繁琐，boilerplate（样板代码）膨胀到 SE 写不动、PG 看不懂的程度。
ow+ 的解法不是改语言、不是换 ORM，而是把”模式化劳动”全部挪到工具里：SE 在 Excel 里填表，工具一键生成 Java 代码。
4.2 核心利器：STUDIO 工具与四张定义表
ow+ 开发被强制分成四个阶段：定义表作成 → 源码自动生成 → 编码 → 单体测试。其中定义表就是四张 Excel：
| 定义表 | 填什么 | 生成的代码 |
|---|---|---|
| 画面遷移定義 | 源画面、触发 Action、目标画面 | 画面迁移元数据 / 路由配置 |
| データ定義 | 字段名、类型、是否必填、是否全角、是否数字 | DTO + 校验注解（Annotation） |
| アクション定義 | Action ID → Service ID 映射 + Web 层 DTO | Action 类骨架 |
| サービス定義 | Service ID → Logic 类映射 + 服务/逻辑层 I/O DTO | Service / Logic 骨架 |
几个关键细节常被外行误读，需要划重点：
- 生成代码 ≠ 全部代码。生成的是骨架（DTO、Action、Service 的壳、配置文件），业务逻辑和 SQL 由人写。这就是原文档里”区分生成代码与手写代码”的来源——很多新人会在生成代码里硬塞逻辑，结果升级 STUDIO 后被覆盖，坑很深。
- 校验在生成时就嵌进了注解。Excel 里勾”必须/全角/数字”等属性，工具会在生成 DTO 上写
@NotBlank、@Pattern这类 Bean Validation 注解。前端提交参数后，框架自动拦截做校验，失败时把 Message ID 塞进上下文并跳转错误页——这就是”前端参数 → DTO → 下层”全自动化的实现。 - Action 是表现层入口，Service 是业务层入口。Action 不写业务逻辑，只做参数组装和路由；Service 才有真正的业务流程。
4.3 严格分层：PL 与 BL
ow+ 通过 STUDIO 强约束 DTO 传递流向来保证分层：
[画面 (JSP/Taglib)] ──画面 DTO──▶ [Action] ──Web 层 DTO──▶ [Service] ──服务层 DTO──▶ [Logic]
│
数据访问层 DTO
▼
[DAO / SQL]每一层都有自己的 DTO 类型，不允许跨层穿透。这听上去”过度设计”，但对几百人合作的大型项目来说，这是防止”逻辑溢出”的硬性边界——也是 NRI 2009 公告里强调的”開発ルールの順守を担保”（保证开发规则的遵守）。
4.4 表现层 / 业务层 / 数据层的技术细节
表现层与控制层
- 底层用 JSP 自定义 Taglib 做渲染，标签与校验机制绑定；
- Front Controller 模式拦截请求，按 XML 配置路由到 Action 类；
- 参数校验失败时，框架把错误码注入上下文并跳错误页。
业务逻辑层
- 事务管理：声明式事务，在 XML 或注解里定义哪些 Service 方法开事务；
- 异常处理：严格分两类
SystemException：数据库宕机、连接失败等基础设施问题——框架捕获 + 严重日志 + 通用错误页；BusinessException：业务校验失败（如余额不足、状态非法）——开发者手动抛 Message Code，框架转成用户提示。
数据访问层
- SQL 外部化（类似 MyBatis 的做法），写 XML 或特定配置文件，不走全自动 ORM；
- 底层自动 PreparedStatement 防止 SQL 注入。
这种”非 ORM”的选择是有讲究的——保险、证券类项目经常需要非常复杂的报表 SQL，Hibernate 自动生成的能力不够；保留手写 SQL + 外部化是企业级系统的现实选择。
4.5 批处理衍生：ObjectWorks/BT
Web 之外，ow+ 通常配一个批处理框架 ObjectWorks/BT（Batch）。它强制三段式生命周期：
- Initialize：读配置、获取游标；
- Process：逐行处理、定时 commit 防 OOM；
- Terminate：关流、释放资源、记录执行状态。
这种结构化的好处是：批处理一旦出了问题，能精确地知道卡在哪一段、重启时从哪里接着跑。对日外包项目里”障害対応”（故障应对）是核心 KPI，BT 的设计就是冲着这个去的。
五、公开资料地图
ow+ 是闭源框架，但有几条公开线索可以挖到结构化信息。
5.1 Think IT 连载（最核心）
日本 Think IT 站（thinkit.co.jp）曾连载过由 NRI 系统顾问撰写的系列文章：
- 综述篇：《Java EE 上の SI 向けフレームワーク》（含四节：架构标准化、通用功能、扩展功能、开发工具）
- ow+ 专篇：《ObjectWorks+ によるアプリケーション開発》（属于”進化するWeb開発フレームワーク”专栏）
署名作者可见深津康行（深津康行）与佐野大輔（佐野大輔）。在 NRI 内部很多架构规约书会引用这两位的文章作为外部参考。
5.2 NRI 官方公告
ow+ 的几个关键时间节点（可检索到）：
- 2009-01-13：《NRI、Java EE 5.0 を採用した SI フレームワーク「ObjectWorks+ R1.0」を発売》——首次公开销售；
- 2009-05-21：《NRI が開発フレームワーク新版，AP サーバーを立ち上げず単体テスト可能に》——可以在不启 AP 服务器的情况下做单元测试；
- 2009-05-13/2011：《既存業務システムとの連携性を高めた SI フレームワーク新版》、《ITpro EXPO 2011：Web アプリ開発支援ツール群を展示》——展示了 STUDIO 类工具；
- 2023-06-15：《野村総合研究所、ObjectWorks X、OpenStandia より SBOM 提供を開始》——OpenStandia 为 ObjectWorks X 提供 SBOM 服务，进入软件供应链安全合规时代。
5.3 NRI 同期的开放化布局
理解 ow+ 的演进不能只看框架本身，要看 NRI 的整体开源战略：
| 时间 | 动作 | 含义 |
|---|---|---|
| 2007/2008 | NRI オープンソースマップ 公开发布 | 把内部 OSS 评估结果公开化（最早一版覆盖 12000+ 软件包） |
| 2008 | OpenStandia 商业化 | 把 NRI 的 OSS 技术支持做成可购买的服务 |
| 2009 | ow+ R1.0 用 Java EE 5.0 + 部分 OSS | 框架底座开始使用开源组件 |
| 2023 | OW X + SBOM | 进一步把安全合规也外包给 NRI 自家的支持体系 |
这条线解释了 为什么 2018 年 NRI 决定做 ObjectWorks X：不是单纯技术升级，而是 10 年开源化战略的自然延续。
六、ObjectWorks X：转型到 Spring 全家桶
2018 年前后 NRI 推出 ObjectWorks X，原文档里写”核心框架从早期自研闭源体系全面转向了 Spring Framework”——这句话是对的，但要补几条结构性原因：
- 招聘：ow+ 这种封闭框架，新人上手需要数周；用 Spring 之后能从市场直接招到熟练工程师。
- 容器化：ow+ 当时的设计没有面向 Docker/Kubernetes；新项目上 K8s 是刚需，原框架的部署单元、配置中心、状态外化全部要重写。
- 生态成熟：Spring Boot + Spring Cloud 已经把企业开发的”基础设施”做得非常完整，自造轮子 ROI 越来越低。
- 10 年长期支持（LTS）：NRI 给 OW X 承诺包括 Spring 与相关 OSS 在内的 10 年支持——这个承诺只能建立在”用主流开源”上，因为自研框架的 LTSC 是 NRI 一家承担。
- SBOM 与安全合规：OW X 通过 OpenStandia 提供 SBOM，能告诉客户”这个系统用了哪些开源、版本是什么、有什么 CVE”——这是金融保险类项目越来越硬的合规要求。
OW X 不是 ow+ 的小升级，而是**从”框架产品”转向”框架 + 生态服务”**的商业策略调整。
七、对日 Java 工程师的项目实战路径
这部分是我最常被问到的——接触到 ow+ 项目时怎么上手？
7.1 上手顺序
- 拿到三份核心文档（优先级从高到低）：
- 《アーキテクチャ規約》——架构规约，整个项目的”宪法”；
- 《開発ガイド》——开发指南，含编码规范、命名规约、必须遵守的约束；
- 《STUDIO ユーザーズマニュアル》——STUDIO 工具的用户手册；
- 找到 sample/tutorial 模块：项目里通常会有一份完整可跑的小示例，模仿它最快。
- 搞清”生成/手写”边界：标注
// 自动生成，严禁修改的是 STUDIO 出来的骨架，你只该填 Service/Logic 和 SQL。
7.2 五个实操建议
- 第一次接手先 Debug 全链路：从前端一个按钮点击开始打断点，跟一个请求从 Filter → Front Controller → Action → Service → Logic → DAO 的完整生命周期。
- 熟读项目里别人写好的 Common Utils：日期处理、消息获取、文件读写这些都有共通方法，别自己造轮子。
- SQL 外部化的习惯：即使能用 ORM 写，也要把 SQL 单独放出来，方便后续 DBA 和性能调优。
- 异常选 SystemException 还是 BusinessException：能用 BusinessException 的别抛 SystemException——前者会展示给用户，后者只进日志、给通用错误页。
- 不要在生成代码里加业务逻辑：升级 STUDIO 之后所有
// 自动生成的代码会被覆盖，你加的东西会消失。
7.3 给面试 / 跳槽准备的视角
如果你是对日 Java 工程师准备面试，ow+ 相关经验可以这样讲：
- 不要只说”我用过 ow+“：要说”我在 ow+ 项目里负责过 X 模块的 Logic 层，写过 Y 类的业务规则，做过 Z 性能优化”——把”填空机器”的观感翻成”我理解框架内部、能在约束下做出正确选择”；
- 带上跨项目的可迁移能力：ow+ 的分层、DTO 隔离、SQL 外部化思想在 Spring 项目里也是好习惯，把这些讲出来，招聘官立刻知道你不是”只会按表填代码”；
- 主动补 Spring 经验：OW X 已经在 NRI 项目内铺开，会用 Spring Boot 的对日开发人员正在变成紧缺资源——这是个好跳板。
八、价值 / 局限 / 常见误解
价值
- 质量下限有保证：大规模对日外包项目的最大风险是水平参差，ow+ 用”框架硬约束 + 工具生成”把下限托住；
- 设计与代码同步：Excel 就是设计文档，文档和代码不会脱节（前提是没人手改生成代码）；
- 新人上手快：填表 + 在指定位置写代码，2 周能上手做模块，远快于从零理解一套 Spring 全家桶。
局限
- Vendor Lock-in：离开 NRI 生态，ow+ 经验的市场价值接近零——这是最大的隐性成本；
- 过度框架化：一些原本直接写就能搞定的逻辑，被迫走完 DTO→Action→Service→Logic 一长串，影响效率；
- 学习资源稀缺：框架闭源 + 文档多为日语，外部能查到的资料只有 Think IT 那几篇和零星招聘帖。
常见误解
- ❌“ow+ 等同于 NRI 的 Spring Boot”——错。ow+ 是独立商业框架，OW X 才是它的 Spring 化继任；
- ❌“ObjectWorks = ParcPlace ObjectWorks”——错。两者无关，搜索时务必带前缀；
- ❌“o3w 已经停用”——部分老项目仍在维护，但新项目基本直接上 OW X；
- ❌“只要会用 STUDIO 就能在 NRI 项目干活”——STUDIO 只是工具，架构规约 + 业务理解 + 跨层 DTO 设计才是核心能力。
九、如果你想挖更深
按可访问性排序：
| 资料 | 可访问性 | 建议 |
|---|---|---|
| Think IT 综述与 ow+ 专篇 | 公网（thinkit.co.jp 系列） | 完整读 1123 + 1131 两篇 |
| NRI 官方公告（2009/2023） | 公网（mynavi、osdn、impress、nri.com） | 搜索”ObjectWorks+”+ “NRI” |
| NRI オープンソースマップ | 公网（thinkit + gigazine 旧报道） | 理解 NRI 的开源战略背景 |
| 架构规约 / 开发指南 / STUDIO 手册 | 仅内网 | 入职后第一时间申请 |
| 框架源码 | 仅 NRI 项目内 | 通过”读生成代码 + Debug 反推”间接获得 |
最实用的建议是：把 Think IT 那两篇打印出来反复读，胜过一切二手解读。
资料来源
公开资料（可在搜索引擎定位）：
- Think IT · Java EE 上の SI 向けフレームワーク（综述）
- Think IT · ObjectWorks+ によるアプリケーション開発
- Think IT · 深津康行 作者页
- Think IT · 佐野大輔 作者页
- mynavi / Tech+ · ObjectWorks+ R1.0 发布（2009-01-13）
- OSDN Magazine · 同上英文报道
- xtech.nikkei · 2009-05-21 单元测试升级
- ITpro EXPO 2011 · NRI 开发支援工具展示
- impress watch · 与既存业务系统集成加强
- NRI 官方 · ObjectWorks X + OpenStandia SBOM（2023-06-15）
- SlideShare · 17-C-4 NRI Axure 案例（含 ow+ 诞生背景）
- Liepin · 野村综研(北京) 大连办公室招聘（确认 NRI 在岸/离岸布局）
- hyron.co.jp · 海隆ソフト收购上海志明軟件 / 无錫智明創発（2019）
说明：本文涉及的 ow+ 内部细节（注解名称、XML 配置项、Action 基类命名等）来自两份内部向笔记与综合技术理解。文中凡涉及”框架内部代码”的描述均未亲历验证，请以你所在项目的实际架构规约为准。
评论
还没有评论，来留第一条吧。