zoukankan      html  css  js  c++  java
  • SOA: My Understanding (转载未来技术方向)

    ??? 菩提:紫霞在你心目中是不是一个惊叹号,还是一个句号?你脑袋里是不是充满了问号呢?
    ??? ----选自《大话西游》之《仙履奇缘》

    SOA,在很多人心里,也是一个问号、句号、或惊叹号:SOA到底是什么?SOA是不是对OO画了一个句号?我花了一些时间想了一下,看了一些东西,突然有一天就有了恍然大悟的感觉,“原来SOA是这样的!”——一个惊叹号。

    下面就说说我的体会,SOA是一个新东西,我对SOA的理解,有不正确的地方是很正常的。

    SOA, evolution or revolution?

    我觉得计算机方面几乎没什么技术是革命性的,大都是不断的在改良改良改良,性能提高一点、结构重新调整一下、代码更简洁清晰一点、封装层次更高一点,等等。即便是一些可能现在看来是承前启后的新技术,例如面向对象的方法,说穿了,从最简单的层面看也只不过是就是在Structure上面再加上了Method,就变成了类。

    我觉得SOA更主要是一种设计、思考的方式、方法,还包括不断重构整个架构的方法。例如,它强调不要预测未来——基本上够用一点就够,以后如果某个大系统的业务在发展,可以根据变化重新调整“服务”的编辑和合作方式——这就是Architecture上的重构。

    就像很多人说的,SOA并不是对OO的否定,而是在OO的基础上往前迈了一步:
    a) 原先我们都在写汇编,都是MOV AX,BX,然后越写越多,觉得不方便了,就搞些高级语言出来,就变成i=0,代码一下子就简洁很多了;
    b) 后来又越写越多,又觉得不方便了,就搞出结构化的语言来,就有了char myfun(int n),用函数去包装statements,就不再是满眼的goto而是调用函数,代码又一下子清晰简洁了很多;
    c) 后来又越写越多,Win32 API搞了上千个,我们又觉得不方便了,还觉得不好维护,就搞出了面向对象,层次上升到类和对象的高度,用一个类把很多数据和函数都封装、组织起来了,又感觉一下子方便了很多;
    d) 现在又到了一个新的阶段,人们渐渐开始觉得OO也不够方便了:组件太多,版本乱,维护、deploy也不方便,接口复杂,互操作查,而且在分布环境中用OO的语汇也不便于描述整个架构,系统的尺度在不断变大,为了适应这种更大尺度的设计、开发和维护,需要一种新的方法学。于是就有了新的东西,就是Services Oriented Architecture。

    所以,SOA并不是对前人的否定,而是一种提高。毕竟在service boundary内部,我们还是要用组件技术来实现,Web Services也要用OO的语言来开发(C#或者Java都成)。

    SOA == XML Web Services?

    回答Yes也是对的,回答No也是对的。你完全可以认为SOA就是分布式对象/组件+HTTP/SOAP/XML,这样认为并不是错误的,这只是看待问题的不同角度和层次而已。例如,牛顿的三大定律,以前是正确的,现在仍然还是正确的——虽然被证明,到了微观和高速世界不再适用,但这并不说明牛顿错了。

    就拿XML Web Services来说,我早先就一直认为它就是以HTTP为传输协议的远程方法调用(RPC),我现在还是这样认为。这种认识的好处是简单——尽量把新东西和老东西类比起来,描述清楚共同点(都是RPC)以及不同点(传输方法是HTTP),这样便于理解新东西。虽然现在在WS上面的东西越来越多——我痛恨死WSE 2.0了,太多东西——但是,XML Web Services的基本质地还是不变的,仍然是HTTP上的RPC。

    然后说对SOA的理解,如果你理解为“分布式对象/组件+HTTP/SOAP/XML”,这样也是对的。因为本来SOA就不是一样具体的技术,而是“方法论”层面的,SOA和OOA/OOD、重构等是一个层面的东西。而SOA本身需要有一定的技术支撑,这技术就是目前既是最好也是比较成熟的分布式组件、XML Web Services技术。这就好像我们说到OO,虽然我们知道OO!=C++,但是你不可能脱开C++单讲OO——那就太抽象了。脱开XML Web Services单讲SOA也会太抽象——什么是服务?什么是消息?什么是服务边界?如果你能把这些概念映射到Web Services的技术上去,就容易理解了。

    当然,SOA并不一定要用XML Web Services来实现——虽然这样是最好的。CORBA/DCOM/RMI/Remoting都可以用来实现SOA。只不过这样会失去一些有用的特性,例如互操作性会变差(Java怎么去调用Remoting呢?),服务的自描述也会变差(没有WSDL和WS-Policy的支持了),也没有目录服务的支持了(RMI可没有UDDI这种配套设施),跨服务边界的调用的可扩展性也会变差(二进制的RPC毕竟比不上消息通信)——当然,XML Web Services的性能比二进制RPC差,所以,没有银弹,不要滥用Web Services,就好像不要滥用B/S——很多情况下,WinForm远比WebForm好。

    Btw,如果能够把WSE 2.0 (Web Services Enhancements 2.0)发挥起来,SOA的方法可以得到技术上更有力的支撑。

    什么是Service?

    Service的具体定义并不重要。按照www.service-architecture.com的定义,A service is a module that can be invoked, that is assigned to a specific function and that offers a well defined interface。

    这里面最重要的关键字就是”a specific function”(一个/一组特定功能),这也是Service和组件技术的区别。下面两段代码是很典型的比较组件技术和Service概念的:

    //使用组件技术
    Customers customers = Customer.List();
    Orders orders = customers[0].Orders;
    Order order = orders.Add("ORDER001", customerData.Customers[0]);
    order.Lines.Add(new Product("53XYPR0D8"), 2);
    orders.Save();

    //体现了“服务”的概念
    CustomerData customerData = CustomerService.ListCustomers();
    OrderData orderData = new OrderData();
    OrderEntity order = orderData.Orders.Add("ORDER001",?? customerData.Customers[0].CustomerID));
    order.Lines.Add("53XYPR0D8", 2);
    CustomerService.AddOrders(orderData);

    从下面这个例子可以进一步理解什么是Service,以及SOA提倡的用XP的方法不断重构的意思:


    A service that implements authentication


    After the authentication has been externalized


    Avoids to duplicate authentication code in each service

    看上去的确也蛮简单的哦?的确是不难。一些重要的理论总是很简单的,例如经济学的一个最基本假设是说“每个人的任何行为都是为自己争取最大利益”——也很简单吧。简单归简单,重点在于如何在日常的设计、开发中不断的正确运用这种SOA的思考方式和重构方法,正确地把握服务的边界、服务的颗粒度等。

    发现和绑定你要的Service?

    我一直很质疑UDDI的价值。UDDI出来也已经有好几年了,曾经UDDI是作为一个Web Services的重要组成部分。但Web Services一直在往前走,UDDI却停滞不前,并未出现原先所预想的那种大量Web Services争相注册、需要用的时候从UDDI里面查询到最快或者功能最好的服务去绑定。

    UDDI的没有成功是有很多因素的。一个因素是Web Services的发展还没到足以扶持UDDI的量;另一个因素是UDDI有点类似于以前Yahoo那种Web上的分类目录——分类目录得要命的地方是需要每一个网站自己去注册,这太麻烦。所以后来这种主动的分类目录渐渐被Web爬虫取代掉了,居于次要地位了。

    但当初的设想仍然是诱人的。一个应用可以到一个目录服务上找到自己需要的Web Services,然后根据Web Services的自描述(比如WSDL)去绑定它。这种方式所描述的应用模式是很有前景的,甚至还可以带出很多商业模式来。关键在于现在的技术还太简单,例如WSDL,我就觉得它太简单,仅仅能服务于描述接口的定义(Schema和Contract层次的问题),至于更多的信息——例如什么访问方式、如何保证安全、服务质量如何等等,就类似于两个公司之间的Service Level Agreement——这些内容就无法用WSDL来描述了。包括以前CORBA里面的IDL也只能描述一下接口,而不能真地告诉我们“它是干什么的”——这恐怕还是要用自然语言来叙述。所以,到目前为止,所谓的“灵活的发现和绑定所需要的Web Services”仍然仅仅是一张画出来的饼。

    好在WSE 2.0里面有些新东西(例如WS-Policy等)可以提供我们更有力的手段来描述一个Web Services所提供的服务以及对调用者的要求/约定。这方面值得研究一下。

    SOA已经有人在用了么?

    任何新技术都会遇到这个问题的。Web Services看上去不错,但已经有人在实用了么?UML看上去不错,已经有人在实用了么?面向对象看上去不错,但已经有人在实用么?…SOA在很多人心目中也一定是一个巨大的问号。

    这里有两个SOA的实例,虽然不是完全真实的商业项目,但已经从虚无缥缈的理论和口头承诺走向了看得见摸得到的程序了。有兴趣的人可以装一下研究一下,我自己也打算近期找个时间装一下:

    1) Shadowfax
    官方描述:It will become the new reference application from Microsoft. It aims at showing how an SOA solution can be set up right now.
    下载地址 http://workspaces.gotdotnet.com/shadowfx

    2) PetshopSOA
    下载地址 http://dotnetguru.org/article.php?sid=286

    一些可以作为参考的网站:
    http://blogs.msdn.com/richturner666/archive/2004/03/02/83009.aspx
    http://blog.joycode.com/kaneboy/posts/14463.aspx
    http://www.service-architecture.com/
    http://dotnetjunkies.com/WebLog/seichert/
    http://www.dotnetguru.org/us/articles/SOA-Softly/SOA-Softly.html
    http://www.15seconds.com/issue/031215.htm

  • 相关阅读:
    Atitit.ati orm的设计and架构总结 适用于java c# php版
    Atitit.ati dwr的原理and设计 attilax 总结 java php 版本
    Atitit.ati dwr的原理and设计 attilax 总结 java php 版本
    Atitit. 软件设计 模式 变量 方法 命名最佳实践 vp820 attilax总结命名表大全
    Atitit. 软件设计 模式 变量 方法 命名最佳实践 vp820 attilax总结命名表大全
    Atitit 插件机制原理与设计微内核 c# java 的实现attilax总结
    Atitit 插件机制原理与设计微内核 c# java 的实现attilax总结
    atitit.基于  Commons CLI 的命令行原理与 开发
    atitit.基于  Commons CLI 的命令行原理与 开发
    atitit.js 与c# java交互html5化的原理与总结.doc
  • 原文地址:https://www.cnblogs.com/daitengfei/p/368148.html
Copyright © 2011-2022 走看看