初探 SOA(补充)
(编辑:jimmy 日期: 2024/11/24 浏览:3 次 )
这种业务灵活性可使企业加快发展速度,降低总体拥有成本,改善对及时、准确信息的访问。SOA 有助于实现更多的资产重用、更轻松的管理和更快的开发与部署,在当今的业务环境中,变化是毫无疑问的,因此快速响应客户需求、市场机遇和外部威胁的敏捷性,轻松应对企业商业服务变化、发展的需要比以往任何时候都更显重要。
各种企业都认识到组件化、模块化、互操作和可伸缩基础设施的价值:
组件化:利用标准化的应用程序和资源服务接口
互操作:实现应用程序和/或资源之间的轻松信息交换
模块化:混合搭配、添加删除、业务流程与基础设施
可伸缩:从现有资源起步,随需添加其他资源
SOA的目标在于让IT变得更有弹性,以便更快地响应业务单位的需求使得企业应用摆脱面向技术的解决方案的束缚。SOA可以用蝙蝠来做比喻,蝙蝠要利用自己的超声波捕捉食物,也需要超声波了躲避障碍物,企业也一样,既想利用软件来赢利,也希望软件来规避企业的的风险。
SOA要求开发者从服务集成的角度来设计应用软件,要求开发者超越应用软件来思考,在服务的基础上进行技术构建,并考虑复用现有的服务,或者检查如何让服务被重复利用,让业务需要成为功能组件选择中的驱动因素。它鼓励使用可替代的技术和方法(例如:消息机制),通过把服务联系在一起而非编写新代码来构架应用。SOA想要实现企业资源共享,首先要把应用和资源转换成服务(Service)然后把这些服务变成标准的服务,形成资源的共享。
SOA服务具有平台独立的自我描述XML文档,旨在提高业务流程之间和 IT 应用程序之间的模块化和重用程度,Web服务描述语言(WSDL, Web Services Description Language)是用于描述服务的标准语言。
SOA 服务用消息进行通信,该消息通常使用XML Schema来定义(也叫做XSD, XML Schema Definition)。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部,SOA服务通过一个扮演目录列表角色的登记处来进行维护。应用程序在登记处寻找并调用某项服务。统一描述,定义和集成是服务登记的标准。每项SOA服务都有一个与之相关的服务品质(QoS, quality of service)。QoS的一些关键元素有安全需求(例如认证和授权),可靠通信,以及谁能调用服务的策略。
不同种类的操作系统,应用软件,系统软件和应用基础结构(application infrastructure)相互交织,这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程(business processes),因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应,利用对现有的应用程序和应用基础结构(application infrastructure)的投资来解决新的业务需求,为客户,商业伙伴以及供应商提供新的互动渠道,并呈现一个可以支持有机业务(organic business)的构架。SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新服务或更新现有服务,以解决新的业务需要,提供选择从而可以通过不同的渠道提供服务,并可以把企业现有的或已有的应用作为服务,从而保护了现有的IT基础建设投资。
要运行,管理SOA应用程序,企业需要SOA基础,这是SOA平台的一个部分。SOA基础必须支持所有的相关标准,和需要的运行时容器。
WSDL,UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP,作为传输层,用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制,其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表(registry)查找服务,取得服务的WSDL描述,然后通过SOAP来调用服务。
SOA的概念并非什么新东西,它代表的是一次进化,而不是一次革命,SOA以借助现有的应用来组合产生新服务的敏捷方式,提供给企业更好的灵活性来构建应用程序和业务流程。我认为现有的web服务、工作流、中间件以及现在炒得火热的SAAS都是SOA在不同层度上的实现。但它们也有所区别,Web服务是技术规范,是利用一组标准实现的服务,而SOA是设计原则一种架构模式,用Web服务来实现SOA的好处是你可以实现一个中立平台,来获得服务,而且随着越来越多的软件商支持越来越多的Web服务规范,你会取得更好的通用性。SOA和SAAS我思想相近,而SOA是站在软件架构和设计的角度来看待软件是如何被架构起来的东西,SAAS则是站在应用的角度来看待软件是如何被应用的,软件可以通过SaaS使用SOA的方法提供给用户,也带给SaaS系统松散的耦合,我相信在不久的将来,SOA和SAAS将会很好的结合起来,来指导我们的开发和应用。
各种企业都认识到组件化、模块化、互操作和可伸缩基础设施的价值:
组件化:利用标准化的应用程序和资源服务接口
互操作:实现应用程序和/或资源之间的轻松信息交换
模块化:混合搭配、添加删除、业务流程与基础设施
可伸缩:从现有资源起步,随需添加其他资源
SOA的目标在于让IT变得更有弹性,以便更快地响应业务单位的需求使得企业应用摆脱面向技术的解决方案的束缚。SOA可以用蝙蝠来做比喻,蝙蝠要利用自己的超声波捕捉食物,也需要超声波了躲避障碍物,企业也一样,既想利用软件来赢利,也希望软件来规避企业的的风险。
SOA要求开发者从服务集成的角度来设计应用软件,要求开发者超越应用软件来思考,在服务的基础上进行技术构建,并考虑复用现有的服务,或者检查如何让服务被重复利用,让业务需要成为功能组件选择中的驱动因素。它鼓励使用可替代的技术和方法(例如:消息机制),通过把服务联系在一起而非编写新代码来构架应用。SOA想要实现企业资源共享,首先要把应用和资源转换成服务(Service)然后把这些服务变成标准的服务,形成资源的共享。
SOA服务具有平台独立的自我描述XML文档,旨在提高业务流程之间和 IT 应用程序之间的模块化和重用程度,Web服务描述语言(WSDL, Web Services Description Language)是用于描述服务的标准语言。
SOA 服务用消息进行通信,该消息通常使用XML Schema来定义(也叫做XSD, XML Schema Definition)。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部,SOA服务通过一个扮演目录列表角色的登记处来进行维护。应用程序在登记处寻找并调用某项服务。统一描述,定义和集成是服务登记的标准。每项SOA服务都有一个与之相关的服务品质(QoS, quality of service)。QoS的一些关键元素有安全需求(例如认证和授权),可靠通信,以及谁能调用服务的策略。
不同种类的操作系统,应用软件,系统软件和应用基础结构(application infrastructure)相互交织,这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程(business processes),因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应,利用对现有的应用程序和应用基础结构(application infrastructure)的投资来解决新的业务需求,为客户,商业伙伴以及供应商提供新的互动渠道,并呈现一个可以支持有机业务(organic business)的构架。SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新服务或更新现有服务,以解决新的业务需要,提供选择从而可以通过不同的渠道提供服务,并可以把企业现有的或已有的应用作为服务,从而保护了现有的IT基础建设投资。
要运行,管理SOA应用程序,企业需要SOA基础,这是SOA平台的一个部分。SOA基础必须支持所有的相关标准,和需要的运行时容器。
WSDL,UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP,作为传输层,用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制,其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表(registry)查找服务,取得服务的WSDL描述,然后通过SOAP来调用服务。
SOA的概念并非什么新东西,它代表的是一次进化,而不是一次革命,SOA以借助现有的应用来组合产生新服务的敏捷方式,提供给企业更好的灵活性来构建应用程序和业务流程。我认为现有的web服务、工作流、中间件以及现在炒得火热的SAAS都是SOA在不同层度上的实现。但它们也有所区别,Web服务是技术规范,是利用一组标准实现的服务,而SOA是设计原则一种架构模式,用Web服务来实现SOA的好处是你可以实现一个中立平台,来获得服务,而且随着越来越多的软件商支持越来越多的Web服务规范,你会取得更好的通用性。SOA和SAAS我思想相近,而SOA是站在软件架构和设计的角度来看待软件是如何被架构起来的东西,SAAS则是站在应用的角度来看待软件是如何被应用的,软件可以通过SaaS使用SOA的方法提供给用户,也带给SaaS系统松散的耦合,我相信在不久的将来,SOA和SAAS将会很好的结合起来,来指导我们的开发和应用。
下一篇:初探 SOA