参与开发1-2个基于SOA的项目,但是面试的时候,别人问我SOA是什么,我都回答不出来,惭愧,惭愧啊。。。 :cry:
什么是SOA?
SOA(service-oriented architecture)是面向服务的体系结构,是一类分布式系统的体系结构。
这类系统是将异构平台上应用程序的不同功能部件(称为服务)通过这些服务之间定义良好的接口和规范按松耦合方式整合在一起,即将多个现有的应用软件通过网络将其整合成一个新系统。
SOA是一个组件模型
它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来;
接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和 编程语言;
构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
在SOA架构风格中,服务是最核心的抽象手段,业务被划分(组件化)为一系列粗粒度的业务服务和业务流程。
业务服务相对独立、自包含、可重用,由一个或者多个分布的系统所实现,而业务流程由服务组装而来。
一个"服务"定义了一个与业务功能或业务数据相关的接口,以及约束这个接口的契约。
接口和契约采用中立、基于标准的方式进行定义,它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。
除了这种不依赖于特定技术的中立特性,通过服务注册库(Service Registry)加上企业服务总线(Enterprise Service Bus)来支持动态查询、定位、路由和中介(Mediation)的能力,使得服务之间的交互是动态的,位置是透明的。技术和位置的透明性,使得服务的请求者和提供者之间高度解耦。
这种松耦合系统的好处有两点:一点是它适应变化的灵活性;另一点是当某个服务的内部结构和实现逐渐发生改变时,不影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当发生变化时,某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改,这样的系统架构就很脆弱了。
面向服务的建模与架构
IBM的SOMA将面向服务的分析和设计分为服务发现、服务规约和服务实现。服务的实现包括服务、组件和服务组装的实现。
服务发现
服务发现是SOMA进行服务分析和设计的第一步。服务发现的主要任务,是确定在一定范围内(通常是企业范围,或若干关键业务流程范围内)可能成为服务的候选者列表。
服务规约
经过服务发现阶段,服务目录基本形成,但是对于每个服务本身的属性信息依然零散。为了能够将服务作为业务和IT层面互动的契约,服务规约阶段是必不可少的。服务规约阶段的主要任务是规范性地描述服务各个方面的属性,其中既包括输入/输出消息等功能性属性,服务安全约束和响应时间等服务质量约束,以及服务在业务层面的诸多属性,如涉及的业务规则、业务事件、时间/人员消耗等。与此同时,规范描述服务相关方面的关系也很重要,如服务间依赖关系,服务和业务组件间关系,服务和IT组件间关系和服务消息间关系等。
服务实现
经过服务规约阶段,作为业务和IT互动的服务契约已经形成。但是服务契约和IT的现状还是有很大差距的,如和某个服务对应的业务逻辑分散于不同的应用中,分散在不同的地域,某些服务目前主要依靠人工完成,还没有IT层面的实现。
为了将服务契约落在实地,服务实现阶段通过差距分析,并结合传统方法学完成每个服务实现决策。这其中包括的内容甚多,其主要内容如下。
(1)现有系统分析:调研现有系统架构,了解架构风格、主要架构元素和能力和架构元素的基本特征;调研现有应用,了解应用主要功能和对外接口,技术实现特征等;如果应用构建已经遵循基于组件开发规范,编制应用已有组件目录;如果应用并没有组件化,将应用覆盖的业务功能和服务规约确定的企业组件进行映射,确定应用现有"组件"目录。
(2)确定服务分配:通过服务组件和现有系统分析确定的IT组件间差距分析,确定服务组件和IT组件间映射关系。例如,一个服务组件对应一个或多个IT组件,没有IT组件和服务组件对应,没有服务组件和IT组件对应,服务组件和IT组件对应时有能力缺失或不匹配等。经过差距分析,一些服务中介被确定下来去实现服务路由,或消息格式等不匹配现象,一些新的IT组件被确定下来,如实现某业务流程的组件或实现人工服务的组件等。最终,服务组件都被映射到IT组件上,从而完成服务分配。
(3)服务实现决策:服务分配仅仅确定了需要哪些组件来实现服务,但是并没有实现的策略和技术层面的决策。服务实现决策首先帮助确定服务实现策略,是在现有基础上进行服务包装,还是重新构建,如果重新构建,是采用已经包装好的应用,还是外包,或者自己构建;如果是服务包装的话,有哪些候选方案等。通常服务实现决策和传统的架构决策是关联在一起的。
(4)服务基础设施设计:服务的功能实现,非功能需求的满足都需要服务基础设施的支持。在进行服务实现决策后,需要根据具体的需求确定服务基础设施的能力,如用于支撑人工服务的人工服务容器,用于支撑服务编排的流程引擎等。
将服务实现阶段的各种产物和传统设计方法结合起来,就可以开始指导实际服务实现的实施。
以上内容,参考于 IBM developerworks
http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index2.html
http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index1.html
什么是SOA?
SOA(service-oriented architecture)是面向服务的体系结构,是一类分布式系统的体系结构。
这类系统是将异构平台上应用程序的不同功能部件(称为服务)通过这些服务之间定义良好的接口和规范按松耦合方式整合在一起,即将多个现有的应用软件通过网络将其整合成一个新系统。
SOA是一个组件模型
它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来;
接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和 编程语言;
构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
在SOA架构风格中,服务是最核心的抽象手段,业务被划分(组件化)为一系列粗粒度的业务服务和业务流程。
业务服务相对独立、自包含、可重用,由一个或者多个分布的系统所实现,而业务流程由服务组装而来。
一个"服务"定义了一个与业务功能或业务数据相关的接口,以及约束这个接口的契约。
接口和契约采用中立、基于标准的方式进行定义,它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。
除了这种不依赖于特定技术的中立特性,通过服务注册库(Service Registry)加上企业服务总线(Enterprise Service Bus)来支持动态查询、定位、路由和中介(Mediation)的能力,使得服务之间的交互是动态的,位置是透明的。技术和位置的透明性,使得服务的请求者和提供者之间高度解耦。
这种松耦合系统的好处有两点:一点是它适应变化的灵活性;另一点是当某个服务的内部结构和实现逐渐发生改变时,不影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当发生变化时,某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改,这样的系统架构就很脆弱了。
面向服务的建模与架构
IBM的SOMA将面向服务的分析和设计分为服务发现、服务规约和服务实现。服务的实现包括服务、组件和服务组装的实现。
服务发现
服务发现是SOMA进行服务分析和设计的第一步。服务发现的主要任务,是确定在一定范围内(通常是企业范围,或若干关键业务流程范围内)可能成为服务的候选者列表。
服务规约
经过服务发现阶段,服务目录基本形成,但是对于每个服务本身的属性信息依然零散。为了能够将服务作为业务和IT层面互动的契约,服务规约阶段是必不可少的。服务规约阶段的主要任务是规范性地描述服务各个方面的属性,其中既包括输入/输出消息等功能性属性,服务安全约束和响应时间等服务质量约束,以及服务在业务层面的诸多属性,如涉及的业务规则、业务事件、时间/人员消耗等。与此同时,规范描述服务相关方面的关系也很重要,如服务间依赖关系,服务和业务组件间关系,服务和IT组件间关系和服务消息间关系等。
服务实现
经过服务规约阶段,作为业务和IT互动的服务契约已经形成。但是服务契约和IT的现状还是有很大差距的,如和某个服务对应的业务逻辑分散于不同的应用中,分散在不同的地域,某些服务目前主要依靠人工完成,还没有IT层面的实现。
为了将服务契约落在实地,服务实现阶段通过差距分析,并结合传统方法学完成每个服务实现决策。这其中包括的内容甚多,其主要内容如下。
(1)现有系统分析:调研现有系统架构,了解架构风格、主要架构元素和能力和架构元素的基本特征;调研现有应用,了解应用主要功能和对外接口,技术实现特征等;如果应用构建已经遵循基于组件开发规范,编制应用已有组件目录;如果应用并没有组件化,将应用覆盖的业务功能和服务规约确定的企业组件进行映射,确定应用现有"组件"目录。
(2)确定服务分配:通过服务组件和现有系统分析确定的IT组件间差距分析,确定服务组件和IT组件间映射关系。例如,一个服务组件对应一个或多个IT组件,没有IT组件和服务组件对应,没有服务组件和IT组件对应,服务组件和IT组件对应时有能力缺失或不匹配等。经过差距分析,一些服务中介被确定下来去实现服务路由,或消息格式等不匹配现象,一些新的IT组件被确定下来,如实现某业务流程的组件或实现人工服务的组件等。最终,服务组件都被映射到IT组件上,从而完成服务分配。
(3)服务实现决策:服务分配仅仅确定了需要哪些组件来实现服务,但是并没有实现的策略和技术层面的决策。服务实现决策首先帮助确定服务实现策略,是在现有基础上进行服务包装,还是重新构建,如果重新构建,是采用已经包装好的应用,还是外包,或者自己构建;如果是服务包装的话,有哪些候选方案等。通常服务实现决策和传统的架构决策是关联在一起的。
(4)服务基础设施设计:服务的功能实现,非功能需求的满足都需要服务基础设施的支持。在进行服务实现决策后,需要根据具体的需求确定服务基础设施的能力,如用于支撑人工服务的人工服务容器,用于支撑服务编排的流程引擎等。
将服务实现阶段的各种产物和传统设计方法结合起来,就可以开始指导实际服务实现的实施。
以上内容,参考于 IBM developerworks
http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index2.html
http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index1.html