- 浏览: 5166256 次
- 性别:
- 来自: 天津
博客专栏
-
实战 Groovy
浏览量:29341
文章分类
- 全部博客 (639)
- 代码之谜 (6)
- JavaScript quirks (5)
- 程序员 (92)
- Java (93)
- BT编程 (7)
- html/css (64)
- Groovy&Grails (42)
- Android (20)
- C/C++ (5)
- PHP/Perl/Python (46)
- 经典文章 (51)
- CodeIgniter (14)
- JQuery (10)
- 笑话 (4)
- 其他 (32)
- javascript (69)
- 云计算 (0)
- html5 (7)
- 面试 (8)
- google (3)
- nosql (2)
- nodejs (11)
- go (5)
- erlang (1)
- 小常识 (3)
- 冷知识 (5)
- database (4)
- web (12)
- 架构 (12)
- Exception (0)
最新评论
-
jqw1992:
https://www.chromefor.com/libra ...
[福利] 开发者必备的 Chrome 插件——ChromeSnifferPlus -
litjerk:
初步算了一下,目前最最精简的Win98版是5M,他5个小时多敲 ...
让人目瞪口呆的三位世界级电脑大师 -
379855529:
。。似乎重点没说NIO啊,前面基础只是铺垫的很好的,可是我要的 ...
Java NIO与IO的详细区别(通俗篇) -
springmvc_springjpa:
spring mvc demo教程源代码下载,地址:http: ...
一步步开发 Spring MVC 应用 -
匡建武:
Good
四个程序员的一天
原文:http://www.infoq.com/cn/articles/tilkov-10-soa-principles
在与许多客户的接触中,我发现有必要建立一套SOA的基本原则。下面的部分将介绍SOA中应有的基本原则。这些并非绝对真理,它们更像一个用于SOA相关讨论的参考框架。你会发现:前四项衍生自Don Box提出的四项原则,尽管随着时间的流逝,这四项原则的描述可能已经有了些变化。
相关厂商内容
1. 明确边界:服务被调用时,与实现其功能相关的内容都应被传递过来。对服务的所有访问都应该通过公共接口进行。调用服务时,非隐含的假设是必须的。“服务与消息紧密联系,因为参数进出服务的唯一方式是通过消息进行的”。作为通用的模式,服务调用不应依赖于共享的上下文,而应被作为无状态的模块。契约描述了服务的功能性与非功能性的能力和特点,管理着服务提供的接口。服务调用是一个具有业务逻辑效果的行为,可能有大量的资源开销,并且导致一系列不同于本地方法调用和远程过程调用的错误。服务的调用绝非远程过程调用。
服务的使用和提供应该尽可能地简单,因此与服务间的交互没必要被隐藏得太多。在SOA中,服务发送和接收的消息、服务契约以及服务本身都应当是最好的构件。这就意味着,例如,被用到的编程模型和工具至少应该提供一个API,这个API会帮助服务的编程人员了解上述概念。总的来说,一个明确的接口会封装服务的内在实现,而服务通过该接口发布自己的功能;与服务交互是一个具体的行为,它依赖于服务使用者和提供者之间消息的传递。
2. 共享契约和架构,而不是类:基于一份服务描述(一份契约),服务使用者和服务提供者都可以获得使用或提供服务的全部所需。根据松耦合原则,服务提供者不能依靠服务使用者来重用那些依赖于使用者环境的代码。毕竟,服务使用者可能使用不同的开发环境和运行环境。这条原则给SOA体系中所能交换的数据加上了严格的限制。理想的情况是,数据以符合一种或多种模式的XML文档形式被交换,因为这种方式可应用于任何你能想到的编程环境。因此,因为这条原则在基于DCOM和基于RMI的环境中是不可能被遵守的,所以这两种环境基本上无法成为SOA的可用选项。
3. 策略驱动:为了与服务交互,必须满足以下两组不同的要求:
例如,一个服务提供者提供了能够精确满足用户需求的服务,但该服务是基于JMS的,可使用者只能使用HTTP方式(比如,服务被应用于.NET平台)。服务提供者可能要求消息级别的加密采用XML加密标准,而使用者只支持采用SSL技术来保障传输层上的安全。即使在那些交互双方都拥有足够能力的案例中,它们的这些能力仍旧需要被“启用”。例如,提供者可能根据不同的使用者需求,对响应的消息使用不同的算法进行加密。
为了使尽可能多的形形色色的使用者能对服务进行访问,一种策略机制已经被作为SOA工具集的一部分引入了。在服务接口对功能进行描述的同时,策略对不同的,非功能性的能力和需求进行了指定。(译者注:策略指定的是服务之外的补充信息,是对服务使用者提出的特征要求)。
4. 自治:与明确边界原则相关,服务自治意味着,接口成为服务与外界联系的唯一方式,至少从SOA的角度来看是这样的。需要注意的是,服务的运行环境一定是可变的。例如,在丝毫不影响使用者的情况下,就可以从轻量级的原型实现转换到成熟的、基于应用服务器的协同组件集。服务能够被彼此独立的修改、部署、发布新版本和管理。服务提供者不能寄希望于服务使用者,期望它们依靠自己的能力迅速适应新版本的服务,有的使用者可能甚至没这个能力或者根本不愿去适应新版本的服务接口(尤其是当这些服务接口超出了服务提供者控制范围的时候)。
5. 采用可传输的协议格式,而非API:服务通常采用协议格式来发布,协议格式应该是明确的、可传输的并且被服务所支持的。这一点与前两条原则非常相关,但却带来了新的见解:为保证一个服务最大程度的可访问性(及长期的可用性),只要交互过程遵守为该服务定义的策略,那么由任何依照服务接口进行消息交换的平台都可以访问该服务。例如,通过以这一原则来测试主流的动态编程语言(如Perl、Python或Ruby),我们可以去考虑该语言能否使用或提供一个特定的服务。虽然,在现有的技术实现里,这条原则可能还没有发挥作用,但这个思路可以作为下列准则的试金石:
6. 面向文档:服务交互时,数据是以文档的形式来传递的。文档是一个被明确模块化的,有层次结构的数据容器。面向文档的一个重要特征就是自描述。最理想的情况下,文档是对现实世界中的文件(如订单、发票或帐单)的建模。文档应该被设计来确保它在问题域的上下文中发挥作用,这意味着它们可能应用于一个或更多的服务。
与现实世界的纸制文档相似,和服务交换信息的文档将包含冗余的信息。例如,文档中可能同时包含了客户ID和客户地址信息(尽管客户ID可能已经足够了)。这种冗余是可以接受的,因为它将服务使用者和提供者双方的服务接口和隐含数据模型隔离开来。应用面向文档的模式的同时,服务调用成为有意义的业务逻辑消息的交换,而非上下文无关的RPC调用。虽然通常可以认为XML将被作为服务文档的格式和语法,但它还没有成为标准。
在一个SOA连接中,参与者之间的消息流转于不同的系统,使得各个系统之间彼此独立。松耦合原则要求参与者对共知的依赖越少越好。当消息在分布式对象或RPC基础架构中发送时,客户端和服务器端使用由同一个接口描述文档生成的代理类(stub和skeleton)。如果不是这种情况的话,当契约不支持双方的交互时,通讯就会停止。因为这个原因,RPC风格的基础架构要求客户端和服务器端程序代码的同步运行。
7. 松耦合:多数SOA的倡导者都认为松耦合是一个很重要的概念。不幸的是,对于究竟哪些特征造成一个系统松耦合,有许多不同的看法。一个系统可以在多个维度表现为松耦合或紧耦合,它依赖于具体的要求和上下文,系统可能会在一些维度是松耦合的,在另一些维度是紧耦合的。这些维度包括:
创造一个满足以上所有维度的松耦合系统,既不可行,也没必要。不同类型的服务要做不同的取舍。Carlos Perez的经典之作中(如这里和这里)有更多的关于松耦合各个维度的讨论。
8. 遵循标准:一个SOA应用中应遵循的一个关键原则是,信赖标准而非专有的API和格式。标准存在于技术方面,如数据格式、元数据、传输协议;也存在于业务层面,如文档的类型。(例如,UBL中所提到的那些)(译者注:UBL定义了业务文档的通用XML库,UBL的文档类型包括订单、发票等)
很显然,一些人认为专有的解决方案,如一些EAI或消息服务提供商提供的方案,都遵循SOA原则。这个原则不遗余力地强调标准的重要性。当然,由于有太多可供选择的标准,什么情况用何种标准成了颇具争议的问题。标准的一个重要方面是它的可接受性(在Web服务的标准中,基本上可以认为“Microsoft肯定要插上一脚”)。
9. 独立于软件供应商:任何架构性的原则都不应依赖特定供应商的产品。将抽象的概念转化为具体的,可运行的系统的过程中,不可避免的要决定使用何种具体的产品,包括商业的或者免费开源的软件。这些决定都不应影响架构层。这就意味着要尽可能的依赖互操作性和可移植性的标准。因此,要应用支持适当标准的技术来构建服务提供者和使用者,不要受限于任何软件供应商的技术路线。
10. 元数据驱动:SOA中所有的元数据对象都需要被按照一种方式储存起来,这种方式将确保元数据对象能够在设计和运行时被发现、检索和解释。元数据对象包括对服务接口、参与者、端点和绑定信息、组织单元和职责、文档类型或模式、使用者或提供者关系等的描述。这些对象的用途应当是被代码自动生成或者解释,成为服务和参与者生命周期的一部分。
以上是我的原则列表。 即使你不完全同意——而坦率地讲,我也不希望你完全同意, 至少不是全部都同意——我希望你能带着它们来引发一些讨论!
发表评论
-
计算机端口详细介绍(整理版)
2012-08-23 09:47 1413我们常常会在各类的网络或者网站方面的技术文章中见到诸如135、 ... -
六分钟八法则塑造优秀程序员
2012-03-31 17:21 1496还记得那个叫做 Justice Gray 的人么?他曾经试图在 ... -
数字签名是什么?
2011-11-29 17:32 57754今天,我读到一篇好文章。 它用图片通俗易 ... -
不要困在自己建造的盒子里
2011-02-25 09:08 10639此文章的主旨是希望过于专注.NET程序员在做好工作、写好. ... -
人民币的符号的正确表示法?一杠?两杠?¥还是¥呢?
2010-09-01 17:17 3100因为做的项目会跟钱打了交道,所以被研究了。 那是一杠还是 ... -
从HTTP GET和POST的区别说起
2010-09-01 17:13 1501面试时得到的回答大多是:POST是安全的,因为被提交的数据 ... -
饭后做这6件事等于慢性自杀。。。
2010-07-05 18:09 2540一般饭后你会做什么呢?是吸烟,吃水果,喝 ... -
99%的人都不知道手机的隐藏功能
2010-06-28 10:31 313141、伪关机 当不喜 ... -
做网站用UTF-8还是GB2312?
2010-06-20 22:25 2082经常我们打开外国网站的时候出现乱码,又或者打开很多非英语的 ... -
得体说话35招
2010-06-20 19:48 1140赞美时,你该说……1.赞美行为而非个人。举例来说,如果对方是厨 ... -
我们真的需要那么多功能吗? - 国外主流开源 CMS 功能评点
2010-06-19 08:55 2700世界上最好用的工具 ... -
OpenID资源大全
2010-06-18 16:23 2240OpenID 是一个在网络上对用户进行验证的分散式框架,O ... -
像设计师一样思考
2010-06-15 20:07 1336原文:http://www.dapenti.c ... -
用户不上你的网站的50个原因
2010-06-13 14:12 1168原因如下: 1 他们不想生产内容,他们期望的是更好的生活 ... -
http状态查询 http 状态代码解释 http状态码查询
2010-06-12 17:29 2002HTTP状态码(HTTP Status Cod ... -
危地马拉惊现“地狱之门”
2010-06-03 13:49 4332我的第一个念头是“这不是真的吧?!”。然后我检查了来源 ... -
【论】Windows操作系统让我们养成了什么臭毛病
2010-05-10 10:03 28001,疯狂刷新 相信很多人跟我以前一样,一进入Wind ... -
Windows操作系统让我们养成了什么臭毛病
2010-05-10 08:45 17231,疯狂刷新 相信很多人跟我以前一样,一进入Windows桌面 ... -
什么是算法 如何寻找稳定的婚姻搭配
2010-05-08 11:42 2610据说,一本书开篇就直言不讳地谈起两性的话题,这本书 ... -
交易员的胖手指导致美股暴跌
2010-05-08 00:10 1587周四,在不到一小时内,华尔街道琼斯指数暴跌了9%(约1000点 ...
相关推荐
### SOA架构十大设计原则详解 #### 明确的边界 在面向服务的架构(SOA)中,明确的边界是构建稳定、可靠且可扩展的服务的基础。这一原则强调了服务之间的交互必须通过清晰界定的边界来进行,边界内部的具体实现对...
阅读提示:日前国外网站报道介绍了面向服务架构(SOA)的基本原则,提出了公共接口与内部实现要有明确界限等原则。虽然这些原则并不是绝对的真理,但可作为一个应用开发参考。
#### 服务设计的十大原则 1. **边界明确**:每个服务应具有清晰的职责范围。 2. **服务自治**:服务内部实现应独立于其他服务。 3. **共享模式而非类**:通过定义数据交换格式而非特定编程语言来确保互操作性。 4. *...
2. **设计技术性架构**:良好的架构设计是关键,应遵循简洁有效的原则,如“奥卡姆剃刀原理”。架构应考虑组织的独特性,但也要追求通用性,避免过度复杂化。基于SOA(面向服务的架构)的理念可以提高系统的灵活性和...
7. **架构模式与原则**:如SOA(面向服务的架构)、微服务、MVC(模型-视图-控制器)、六边形架构等,以及开放封闭原则、单一职责原则、依赖倒置原则等设计原则,是构建可扩展和可维护系统的关键。 8. **论文写作与...
2. **软件设计原则**:了解模块化、抽象、信息隐藏、封装、继承、多态等设计原则,以及它们在系统架构中的应用。 3. **架构模式与风格**:熟悉常见的架构模式,如微服务架构、面向服务架构(SOA)、事件驱动架构...
11. **项目管理**:了解项目管理知识,如PMBOK指南中的五大过程组和十大知识领域,可以帮助设计师参与项目计划、执行和控制。 12. **质量保证与测试**:理解软件质量保证的原则,掌握不同的测试方法(如单元测试、...
5. **项目管理知识**:熟悉PMBOK(项目管理知识体系指南)中的五大过程组(启动、规划、执行、监控和收尾)和十大知识领域。了解敏捷开发方法如Scrum和Kanban,以及持续集成/持续部署(CI/CD)流程。 6. **时间管理**...
3. **软件架构**:高级软件工程强调大规模系统的架构设计,如微服务架构、SOA(面向服务架构)和MVC(模型-视图-控制器)架构。课件会深入讨论这些架构的优缺点和适用场景。 4. **软件质量保证**:这部分内容可能...
这可能涵盖项目的生命周期、项目管理过程组、五大过程组(启动、规划、执行、监控和收尾)、十大知识领域(范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、整合管理和干系人...
1. **项目管理知识体系**:理解PMBOK(项目管理知识体系指南)中的五大过程组(启动、规划、执行、监控、收尾)和十大知识领域(范围、时间、成本、质量、人力资源、沟通、风险、采购、干系人管理、整合管理),并能...
熟悉OWASP(开放式网络应用安全项目)十大安全风险,能帮助我们在架构设计中预先防范安全漏洞。 最后,性能优化是架构狮必须掌握的技能。这包括理解CPU、内存、网络等资源的瓶颈,进行性能监控和调优,如使用JMeter...
9. **架构设计**:学习不同的架构模式(如微服务、SOA、三层架构),以及如何选择合适的架构风格来满足特定的业务需求。 10. **技术选型与评估**:理解如何评估和选择硬件、软件和技术解决方案,考虑因素包括性能、...
- **安全实践**:理解OWASP十大安全漏洞,掌握安全编码和安全设计原则,保护软件免受攻击。 5. **持续学习与个人发展** - **技术趋势**:关注AI、大数据、物联网等新兴技术,持续学习,保持技术敏锐度。 - **软...
此外,还需要理解系统设计的基本原则,如模块化、抽象、信息隐蔽等。 2. **软件工程原理**:涉及软件生命周期模型(如瀑布模型、敏捷开发、迭代模型),软件质量保证和质量管理,以及软件度量和评估方法。考生需要...
2. **架构模式**:如微服务架构、服务导向架构(SOA)、事件驱动架构(EDA)等,每种模式都有其特定的优点和适用场景。例如,微服务架构强调将大型应用拆分为小型、独立的服务,以提高灵活性和可部署性。 3. **分层...