架构设计—又见架构之SOA

        在经历了逻辑架构、物理架构、系统架构等抽象模式后，初次看到面向服务的架构时一时不知从何谈起，因为这确实是一个神一般存在的概念，“SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言”。难道当年DCOM、CORBA在制定初期不是这样定义组件模型的？更神奇的是这么一个普适概念在借助上了SOAP协议后竟然大火特火，这也难怪当Restful出来后就有了ROA的概念了。

        论是SOA还是ROA在笔者看来本质还是在系统的目标要求和资源约束下对逻辑架构下面的业务抽象模块的一个形象描述，动态的，对数据有明显操作的就是服务；静态的，对数据没有相对明显操作的就是资源。其实说白了，无非就是对程序=数据结构+算法中的算法和数据结构起了一个别名，说他们是架构，感觉有点太看得起他们了，这点还是老外比较实在，关于SOA到底是什么？Yefim V. Natis说：“SOA是设计原则”。如果这样来解释他那个神一般存在的概念，倒是也能说的过去。

那么软件设计的设计原则都有哪些呢？多如牛毛，但是始终占有一席之地就是重用原则。于是就从原始的粘贴代码，到接口声明，同编译器、同构机下二进制代码重用，到不同编译器、同构机下的二进制代码重用，以及其分支不同编译器、异构机下的二进制代码重用。再到后来就发展到了我们今天的主题SOA进程级别的代码复用貌似是很顺利成章的事情，可是真是如此么？应该不是，进程级别的代码复用在Unix族系统下是非常古老的技术，我们常见的各种命令行，当我们通过管道把他们组合起来使用时就是在进行进程级别的代码重用，其他操作系统也有支持，只是不像这般强大。难道说Unix组的操作系统是采用SOA架构开发的？这显然是荒诞不经的说法。

        至于“定义良好的接口和契约”则是同“人饿了要吃饭”一样，是不言而喻的真理，因为很多时候，关于重用，不是我们说想重用就能重用的。但是找到银弹了么？大名鼎鼎的《人月神话》中给我们下的主要论断就是：没有银弹。虽然在实践中大家发现了很多指导原则，比如有名的开闭原则、专一原则，甚至纯接口原则等。为此也有大牛专门出书《UNIXX编程艺术》，《COM本质论》等等但是能改变得了拙劣接口的出现么？不能。为此微软提出了DOP，面向领域的编程，视图让领域专家去解决这个问题，开源世界提出了AOP面向切面的编程，试图从一个个切面来来解决这个问题。或许还有其他解决方案。不过老实说，技术一线工作的时间长了，对各种概念也慢慢开始麻木了，在底层编程基础没有发生类似机器码像汇编码发生质变的情况下，任何概念的落地都离不开现有编程语言的实现，捏的再好的面团其实还是面团。

        继面向过程和面向对象编程后，影响笔者最大的还是面向函数的编程，在笔者眼里这三个是绝对可以称得上思想的，因为拉出他们任意一个都能独立的、完整的、自成体系的解释这个世界。但DOP、AOP却显然没有这通天本领。以最能体现AOP精神spring框架来看无非是写了一个基于xml语法的解释器，用户可以通过xml文档来描述来组合使用系统已有的组件。如果这都能称王称祖，那些以bash脚本为代表的动态组合使用组件(系统命令)的解释器和以c/c++的模版技术和预编译为代表的静态组合使用组件的编译器估计都会羞愧的难以抬头，因为虽然他们也是这么做的，可是这种高大上的荣誉他们估计还是会不自在的，毕竟胶水这种屌丝的叫法让他们已经习以为常了，叫一个TPL他们都感觉很牛逼了，虽然c++的模板技术早都有人证明是图灵完备的了。