时间很长；现在很短；距离很长；相遇很短
Posts tagged SOA
从Twitter等看企业软件架构（一）
Jun 28th
企业软件发展到现在，普遍面临的一个问题是自身积重难返。系统功能越来越多，数据存储到处都是，技术标准五花八门。几乎任何一个做实施的都头痛每天遇到的各种历史遗留问题。事情就是这样，企业软件已经是一个构造复杂的精密系统，无数的管道线路纠结在一起，牵一发而动全身，难以为继。
问题
看一下业务流程管理技术趋势图：
摆在面前的当务之急就是SOA化的系统结构，然而，除了在政府机构有比较好的案例意外，其他行业鲜有成功的事实，原因又在哪里呢？不负责任的分析一下，至少有以下几点：
对庞大的现有系统改造成本巨大，SOA是需要一个规模效应的，当系统间不断的整合才能发挥其低耦合的结构特，在此之前的投入往往会被看成是不值得的，这里有一个门槛效应。
业务和技术要求高，SOA不仅是一个技术课题，也是一个业务课题。当前大多数机构和组织的设计能力还不能达到全面应用的要求。软件架构往往在分布式和集中式之前博弈，分布式的高要求往往让很多项目选择折中的方案。“二步提交”等分布式系统特有的技术问题带来的风险考验开发人员的能力和系统的综合管理能力。
规格差异化，各厂商为了自己的利益，推广各自的方法论，互相之间缺乏沟通，壁垒明显，势必造成技术推广的困难。
巨大的挑战面前是巨大的市场，SOA默默挣扎了这么多年，依然坚挺，其背后是非常不错的理论架构。
一种思路
其实说穿了，SOA无非就是解决系统整合的方式，互联网是分布式系统的基础，而Web2.0是内容和服务整合最成功的例子。
翻开Twitter, FriendFeed, Facebook的API文档，绝对找不到一个ESB，SOA的名词，能看到的无非是JSON, XML, RSS, ATOM，或者单独说个REST。但是解决的问题和SOA是一样的，系统整合，标准协议，高可用性，服务寻址等等。但他们看起来很不规范。从某种意义上说，属于SCA(Service Component Architecture)的理念。
SCA与SOA最大区别就是给服务实现松绑，很多实现不需要再去应用个别高端厂商发明的WS-*，可以更灵活的应用互联网上被验证有效的方式。SCA保留了SOA理念中的核心，更加强调组件的概念，弱化技术性的限制。SCA是个非常复杂的主题，这里是一个相对容易理解的SCA白皮书。
比较一下几种格式，或许能看得更清楚：
| 数据格式 | 可读性 | 数据转换 | 扩展性 | 开发难度 |
| SOAP | 较差，所有格式中最复杂的 | 较容易，可以根据定义生成类型 | 可扩展，有一定难度 | 很高 |
| XML | 看设计能力 | 需自定义转换规则 | 任意扩展/或利用命名空间 | 较高 |
| JSON | 清晰易懂 | 没有类型定义，在强类型端处理困难 | 任意扩展，缺少规则 | 简单 |
| RSS/ATOM | 比较清晰 | RSS多种不同版本，ATOM相对统一一些，整体来说较简单 | 通过命名空间扩展 | 一般 |
| YAML | 可读性最好 | 可以容易的序列化与反序列化 | 任意扩展，缺少规范 | 简单 |
从以上比较不难看出，单纯从开发和功能上讲，新的YAML最有优势，也容易继续改良取长补短。而标准最多的SOAP实在是有点笨重，难以和新格式竞争。
未完待续
七街开发报告1104
Nov 5th
新技术是很好的事情。然而如何应用是另外一件事情。
新七街开发过程中最大的痛苦就是没有可供参考的例子。
REST的概念原本不是Java兴起的，仅有的RESTlet试图做的事情太多，Struts2是非常具有实验精神的框架。然而通过插件来实现的时候，文档上面就太痛苦了，只能遇到问题去mail list询问。虽然不是完全的语言不同，但误会也是常常发生。
不过，除去以上因为不成熟带来的种种不变，七街的REST开发模式还是很令人舒服的。
- MDA，模型驱动：因为完全的ORM，模型在整套架构里面举足轻重。好的模型除了3NF要求以外，应当满足：支持业务功能；保证数据完整性；可演化。后两者于模型质量是及其重要而相互制约。这种时候，经验可能更重要，但如果没有严格的实践过程，这种经验也无从获取。可演化是一个很有意思的概念，现在有提出数据库重构；包括RoR中也有工具来反映对数据库的变革。之所以没有全套使用Rails，并不是对现有技术的割舍不下。ORM不能解决关系模型中的问题。面向对象就完备性和理论而言，还无法和关系模型完全对照。关系模型的具体物理实现也差异巨大。再加上性能和数据安全的考虑，完全的ORM是难以令人信赖的，毕竟没有基于ORM的数据管理工具。
- 业务逻辑：业务逻辑会因为高质量的模型而得到异常的简化。而在业务逻辑实现的时候，一些有效而简单的工具包至关重要。按照契约式思想分解业务对象时，可以很简单的按照2:8原理分解重复逻辑，大幅降低开发代码量。更少的逻辑，更少的测试，就意味着更健壮的软件。
- 表现层：REST使得表现层可以随意组合。不同的数据展现方式，只需要一次业务逻辑实现。配合MDA，所有的信息都可以相互解耦。从而在一开始就重点实现业务功能，最快进入系统集成阶段。
- 低耦合的架构：基于Session和基于应用的变量与常量能够简单的存取；模块间相互独立的版本控制。虽然还没有达到一个理想的地步，但是下一步的改进也已经有章可循。第一阶段的主要目的在与尽可能的减少代码量，以此为目标来评价框架。
以上是种种好处，以下是种种不足：
除了美工与产品设计等难以短时间高质量的东西，还有很多问题有待解决：
- REST数据展现的方式：目前实现的三种 xhtml, json, xml 其中xhtml大概还需要大量工作符合各种标准，以及优化性能。json与xml从json-lib换到xstream又换回来，这些开源的组件的确有一些bug，目前使用的REST插件功能也过于简单虽然自己可以修改，但估计还会有许多的问题需要解决。另外，RSS以及ATOM应该也是必需的。
- 代码质量：单元测试覆盖率还远远不够。集成测试和压力测试也完全没有做。自动化工具的使用也仅仅是停留在第一个层面上。
- 代码重构：源码库已经积累了一段时间，重构也必须要提上日程了，只是目前重构的水平还亟待提高。
- 文档质量：虽然XP是不要太多文档的，但如果连路线图都不明确，那就是耽误时间了。
以上种种，时间和人手是大问题。
一些未来的可能性：
- ROA与SOA的比较。目前当然SOA在前，ROA完全没有成型的标准，难以产品化。不过ROA比SOA简单太多，再加上SOA虽有标准，但大多执行起来张冠李戴，良莠不齐，效果也将大打折扣。至少对于中小应用来讲ROA是完全胜任而迅速的，更提供了现成的API接口。
- 企业架构的复杂性在于，永远不会有一劳永逸的解决方案。这种情况下，技术型风险的控制是第一位的。在部分组件出错的情况下仍然可以进行业务处理是非常重要的。所以无论从架构或模型的设计上，都要求可查可控。数据审计是个必须重视的课题。
- 智能平台，Web3.0(semantic web)与数据挖掘。数据要素由数据结构、数据操作和完整性要求构成。换句话说，数据要可分辨，可计算，有效。因为在系统设计的各个阶段，从模型到系统IO，标准设计，互操作契约是第一位的。为了降低开发成本和风险，标准化是第一位的选择，其次是系统暗喻，再次是设计文档。系统暗喻也应当体现在设计文档中。
