从Twitter等看企业软件架构（一）
企业软件发展到现在，普遍面临的一个问题是自身积重难返。系统功能越来越多，数据存储到处都是，技术标准五花八门。几乎任何一个做实施的都头痛每天遇到的各种历史遗留问题。事情就是这样，企业软件已经是一个构造复杂的精密系统，无数的管道线路纠结在一起，牵一发而动全身，难以为继。
问题
看一下业务流程管理技术趋势图：
摆在面前的当务之急就是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实在是有点笨重，难以和新格式竞争。
未完待续
