作为以老版本为模子重做的解耦版本，这个大型互联网应用产品是从 2009 年中开始落地的。而我本人也是该版本的主创人员之一，到今日，团队已经发展到开发测试人数百人的大型互联网产品团队的规模，发布、割接和上线了许许多多个商用版本。
对架构的审视，对选型和设计的反思，不仅仅要在产品初创时期，更要在产品发展的整个过程中进行，团队做同类型产品的能力就是这样在不断总结和自我批评中成熟的。以下为个人观点，难免不对许多人的胃口，不过还是希望这些文字有足够到让人思考的价值。无论如何，对于这样一款产品，从如今的视角来解读它的历史故事，更别有一番风味。
—————————————————————————————
5 条成功的记录：
1、Portlet 技术作为整个架构的核心。
这一条既是成功的记录，也是失败的记录。
Portlet 给各个局点的不同定制版本带来了相当的页面定制灵活性，不懂 jsp 的管理员都可以按照自己的要求部署页面，通过简单的选择和拖动，将一个个内容丰富的频道展现出来。
另一方面，Portlet 对于栏目的扩展和定制保留了相当的灵活性，尤其是对于潜在的互联网应用按照栏目维度保持伸缩性方面，留足了空间。
2、持久层选择了更加轻量级的 iBatis，没有选择 Hibernate。
事实证明，iBatis 透明、简单，易于配置和使用，多数开发人员可以读透持久层的代码，擅长数据库的开发人员可以轻易地完成 Oracle 下 SQL 语句的调优，应用到 iBatis 的配置文件中去，并不需要太多 ORM 的技术积累，也不需要深厚的 Hibernate 调优技巧。
3、业务核心逻辑层得以抽象出来，独立成可以单独发布的 API 模块。
面对多种接入渠道，把核心业务通过 API 的行为抽取出来，给项目组带来的最大好处是：清晰的团队分工。
虽然 API 模块还不成熟，但是 API 的诞生和发展意味着可以让各个接入门户的开发和定制团队更聚焦在以展现为核心的工作上面，把业务代码的梳理交给专门的 API 团队去做。
从长远看，纯 Java 的 API 是干净、简洁和易于 UT 的，通过这种天然的方式隔离了持久层，也保护了核心业务的代码质量。
4、将功能的界面展示部分抽取成可重用的业务标签。
有人会对这个有异议，事实上，除了 FreeMarker 的性能确实让人不敢恭维以外，将界面的展示部分以标签的方式组件化带来的益处是很大的。
理想状况下，定制团队可以通过简单的标签插入、删减和修改，完成页面的定制工作，这比理解宏伟复杂的 jsp 页面，进行拷贝粘贴大法简单了不少。
5、基础设施稳定且有质量保障 。
基础设施包括日志、协议栈、License 等等，大多稳定而且易于使用。
比如异常体系，整个异常体系给开发带来了自然和轻松的异常处理流程，开发人员只需要更关注核心流程，把错误流程交给运行时异常去处理；不同的异常捕获层次给最终页面的错误展示和归纳带来便捷。
也有遗憾的地方，比如错误码比较纠结，错误码是团队内部讨论经过激烈的斗争和妥协的结果，有些过于庞大和繁杂了，这似乎更验证了：软件工程不是明主选举。
—————————————————————————————
5 条失败的记录：
1、Portlet 技术作为整个架构的核心。
这一条既是成功的记录，也是失败的记录。
Portlet 的许多特性还远未得到适合的发挥，譬如 Portlet 状态的保持、远程聚合的能力等等，却给开发人员带来了许多困扰，譬如页面分解困难，Portlet Session 和 Portal Session 的互异性，聚合流程性能问题等等，给开发人员定制手提出了更高的要求。
2、独立出基于 Portlet 核心的负责门户运营的 Portal 平台。
Portlet 规范作为一种聚合展现行为的抽象，通过组件化这样一种独立平台的形式，将页面控制聚合流程从业务页面展现和业务流程处理中剥离出来，开发人员得以将更多的精力聚焦在业务开发上面。
我想这是它诞生的本意，但是实际上，却带来了聚合流程复杂，方法调用栈过深等问题，而门户定制的开发人员，也必须经过相当的培训才得以上手。
3、通过 ajax 方式聚合 Portal 位于不同 war 包内的管理台页面。
本意是想让不同的管理台页面随着不同的 Portal 接入渠道分离发布，在展现时在页面上进行简单集成。
但由于浏览器的安全机制和对于不同域的会话独立管理的机制，使得它像恶魔一般被引进来，带来的不仅仅是定制的困难，开发人员理解的困难，还有一些因会话无法统一而导致的在不同域页面间信息传递时难以解决的问题。
4、保留 XDIME、WML 和 XHTML 三套 WAP 的模板页面。
当然也许这有一些人为无法控制的因素在里面。
XDIME 页面的目的就是经过终端适配组件转换成适合手机的 WML 和 XHTML 页面的，而由于局点或某些历史原因，WML 和 XHTML 还无法被干脆地摒弃掉，无论是一种主动的决策还是迫于无奈，带来的问题就是页面模板数量增加了两倍，给开发和测试带来了大量的工作量。
最终，WML 和 XHTML 模板还是被抛弃了，只保留了 XDIME 一套模板。
5、缺少一套简易的和可管理的 UI 框架。
前端开发是整个产品的瓶颈，尽管页面并不非常复杂，前端的混乱却已经带来了诸多问题，这些问题主要暴露在产品定制和最终的用户细节体验环节上。互联网产品是否专业，很大程度上是由产品的前端团队所决定的。
依据不同的团队级别、不同的前端展示要求，需要定制不同的 UI 框架。由展现的简易性，而且需要定制的基线版本，决定了我们的 UI 框架应该简单；并且由于开发成员普遍前端能力欠佳，决定的我们的 UI 框架应当便于控制和管理，不应暴露过于复杂的界面行为给普通开发人员。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
