Posts tagged rest

新技术是很好的事情。然而如何应用是另外一件事情。

新七街开发过程中最大的痛苦就是没有可供参考的例子。

REST的概念原本不是Java兴起的，仅有的RESTlet试图做的事情太多，Struts2是非常具有实验精神的框架。然而通过插件来实现的时候，文档上面就太痛苦了，只能遇到问题去mail list询问。虽然不是完全的语言不同，但误会也是常常发生。

不过，除去以上因为不成熟带来的种种不变，七街的REST开发模式还是很令人舒服的。

1. MDA，模型驱动：因为完全的ORM，模型在整套架构里面举足轻重。好的模型除了3NF要求以外，应当满足：支持业务功能；保证数据完整性；可演化。后两者于模型质量是及其重要而相互制约。这种时候，经验可能更重要，但如果没有严格的实践过程，这种经验也无从获取。可演化是一个很有意思的概念，现在有提出数据库重构；包括RoR中也有工具来反映对数据库的变革。之所以没有全套使用Rails，并不是对现有技术的割舍不下。ORM不能解决关系模型中的问题。面向对象就完备性和理论而言，还无法和关系模型完全对照。关系模型的具体物理实现也差异巨大。再加上性能和数据安全的考虑，完全的ORM是难以令人信赖的，毕竟没有基于ORM的数据管理工具。
2. 业务逻辑：业务逻辑会因为高质量的模型而得到异常的简化。而在业务逻辑实现的时候，一些有效而简单的工具包至关重要。按照契约式思想分解业务对象时，可以很简单的按照2:8原理分解重复逻辑，大幅降低开发代码量。更少的逻辑，更少的测试，就意味着更健壮的软件。
3. 表现层：REST使得表现层可以随意组合。不同的数据展现方式，只需要一次业务逻辑实现。配合MDA，所有的信息都可以相互解耦。从而在一开始就重点实现业务功能，最快进入系统集成阶段。
4. 低耦合的架构：基于Session和基于应用的变量与常量能够简单的存取；模块间相互独立的版本控制。虽然还没有达到一个理想的地步，但是下一步的改进也已经有章可循。第一阶段的主要目的在与尽可能的减少代码量，以此为目标来评价框架。

以上是种种好处，以下是种种不足：

除了美工与产品设计等难以短时间高质量的东西，还有很多问题有待解决：

1. REST数据展现的方式：目前实现的三种 xhtml, json, xml 其中xhtml大概还需要大量工作符合各种标准，以及优化性能。json与xml从json-lib换到xstream又换回来，这些开源的组件的确有一些bug，目前使用的REST插件功能也过于简单虽然自己可以修改，但估计还会有许多的问题需要解决。另外，RSS以及ATOM应该也是必需的。
2. 代码质量：单元测试覆盖率还远远不够。集成测试和压力测试也完全没有做。自动化工具的使用也仅仅是停留在第一个层面上。
3. 代码重构：源码库已经积累了一段时间，重构也必须要提上日程了，只是目前重构的水平还亟待提高。
4. 文档质量：虽然XP是不要太多文档的，但如果连路线图都不明确，那就是耽误时间了。

以上种种，时间和人手是大问题。

一些未来的可能性：

1. ROA与SOA的比较。目前当然SOA在前，ROA完全没有成型的标准，难以产品化。不过ROA比SOA简单太多，再加上SOA虽有标准，但大多执行起来张冠李戴，良莠不齐，效果也将大打折扣。至少对于中小应用来讲ROA是完全胜任而迅速的，更提供了现成的API接口。
2. 企业架构的复杂性在于，永远不会有一劳永逸的解决方案。这种情况下，技术型风险的控制是第一位的。在部分组件出错的情况下仍然可以进行业务处理是非常重要的。所以无论从架构或模型的设计上，都要求可查可控。数据审计是个必须重视的课题。
3. 智能平台，Web3.0(semantic web)与数据挖掘。数据要素由数据结构、数据操作和完整性要求构成。换句话说，数据要可分辨，可计算，有效。因为在系统设计的各个阶段，从模型到系统IO，标准设计，互操作契约是第一位的。为了降低开发成本和风险，标准化是第一位的选择，其次是系统暗喻，再次是设计文档。系统暗喻也应当体现在设计文档中。