JOSH:企业软件组合的新提议

  • Abel Avram
  • 郭晓刚

2009 年 4 月 4 日

话题:Scala架构

Grey Lens Man,这位戴灰墨镜的神秘人发了一篇很有意思的博客文章,谈正折磨着许多企业的遗留问题,并提出了一种新的软件组合作为解决之道——JOSH,也就是 JSON、OSGi、Scala 和 HTTP。

灰镜人先说了一个似曾相识的企业 IT 故事:

跟你说,我有个小问题——3 百万行 RPG 和 COBOL,5,500 个逻辑和物理文件分散在几台不是很便宜的 AS400 上。过了这么些年,情况更妙了——系统经过克隆和分支,现在有好几个不兼容的版本分布在全世界。

实际维护起来不是一般的痛苦:

折磨人的细节我就不说了,我就说个例子吧。在这 2.5T 数据当中,客户文件里面有个特殊的标志,决定了客户与系统的交互方式将会有根本区别,而它的位置是 Filler3 左数第三个字节(译注:COBOL 习惯用 Filler 补足记录长度或者分隔字段,本不应存放有意义的数据)。还有一个文件,它的“账户 ID”列有时候真的保存了账户号码,有时候又不是,真难为死我们了。你再猜猜“邮编”列存的是什么?(提示:一点都不像邮政编码)。

谈到问题的解决之道,灰镜人很坦白:

没人想让它 [遗留系统] 苟延残喘下去,所以再牺牲人力去与熵作对,或者给这头猪涂点 SOA 的口红,都不是我们想要的。问题是根本性的、系统性的。

灰镜人提出的方案是 JOSH,也就是JSON OSGi Scala HTTP:

JSON 完成了 XML 许下的承诺。简单易懂,人类和机器都能轻松使用的高效数据表示。序列化 / 反序列化速度持平或超过 XML、Thrift 和 Protocol Buffers。没错,我会损失 XSD Schema 类型检查、SOAP 和 WS-* 的标准化。可我看划得来。

OSGi 是标准化的组件和服务动态模块框架。挑一个日志组件、一个 HTTP 服务器组件、一个别的什么组件,加上你自己的组件做集成,一个专用的应用方案就拼好了。精简的部署方案加上真正的可替换能力。我失去的是什么呢?加载了 25 个框架的巨型 J2EE 应用,SCA 和 XML 的配置深渊。成交。

HTTP 简单,高效,足够快,又受到广泛的支持。为了把简单的数据从 A 移到 B,搞出一个又一个复杂的专有协议,还因此要和防火墙端口一类的麻烦纠缠不清,我受够了。是的,HTTP 不够完美。但只要有可能,我乐意。

所有接口都将是基于 HTTP+JSON 的简单 API,向 REST 靠拢。这就是 JOSH 组合立竿见影的效果。

Scala 是 JOSH 组合中最艰难又最容易决定的选项。我反复思量,远比 JSON 或 XML 或 Thrift 或 Protocol Buffers 的抉择困难得多。

Ted Neward 欣赏灰镜人的方案,但也指出了一些顾虑

表面上看,这个组合非常漂亮。管理 Java 系统的版本和模块,OSGi 是很可靠的规范。更重要的是它为人们所熟悉、不容易出问题、处理典型问题方面又久经考验。……

但有几点需要审慎考虑。JSON 是一种简单的传送协议,没错,但这件事有好坏两个方面(比如它是以对象为中心的,因此在处理某些关系的时候会遇到跟对象一样的问题)。而且它不像 XML 那样无处不在。是的,XML 有滥用的问题,但当为了和各种不同系统通信而寻找一个共同基础的时候,普遍性是不得不考虑的问题。……

HTTP 很适合远距离的、客户端发起的通信,但它绝对存在局限(灰镜人也坦率承认,值得赞扬),至少对于面向内部的应用存在缺点。

JOSH 组合还缺了很重要的一层,持久化层的方案灰镜人尚在寻找当中。Ray Krueger 提了一个 JOSCH 的建议,其中的“C”代表 CouchDB。灰镜人赞成这个方向,但他更推崇Cassandra或者Voldemort。Neward 也赞成 CouchDB 是可以考虑的方案,还提出db4o也值得考虑。他甚至给.NET 也想了一套对应的组合:JSON + Assemblies + F# + HTTP = JAFH。

查看英文原文:JOSH: A Proposed Software Stack for the Enterprise

Scala架构