欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜:Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
SOA
第26行: | 第26行: | ||
==厂商方案== | ==厂商方案== | ||
*[[BEA AquaLogic]] | *[[BEA AquaLogic]] | ||
− | *[[SUN SOA]] - [[Java CAPS]] - http://www.sun.com/products/soa/ | + | *[[SUN SOA]] - [[Java CAPS]] (Integration software suite) - http://www.sun.com/products/soa/ |
*[[Oracle SOA Suite]] | *[[Oracle SOA Suite]] | ||
2006年8月5日 (六) 16:37的版本
SOA: Service-Oriented Architecture
面向服务的体系结构(service-oriented architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
目录 |
SOA的原则
SOA是一种企业架构,因此,它是从企业的需求开始的。但是,SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说,创建一个业务敏捷的架构意味着创建这样一个IT架构,它可以满足当前还未知的业务需求。
要满足这种业务敏捷性,SOA的实践必须遵循以下原则:
- 业务驱动服务,服务驱动技术
从本质上说,在抽象层次上,服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系,另一方面,同样要理解服务与提供这些服务的底层技术之间的关系。
- 业务敏捷是基本的业务需求
SOA考虑的是下一个抽象层次:提供响应变化需求的能力是新的“元需求”,而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求,因为,在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。
- 一个成功的SOA总在变化之中
SOA工作的场景,更象是一个活的生物体,而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化,因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说,要转向设计一个活的生物体要求崭新的思维方式。如下文所写的,SOA的基础还是一些类似的架构准则。
开源项目
- ServiceMix Open Source ESB - http://servicemix.org/
- Celtix Open Source Java ESB - http://celtix.objectweb.org/
- Mule Enterprise Service Bus (ESB) messaging framework - http://mule.codehaus.org/
- Open ESB - https://open-esb.dev.java.net/
厂商方案
- BEA AquaLogic
- SUN SOA - Java CAPS (Integration software suite) - http://www.sun.com/products/soa/
- Oracle SOA Suite
相关链接
- Oracle SOA - http://www.oracle.com/lang/cn/technologies/soa/