架构服务（共12篇）
架构服务 篇1
摘要：在基于分布式应用的互联网技术高速发展的今天,为解决异构平台互联、不同协议系统之间的通信、遗留系统和新增系统接口等等传统技术较难解决的问题,一种被称为“面向服务的体系架构SOA”的软件工程方法应运而生。SOA由于具有基于标准、松散耦合、共享服务、粗粒度和联合控制等优势,比以前的面向过程、面向对象、面向构件的方法能够更好地解决前述问题而日益受到软件理论界和业界的青睐。该文从概念介绍开始,逐步深入探讨SOA作为一种新型软件架构的基本特征和优点,详细介绍了SOA参考架构中的三个角色和三种操作,以及组成SOA的四个关键元素;然后把SOA与传统的软件架构进行比较,说明了SOA的必然性。
关键词：面向服务的软件体系结构(SOA),Web Service,面向服务的分析与设计
1 SOA的定义
从总体上来讲,面向服务体系结构SOA(Service Oriented Architecture)是一种结构模型,它可以根据需求并通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。现在关于SOA尚未有一个统一的的定义,甚至有些还相互冲突。目前大多数人将SOA定义如下:“面向服务的体系结构是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来,接口是采用中立的方式进行定义的,独立于实现服务的硬件平台、操作系统和编程语言,使得构建在各种这样的系统中的服务可以用一种统一和通用的方式进行交互。”
2 SOA与传统架构的比较
由于SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范,这就决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用。
SOA被认为是传统紧耦合的、面向对象模型的替代者。像通用对象代理架构CORBA和分布式组件对象模型DCOM。与传统架构相比,SOA具有更多优势:基于标准、松散耦合、共享服务、粗粒度和联合控制。SOA与大多数通用的客户端/服务器模型的不同之处在于它着重强调软件组件的松散耦合,并使用独立的标准接口。
SOA不是一种全新的技术,而是对更传统的、紧密的面向对象模型的另一种选择。而且SOA并没有排斥面向对象,系统的总体设计是面向服务的,但是具体到某个服务的实现可以是基于面向对象设计的。SOA是允许对象在系统内存在的,所以SOA其实也是基于对象的,但是SOA作为一个整体就不是面向对象的,可以说SOA是更高层意义上的架构。SOA和面向对象的区别在与接口上,面向对象的接口是给其他对象使用的。而SOA的接口是可以给从组件到系统来使用的,SOA的接口一般使用web服务、EJB、CORBA等分布的技术来实现。
3 SOA的元素
3.1 SOA参考架构模型
SOA的模型描述了三个角色(服务提供者、服务注册库和服务请求者),执行三种操作(发布、查找、绑定),具有简单、动态和开放的特性。图l简明地表述了SOA模型。
SOA模型中的角色包括:
1)服务提供者(Service Provider):从企业的角度看,是服务的所有者。从体系结构的角度看,是被访问服务的运行平台。服务提供者是一个可通过网络寻址的实体,它接受和执行来自服务请求者的请求,它将自己的服务和接口契约发布到服务注册中心,以便服务请求者可以发现和访问该服务。
2)服务注册中心(Service Registry):服务注册中心是服务发现的支持者,它包含一个可用服务的存储库,是可搜索的服务描述的注册中心。服务提供者在此发布他们的服务描述,同时服务请求者也可以从服务注册库以外的其它来源得到服务描述,例如本地文件、盯P站点、Web站点等。静态绑定中,服务注册库是可选的,因为服务提供者可以把描述直接发送给服务请求者;在动态绑定中,服务请求者通过查找(Find)动作实现对服务的查询并获得在服务描述中的绑宁信息。
3)服务请求者(Service Request。r):从企业的角度看,是要求使用某些特定功能的企业。从体系结构的角度看,是寻找并调用服务的应用程序,或是启动与服务交互的应用程序。服务请求者是一个应用程序、一个软件模块或需要一个服务的另一个服务,它发起对服务注册库中的服务的查询,通过传输绑定服务,并且执行服务功能。
SOA中的每个实体都扮演着服务提供者、服务请求者和服务注册库这三种角色中的某一种(或多种),在这些角色之间使用三种操作:
发布(Publish):为了使服务可访问,服务提供者需要发布服务描述以使服务请求者可以发现和调用。
查找(Find):服务请求者定位服务,方法是查询服务注册中心来找到满足其标准的服务。
绑定(Bind):在检索完服务描述之后,服务请求者根据服务描述中的信息来调用服务。
3.2 SOA的组成元素
基于SOA的参考模型,我们抽象出SOA的4个组成元素:应用程序前端、服务、服务库和服务总线,如图2所示。
“应用程序前端”是业务流程的所有者。“服务”提供业务功能,可供应用程序前端和其他服务使用。服务的“实现”提供业务逻辑和数据。服务的“合约”为服务客户指定功能、使用和约束。服务的“接口”物理地公开功能。“服务库”存储SOA中各个服务的服务合约。“服务总线”将应用程序前端和服务连在一起。
4 SOA与Web Service
为了能够实现SOA,业界给出了一套SOA的标准。用服务作为建模单元并非最近才有的,正如前文所说DCOM和CORBA等都是在早期萌发SOA雏形的初步设想阶段的产物,但是他们的努力并没有使SOA发扬光大。而随着技术的发展,更主要是随着Web Services的出现,大大刺激了SOA的发展。它给出了一个目前最好的实现SOA的方式。Web Services本身的特性决定了它能够满足SOA提出的要求,比如Web Services本身也是基于Internet的、基于标准的消息描述语言或网络传输协议等。但是我们有理由相信Web Services这种技术终将被另一种更先进的技术所取代。
4.1 Web Service与SOA的关系
SOA与Web Services是两个不同层面的问题,前者是概念模式,面向商业应用;后者则是实现模式,面向技术框架。SOA概念并没有确切地定义服务具体如何交互,而仅仅定义了服务如何相互理解。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面,Web服务在需要交互的服务之间如何传递消息有具体的指导原则。从战术上实现SOA模型是通过HTTP传递的SOAP消息的Web服务模型。
Web Services建立在开放标准和独立于平台的协议的基础之上。Web Services通过HTTP使用s OAP(一种基于XML的协议),以便在服务提供者和消费者之间进行通信。服务通过WSDL(服务描述语言)定义的接口来公开。UDDI是一种语言无关的协议,用于和注册中心进行交互以及查找服务。但是值得注意的是Web Servi。es仅仅是实现S以的一种技术,与SOA是血与肉的关系。只是因为Web Service S的发展,在很多层面满足SOA的实现需要,所以使得web Services成为目前开发SOA应用程序的优秀选择。
从本质上讲,Web Servces是实现SOA的具体方式之一。基于Web Services的SOA具有以下优势:
1)它是基于标准的,这意味着机构不再需要对专有解决方案进行投入,以免受制于个别厂商。
2)它支持解决方案间的互操作,令你可以使用不同厂商的、具有单项优势的产品,以显著降低成本。
3)它支持机构内的集成,而且可被扩展为支持跨机构和机构间的集成。
4.2 基于Web Serv1ces的SOA集成模型一WSOA
随着Web Services技术的成熟,尤其是所依托的XML,SOAP,wSDL,UDDI均已成为开放行业标准,使得基于Web Services的SOA实现,成为了公认的实施SOA架构最好的方式,是很多企业采用的一种应用集成方法。本文将SOA与Wob Services结合起来,提出了个基于Web Services的SOA集成体系架构模型一WSOA,如图3。
WSOA架构模型仍然是基于SOA架构的三类主体(角色)的,即离散Web服务资源的服务提供者、UDDI注册库、通用客户端的服务请求者。根据WSOA模型,我们在对企业进行SOA的实施时,首先对现有应用系统进行分析和服务界定,把原有系统的一些需要对外暴露的功能进行Web服务封装,部署到应用服务器。这样,现有应用系统既能被其它应用程序通过Web服务进行调用,又能保证原有应用的运行不会受到影响;然后服务提供者对应用服务器上的Web服务进行WSDL描述,通过SOAP协议将其在UDDI注册库中进行注册和发布,如果这些Web服务之间存在着一定的关系,则UDDI注册库管理系统对注册服务之间进行关联和动态组合,以便服务请求者调用服务;通用客户端就是服务的请求者,通用客户端通过到UDDI注册库查找并发现服务,再通过SOAP消息动态、按需地获取服务的WSDL文档的地址,然后解析WSDL文档,调用Web服务,进行服务集成。
在图3所示的模型中,我们把服务划分为遗留系统所封装的服务,和新开发的单独的服务,或者是由其他厂商提供的服务。客户端可以是任何一个需要进行SOA实施的应用。如果是对遗留系统的改造,则可以与左边的遗留系统提供的服务进行交互,如果是己用SOA架构开发松耦合系统,只是需要扩展现有功能,则可以采用和右边的新增服务及其他服务进行交互的方法。当然客户端也可以是一个待构建的全新SOA系统,那么它就可以完全通过在UDDI注册库中查找所需服务来构建一个新系统。UDDI注册库是一个可用服务的存储库,存储了所有可用服务的信息,以供请求者查找。
5 总结
SOA作为一个新兴的软件体系架构,越来越受到人们的重视,其技术也处于不断的发展与更新之中。全面应用Web Servies及ESB/SOA的开发方法仍然有不足的地方。对于旧的系统,需要进行改造才能支持SOA,这个修改不是一件简单的事情。除了需要资金,用户还需要时间、勇气、理念,以及抗风险的充分准备。另外开发人员己经习惯旧的设计和开发模式,采用截然不同的新模式和工具,需要重新培训。不过最大的问题还是开发调试的问题,基于SOA的系统一般需要集成很多的系统或者模块,还会使用很多包装好的控件、服务,这些都是经过很多层包装的组件,开发人员很难深入了解这些组件,当他们抛出错误的时候(例如底层跑出NullPointer Exeeption),由于信息不够明确或者stacktrace太长,将会很难找到问题的所在。但是,SOA是未来发展的必然趋势。随着IBM,微软,oracle,Bea等多个大公司在SOA方面加大力度,更多的优秀产品投入市场,我相信在未来几年SOA将迅速成为企业级Web应用的主流技术架构。未来的Web应用系统的开发就会好像桌面应用系统开发那样简单。
参考文献
[1]IBM.What is Service-Oriented Architecture(SOA)[EB/OL].http://www-128.ibm.com/developerworks/webservices/newto/#1
[2]Principles of SOA Design[EB/OL].www.webservices.org.
[3]O’neil M.Web服务安全技术与原理[M].冉晓旻,郭文伟,译.北京:清华大学出版社,2003.
[4]卢致杰,覃正,韩景调.王立华SOA体系设计方法研究[J].工业工程,2004(6).
架构服务 篇2
1.1 模式描述
不管你选择哪种实现,有几个常见的核心概念都需要进行了解。第一个概念是独立部署单元。如图4-1所示，微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。
也许要理解这种模式，最重要的概念就是服务组件。不要考虑微服务架构内部的服务，最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应用程序。服务组件包含一个或多个模块（如Java类），这些模块可以提供一个单一功能，例如为特定的城市或城镇提供天气情况，或也可以作为一个大型商业应用的一个独立部分，例如火车票的余票查询系统。在微服务架构中，正确设计服务组件的粒度也是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。
微服务架构模式的另一个关键概念是它可能是一个分布式的架构，这意味着架构内部的所有组件之间是完全解耦的，并通过某种远程访问协议（例如， JMS, AMQP, REST, SOAP, RMI等）进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。
微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。
提示 : 单体应用, 即一个应用就是一个整体。
从单体应用到微服务的发展过程主要是由持续交付开发促成的。单体应用通常是由紧耦合的组件组成，这些组件同时又是另一个单一可部署单元的一部分，这使得它繁琐，难以改变、测试和部署应用。这些因素通常会导致应用变得脆弱，以至于每次有一点新功能部署后，如果由于这些新功能引发了异常，那么整个应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元（服务组件）的方法来解决这一问题，这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。
另一个导致微服务架构模式产生的演化过程是由面向服务架构模式（SOA）应用程序存在的问题引起的。虽然SOA模式非常强大，提供了无与伦比的抽象级别、异构连接、服务调度，并保证通过IT能力调整业务目标，但它仍然是复杂的、昂贵的,它很难理解和实现，对大多数应用程序来说它过于重量级。微服务架构通过简化服务概念，消除调度需求、简化服务组件连接和访问来解决复杂度问题。
1.2 模式拓扑
虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出，最常见和流行的有:基于REST API的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。
基于REST的API拓扑基于REST的API拓扑适用于网站，通过某些API对外提供小型的、自包含的服务。这种拓扑结构,如图4 - 2所示,由粒度非常细的服务组件（因此得名微服务）组成，这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。这种拓扑的例子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。
图 4-2
基于REST的应用拓扑结构基于REST的应用拓扑结构与基于REST API有所不同，它通过传统的基于web的应用或者客户端应用来接收客户端请求，而不是通过一个简单的API层。如图4-3所示，应用的UI层是一个web应用，可以通过简单的基于REST的接口访问单独部署的服务组件。该拓扑结构中的服务组件与基于REST API拓扑结构中的不同，这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分，而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。
图 4-3
集中式消息拓扑微服务架构模式中另一个常见的方法是集中式消息拓扑，如图4-4所示。该拓扑与前面提到的基于REST的应用拓扑类似，不同的是基于REST的应用拓扑结构使用REST进行远程访问，而该拓扑结构则使用一个轻量级的集中式消息中间件（如，ActiveMQ, HornetQ等等）。不要将该拓扑与面向服务的架构模式混淆或将其当做SOA简化版，这点是极其重要的。该拓扑中的轻量级消息中间件（Lightweight Message Broker）不执行任何调度,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。
集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟（将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理）解决。
图 4-4
1.3 避免依赖和调度
微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合）。然而,服务组件粒度过细将导致额外的服务调度,这可能会导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的、重量级的面向服务架构。
如果你发现需要从应用内部的用户接口或API层调度服务组件，那么很有可能你服务组件的粒度太细了。同样的，如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。
服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。
共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份，因此违反了DRY规则。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。
提示 : DRY，即don’t repeat yourself.
如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件调度,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。
1.4 注意事项
微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的、单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。
该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。
最后一个要重视的考虑是，由于微服务架构模式可能是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理、远程系统的可用性、远程访问身份验证和授权等。
1.5 模式分析
下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于其自身特点，基于典型模式实现的能力特性,以及该模式是以什么闻名的。
特性评级分析整体灵活性高整体的灵活性是能够快速响应不断变化的环境。由于服务是独立部署单元,因此变化通常被隔离成单独的服务组件,使得部署变得快捷、简单，架构服务 篇3
医疗保险一直是我国社会保险的重要组成部分，医疗保险信息管理系统也是社会保险信息管理系统的重要组成部分。
由于各地的医保待遇政策的差异，各地医保系统的核心算法各不相同，必须通过在各地的服务之间交换数据才能准确地完成异地就医待遇计算。可是各个独立的系统采用的技术不同，采用的接口方式也不相同，所以无法简单地采用网络把这些独立的系统连接起来。为了实现这些独立的系统之间的通信，可以重新制作一个可以适应各地医保待遇算法的统一的程序框架，把各地的医保待遇算法“填充”进去；也可以封装现有的系统，通过统一的接口和互操作协议使原有系统可以互相理解。面对服务的架构才能够适应这种需求。
2 设计
2.1 面向服务架构
总的来说面向服务开发具有以下特点：
（1）重用：创建能够被各种应用重用的服务，提高服务的适应性。
（2）效率：较少改变原有系统，集中精力于数据共享，组合现有服务以达到快速创建新的服务与应用的目的。
（3）低复杂度：较少关心底层实现、执行环境，通过对服务建模和建立接口契约来连接系统。
（4）高操作性：将业务问题和技术问题尽量分离，使业务人员和技术人员通过服务契约进行高效协同。
开发服务与开发对象不同：因为一个服务，是由它与其他服务交换的信息而不是由一个方法的结构来定义的；服务定义所在的抽象层次必须比对象定义所在的抽象层次要高，因为这样可以把一个服务的定义映射到某种面向过程的语言、消息排队系统或面向对象系统上。理解服务定义的粒度也同样重要。一般来说，服务都会定义粗粒度的接口。相对于对象的调用来说，对服务的单次调用会接收更多的数据，消耗更多的计算资源，因为它需要进行执行环境的映射和xml处理等工作，而且对服务的访问通常都是远程的。当然，对象接口也可以是粗粒度的。关键在于，服务是用来解决应用的互操作问题以及用于组合新应用或者应用系统，而不是为应用创建具体业务逻辑。通过进行Web服务的聚合，可以发布封装了多个其他服务的Web服务。这样，可以将一个粗粒度的接口分解为多个细粒度的服务，或者，用多个细粒度的服务组合为一个粗粒度的接口。粗粒度的服务更适合用于发布，而细粒度的服务则更适合作为仅供前者使用的“私有”服务。
结合目前的医保系统，医保中心对医院端提供了许多功能，如门诊和住院登记、交易结算、药品目录下载、对账报表生成等。这些交易中有的在中心端和客户端之间的数据交换量很大，不适合作为实时系统的一部分进行封装。考虑到异地医保业务中，只有属地的医保中心待遇核心算法对异地的医保系统有意义，所以我们只要封装属地的医保中心待遇核心算法部分，作为我们新系统的服务。向异地提供一些如待遇审批、待遇结算等医保待遇核心功能即可，其它不涉及到账户消费的功能就不需要加入实时系统部分。
在努力减小业务中交换的数据量的同时，也要减少每次业务在属地和异地医保系统之间的往来次数。
2.2 结算中心
将各地的系统进行封装之后，还需要建立一个结算中心。其目的有二：
(1)由于医保业务的特殊性，每个业务请求都必须要被处理，所以系统不能采用自动发现服务的方式，需要有一个模块来登记和维护这些已知服务的信息，进行数据的调度。
(2)各地的医保的结算系统是独立结算的，异地之间的业务的结算信息要被记录，然后通过银行系统对这些结算记录进行冲减，这为保证数据一致提供了依据。
为了实现以上这两个目的，结算中心需要至少具备以下几个功能：服务登记、数据转发、保证事务完整性、保存交易记录。通过在已知的服务地址列表中检索某个描述，找到对应的地址作为请求的目的地址。如要进行异地医保垫付给用结算，可根据保存的请求数据记录，通过调用银行提供的接口来完成。
2.3 层次结构
实时系统可以在医院客户端和医保中心端之间加入一个中间层，通过这个中间层来完成对原有医保系统的封装，同时也利用这个中间层来完成对异地医保系统请求的转发。如果发现一个请求的属地信息不是本地，则直接请求转给结算中心。同时还要完成本地医保中心的数据和异地之间传输的xml之间的数据格式转换。
3 实现
3.1 各地医保系统改造
异地就医业务发生时由异地医疗保险系统要多传入一个异地的区域编号，这个编号可以是全国统一编制的，也可以是局部的结算中心可以识别的，然后调用上一级结算中心进行交易。属地医保中心要提供接口给结算中心调用。每一个医保中心都具备异地和属地的双重角色。具体改动如下表：
表1 原系统改动列表
3.2 结算中心功能
结算中心是一个独立的新增模块，要在省级或部级进行开发。结算中心负责连接各地的医保中心，接收并转发各地的异地医保请求，将这些请求保存起来而不保存返回的处理结果。同时还要和银行接口连接，根据保存的请求数据，完成异地医保垫付。
3.3 结算中心接口
结算中心对外接口由Tuxedo编制的服务程序提供。主要完成两个任务：向结算中心数据库内保存请求数据、解析请求串并转发到指定的医保中心服务器。对于数据库操作由Tuxedo自动完成事务控制。使用Tuxedo主要原因是Tuxedo支持C语言编制的服务，执行效率较高；而且Tuxedo的并发性能很好，可以满足大量数据交换的需要。
结算中心提供给各医保系统的是一个jar，无用户界面，要求输入输出必须遵守接口规范。程序文件名：ddb_interface.jar。此接口完成远程服务接口调用，用于医保中心java程序调用jar的相应接口，完成调用Tuxedo服务：将此jar在医保中心WebLogic服务器部署为EJB，完成医保中心处理Tuxedo调用。
在这个jar中一共有5个消息类和2个功能类。5个消息类分别为MessageRequest：与Tuxedo交互过程中使用到的交互消息请求对象；MessageResponse：与Tuxedo交互过程中使用到的交互消息回应对象；MessageBody：交互消息休；MessageRequestHeader：交互消息请求头信息；MessageRequestHeader：交互消息回应头信息。2个功能类为RemoteTusedoServiceClient：远程Tuxedo服务客户端接口，负责调用Tuxedo服务；DDBException：接口异常类。由于目前只是一个原型系统，所以没有异常类的具体实现。
3.4 数据封装
对数据的封装采用xml的格式，在信息头中包括了：数据来源地、数据目的地、请求类型、交易编号、交易响应码、错误措述等几个部分。信息体中又分为参数和数据项，数据项中有多个数据元素。设置数据项是因为WebLogic和Tuxedo进行数据格式转换时，不支持xml的元素属性，所以要把元素属性转化成元素。根据需要，这些xml的内容可以加密后传输，来提高安全性。
针对具体业务，以住院异地结算为例，请求方必须发送包括请求业务类型、住院流水号、个人编号、医疗费总额、符合基本医疗费用总额、自费金额、自付金额、结算日期等项，应答方必须发送包括应答业务类型、执行成功标识、统筹支付金额、个人账户支付、个人现金支付等项。这些数据项都是选取出的待遇计算所必须的重要数据项。
4 测试
4.1 测试环境
测试模拟同一省内两城市医保中心，通过省级办理异地业务，其中属地医保中心为两台Sun V20z，每台机器上安装WebLogic，建立一个Server，2个Server形成Cluster。异地医保中心的系统搭建方式与属地医保中心相同。省级交换中心为两台SumV20z搭建的Tuxedo Cluster。属地医保中心、异地医保中心和省级交换中心分别建立用户，共用一个数据库，数据库服务器机型为Hp4640。
4.2 测试软件
监控工具：
操作系统vmstat /mpstat/iostat/netstat/prstat、中间件WebLogic8.1.4Console、数据库Oracle9.2OEM、statspack。
负载生成工具：
模拟负载场景Loadrunner v8.0。
4.3 测试数据及分析
在测试这个场景时，通过处方数量一定（300条处方），逐步增加并发人数；并发人数达到100个用户时，逐步增加处方量进行分别测试。跟踪后台的出错信息，根据这些错误信息分析、定位原因。通过调整中间件配置、应用等，最终达到并发100个用户、每人处方量达到500条的要求。详细数据见表2。
通过观察表2中列出的数据看到，所有的交易请求都能得到响应，说明系统有效。随着并发用户数的增加，交易请求的最小响应时间变化不明显，最大响应时间逐渐增加，说明这个实验环境中，系统的并发处理能力有限，交易请求要在队列中等待，但最后还是可以成功被处理的。每种业务的最小响应时间和最大响应时间都有一定差距，随着并发用户数的增加这种差距明显增加，这种增加也不是线性的，主要由于测试服务器只有一台，没有进行负载均衡，在后台处理时采用随机抢先机制造成的。
5结语
面向服务的架构概念和J2EE、web service、xml、中间件的结合使其更实用有效，通过面向服务的架构来重组现有的医疗保险系统，对原系统改动小，而且技术复杂度低，可以降低开发和维护成本。利用结算中心进行调度，利用交易中间件来进行消息的转发，保证了系统的可靠和效率。实验证明方案切实可行，但在性能优化方面仍有提升空间。
参考文献
[1]Thomas Erl.
东软:开放架构促进位置服务发展 篇4
刘磊介绍说, 开放的位置服务架构是:资源层吸引开发者、创业者和应用使用者的参与和贡献;控制层开放平台接口, 提供测试环境, 降低应用接入门槛;应用层面向位置服务和位置应用提供统一接入、统一鉴权, 支持复杂计费;接入层通过业务和业务管理相分离, 满足SP/SI多种运营模式需求。
刘磊认为, 基于开放的位置服务架构, 中国移动GIS正从WebGIS向ServiceGIS转变, 主要体现在三个方面:第一, 提供支持大规模的共享服务能力, 不仅包括地图, 还包括基础数据和计算能力的共享;第二, 提升支持多样化的客户端软件的能力, 不仅包括各种Web浏览器, 也包括桌面软件、移动设备和专业应用终端;第三, 提升支持更多的网络服务协议和高级功能的能力, 不仅包括WebMapping的协议, 也包括多种其他协议, 以及厂商制定的REST和SOAP协议。
垂直行业网站服务器架构方案 篇5
一、目前架构：
114.113.229.66massterHadoop114.113.229.72V1web114.113.229.73V2webmysql主JobsHbase114.113.229.67slaveHadoopHadoop-data114.113.229.68tomcatV1 搜索tomcatSolrSolr Home索引搜索服务编辑后台114.113.229.69slaveHadoopHadoop-data114.113.229.70slaveHadoopHadoop-dataMongoDBHbase114.113.229.71slaveHadoopHadoop-dataMongoDBHbase114.113.229.74slaveHadoopHadoop-dataMongoDBHbasemysql从 爬虫使用6台，其中3台同时放了MongoDB服务，1台同时放了搜索服务和编辑后台服务，直接导致服务器不能专职使用互相影响，大部分服务器CPU一直在高负荷运作，67为我们的搜索服务器，其中编辑后台和爬虫服务会影响到搜索服务的运行，一旦cpu负荷到100%，那么搜索指令将不会被执行，直接表现为搜索任何关键词或分类都无结果。
缺点：服务器不能发挥出应用的性能。
二、基本架构：需要9台服务器
114.113.229.66massterHadoopJobsHbase114.113.229.71V2webmysqlMail114.113.229.67slaveHadoopHadoop-datatomcat编辑后台114.113.229.69slaveHadoopHadoop-dataCPS/API114.113.229.72slaveHadoopHadoop-dataHbase114.113.229.73slaveHadoopHadoop-dataHbase114.113.229.74slaveHadoopHadoop-dataHbase114.113.229.68SolrSolr Home索引搜索服务114.113.229.70MongoDB
一台WEB主机；支持500人同时在线，每天约百万PV。 一台搜索SOLR主机；支持 400W 以下数据量。
爬虫HADOOP共6台；能做到全部商城数据更新2天更新一次，主流5个综合商城每天更新一次（京东除外）
CPS和API搭建在hadoop集群内； 一台独立MongoDb；
以上架构缺点：没有容灾性，宕机会丢失数据，尤其是WEB/MYSQL服务器、搜索服务器和MongoDB服务器这3台机器是支撑我们前端服务的，一旦一台主机宕机网站就无法正常使用。
三、最佳架构：需要18台服务器
114.113.229.73WEB主webmysqlMail114.113.229.72WEB从webmysqlMail114.113.229.74massterHadoopJobs114.113.229.*搜索SolrSolr Home114.113.229.*搜索SolrSolr HomeAPI114.113.229.*搜索主SolrSolr Home索引搜索服务114.113.229.67slaveHadoopHadoop-datatomcat编辑后台114.113.229.69slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data搜索服务搜索服务114.113.229.66slaveHadoop114.113.229.70数据库从MongoDB114.113.229.71数据库从MongoDB114.113.229.68数据库主MongoDBHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*slaveHadoopHadoop-data114.113.229.*CPSCPS
爬虫服务器Hadoop：9台（配置需求不高）架构可以随时扩容。满足所有80家商城数据更新每天可以更新一次，部分综合商城可以做到每天更新2次（京东除外）
数据库服务器MongoDB：3台主从（配置需求比较高）架构可以随时扩容。
搜索服务器SOLR/编辑后台：3台主从（配置需求比较高）架构可以随时扩容。搜索服务器Solr服务将支持 千万级以上数据量，并可以随时根据服务器压力扩容。 CPS： 1台，能满足初期CPS接入流量，可以随时扩容。 Web/Mysql：2台主从（配置需求比较高）架构可以随时扩容。
架构服务 篇6
关键词：面向服务的体系结构；电子商务；应用
中图分类号：TP302.1文献标识码：A
基于Internet的电子商务系统平台，将给企业带来无限商机，同时对企业的管理和经营提出了更高的要求。现代市场营销观念是以营销者更好地满足目标顾客的需要和欲望为出发点的。因此，为客户提供更加快捷、有效的服务，已经成为企业发展的重要条件。基于面向服务的体系结构(SOA)的电子商务系统平台，这就为企业采用网络营销，搜集、编辑、整理和分析其目标顾客的数据资料，进而能够以目标化的互动传输方式为客户提供个性化的产品和服务。
1 SOA概述
SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种系统中的服务可以用统一和通用的方法。
SOA是一个面向未来的长期策略。它可以大大提高rr基础结构的灵活性，减少了技术依赖，简化了开发过程，也可以为企业提供永久的敏捷性。通过允许强定义的关系和依然灵活的特定实现，IT系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。SOA可以使企业满足短期内的新业务要求，它通过重复利用现有业务逻辑和数据模型，将成本、资源和时间开销降至最底，并降低风险来达到此要求。与重新编写整个应用系统相比这显示了SOA的巨大优势。
2采用SOA架构实现电子商务系统平台
2.1系统实现技术
面向服务架构最常用的一种实现方法是Web Services技术，Web Services技术使用一系列标准和协议实现相关的功能，其中XML作为Web Services技术的基础，是开放环境下描述数据和信息的标准技术。作为SOA的一种实现手段，Weh服务继承XML语言的优势，是一种与开发语言、应用平台无关的开发技术。Web Services由SOAP、WSDL和UDDI组成。服务提供者可以用WSDL(Web服务描述语言)描述Web服务，用UDDI(统一描述、发现和集成)向服务注册代理发布和注册Web服务，服务请求者通过UDDI进行查询，找到所需的服务后，利用SOAP(简单对象协议)来绑定、调用这些服务。
2.2系统总体设计
企业要构建一个使用不同硬件设施和软件平台，以及可能不在同一个地域的，一个以信息交换为技术基础、以价值链的理论系统为理论基础的一个在供应商、分销商、用户、银行等之间建立起实现一个跨地域、跨平台、易扩展的综合电子商务平台。在架构设计时，选择了基于Web Services的SOA模型，以解决异构系统互连，低成本高扩展性需求等业务问题。系统平台运行于各个不同运营商之间的多台服务器上，从结构和功能上大致可以分为Web Service应用服务，网络交易业务门户网站服务，物流管理服务，库存管理服务，网银结算服务，每类服务均由在不同平台类型的服务器组成。
系统的主体部分以及重心在网络交易业务门户网站和Web Service应用服务。网络交易业务门户网站服务针对用户的请求作出响应。与网络交易业务服务提供者的合作单位使用Web Service发布的接口与之通信，将用户交易业务的信息数据传输到网络交易业务门户网站的数据服务集群中，牵扯到结算的数据提供给网银服务服务器。
这种系统结构是一种分布式的计算结构，也是一种典型的多层架构：
(1)数据层：数据层中包含数据访问子层和数据，数据访问子层是业务逻辑层和数据的桥梁，为业务逻辑层中的业务系统提供数据访问功能。数据层中的数据包括现有分散异构的数据库系统资源库。
(2)业务逻辑层：业务逻辑层封装业务逻辑和规则并且调用各个服务器的Web Service提供的服务，负责提供对用户请求的响应和与合作单位通信，为合作单位提供数据的统一接入方式，在异构的系统之间提供服务支持。
(3)服务层：服务层是整个系统架构的核心，调用各个Web服务生产代理类，生成代理对象，成底层与数据库的交互工作，目中所有Web应用底层的数据操作都采用了同一套业务代码以达到重用的目的；UDDI服务用于系统所有Web服务的发布和发现，以便于系统中各个独立企业之间实现更好的合作。
(4)应用层：应用层就是网络交易业务门户，将各种服务应用集中在一起，提供可用、高效、一致的界面和统一的信息访问机制，为不同的用户提供个性化的服务。
3结束语
浅析面向服务架构体系的搭建 篇7
一、SOA的定义
SOA, 是一种基于服务的业务组建模型, 它通过服务间定义良好的接口和契约联系起来。接口采用中立的方式定义, 独立于具体实现服务的硬件平台、操作系统和编程语言, 使得架构在这样系统中的服务可以使用统一和标准方式进行通信。
SOA架构的基本元素是服务, 服务是代表着一定业务功能且可以被其他方请求调用。服务是独立而自治的, 它屏蔽了平台、语言、业务流程等具体技术问题, 具有标准化的接口, 使用服务的用户只关心服务给出的结果, 而不用关心业务细节和技术实现方式, 可以在未来很方便的加入或取消服务。
二、SOA模型的角色关系
万维网联盟 (W3C) 给出了SOA模型中服务提供者、服务请求者、服务代理者等角色的关系。
服务提供者主要提供符合契约的服务, 并将它们发布到服务代理;服务请求者也叫服务消费者, 它发现并调用其他的软件服务来提供商业解决方案, 消费者可以是终端用户、应用程序或者别的服务;服务代理者, 作为储存库, 产生由服务提供者发布的软件接口。
这三种SOA参与者通过3个基本操作:发布、查找、绑定相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务, 并绑定到这些服务上。服务提供者和服务请求着之间可以交互。
三、SOA体系搭建
SOA体系包括服务的提供、使用、说明、中介等四个方面。
搭建SOA体系, 首先要定义原子服务, 从业务角度讲, 每一个原子服务可以是每一个基本的业务单元, 将原子服务进行合成为可以使用的服务, 当然, 单独的原子服务也可以为服务, 然后, 对服务进行编排, 定义各自的业务流程, 最后构建服务消费者访问和使用服务的方法。
为了更清楚地描述SOA的搭建过程, 我们通过实现银行业IT系统的例子来进行分析说明, 银行的核心业务系统为SOA角色中的服务提供者, 企业服务总线系统为SOA角色中的服务代理者, 而使用服务的系统, 如网上银行、ATM、柜员、手机银行、中间业务平台等系统则为SOA角色中的服务消费者。核心业务系统向企业服务总线系统发布服务, 企业服务总线系统则对这些服务进行合成、编排, 组成很多的业务流程, 并分别发布给网上银行、ATM、柜员、手机银行、中间业务平台等各种各样的服务以供使用。如简单的ATM取款交易, 客户在进行取款交易时, 客户触发取款动作后, 在拿到现金以后, 同时可以自动看到自己账户的余额, 这就是通过企业服务总线系统将核心业务系统的取款、余额查询等二个原子服务编排成一个简单的业务流程对ATM系统进行发布。而同样的取款交易, 通过柜员系统进行取款时, 企业级服务总线系统则可能只将核心业务系统的取款原子服务组成一个业务流程对柜员系统进行发布。这是不同的业务需求对业务流程的不同要求。
一个成功的SOA系统应该总在变化之中的, 可以很灵活、敏捷的适应业务需求的变化, 服务总是位于业务和技术之间, 通过业务驱动服务, 服务驱动技术。
四、SOA的特征
通过对SOA体系的搭建, SOA体系具有一些特征:
封装和重用性:原子服务可以按照业务流程进行不同的封装, 封装可以隐藏复杂性, 服务发布后可被很多服务消费者重用, 这种设计降低了业务变更成本, 使变更便的更为简单、可行。
自治性:SOA体系屏蔽了平台、语言、业务流程等具体技术问题, 强调架构的自我管理和恢复能力。SOA体系应该良好的支持事务处理、队列冗余部署、集群管理等技术。
松藕性:服务消费者可以在未来很容易的加入或取消服务, 或者选择新的服务, 而不需关心服务提供者实现的技术细节, 甚至不必知道响应自己需求的服务的位置及原子服务。
五、小结
SOA体系已被做为一种通过对齐IT和业务来促进业务敏捷性的方法而被广泛接受, 通过SOA架构可以相对较低成本的获得某种敏捷性, 适应业务的快速变更、灵活发展, 但SOA并不是适应于各个业务系统的, 它只是一种基于业务复用的架构方法, 如果对业务变化理解力不足, SOA带来的麻烦可能比普通系统更多。为了尽早达到后期低成本的多次业务迭代愿望, 在项目实施早期为此目的而构造企业架构是非常有意义的。
摘要：面向服务架构 (SOA) , 是一种形式化的方式分离服务的架构风格, 在构建弹性架构强烈的需求背景下发展起来, 对整个企业级软件架构设计带来巨大的影响。本文首先对SOA的定义进行简单介绍, 并对SOA模型的角色关系、体系搭建及特征等进行分析。
关键词：SOA,体系搭建,服务
参考文献
RIM改革必须开放服务架构资源 篇8
一片否定声中, RIM仍在继续试探着资本市场和客户的耐心:搭载新一代QNX系统的BlackBerry 10系列智能手机发布时间由今年初推迟到了今年末;2012财年Q3的盈利业绩、销量仍无起色, 股价几乎跌至近8年来的最低水平。应该说, RIM股价没有“一泻千里”已是一个奇迹。
也许这是因为业界普遍看到, 尽管形势艰难, 但黑莓仍然存在着巨大的核心竞争力。毕竟, RIM有着结合专用硬件和专有软件平台的优势, 与苹果相似, 属于“两手都很硬”的角色, 并且, RIM企业服务器的应用服务仍然有着巨大的生命力。
但在与苹果iPhone和搭载谷歌Android系统的智能机的竞争中落败, 说明RIM公司必须做出改变。于是, 人们想起了杰克·韦尔奇重构GE以及郭士纳带领IBM成功转型的例子, 也就出现了RIM应当炒掉冥顽不化的联席CEO及RIM应出售手机业务的呼声。
事实上, 急于撤掉联席CEO以及部分或全部出售RIM业务的人们, 更多的是急于看到RIM市值的回升, 以拿到预期的投资盈利, 而非是从RIM长远发展的角度出发。当谷歌以125亿美元收购摩托罗拉移动后, 摩托的股价出现了回升, 但近期又传出谷歌在完成专利交叉授权后将再次出售摩托的传言, 这似乎说明了, 被收购并非是最佳选择。更何况, 现在出售RIM手机业务已经无法获得像以前那么高的溢价, 既然RIM仍然有着较为充裕的现金流, 就不必将出售放在优先考虑的位置。
对此, 笔者认为, RIM更应该把注意力放在挖掘除自身手机业务以外的架构资源, 必须看到, RIM还有大量可以盈利的服务架构资源没有得到充分利用, 比如BAS和BIS。
好消息是RIM似乎已经在朝着好的方向转变。前不久, RIM宣布推出延伸服务, 黑莓BAS和BIS邮件服务将支持iOS系统与安卓系统的智能手机与平板电脑, 此前该公司服务仅限黑莓设备。黑莓的核心服务开放举措将维持其在企业市场的领先地位, 此时大多数企业客户将继续采用黑莓相关服务, 即使黑莓手机的硬件利润缩水, 也不再会影响RIM的总体利润率, 因为, 新的利润增长点已经产生。
区域医疗服务平台网络架构设计 篇9
1 需求分析
市民健康系统存储了完整的市民健康档案,旨在采集每个市民所有健康信息,为市民建立一份完整的健康档案,时间从新生命开始到生命消失的整个过程,内容包括出生信息、免疫息、体检、门急诊诊疗、住院诊疗、妇幼保健、健康调查、死亡证明等在医疗机构中产生的相关医疗及健康信息,同时还包括个人自我保健信息录入。在基础数据采集过程中,需要和户籍信息中心、社保数据中心等进行数据交互。为了获得相关医疗及健康信息,也要对各级医疗机构等进行数据采集。在对普通市民或保险、健康咨询等第三方公司提供信息服务时,则需要通过互联网提供相关查询、检索等功能。因此,市民健康系统是一个基于广域网的系统,在卫生系统内部采用专用的VPN网络模式采集和访问数据,其中外部的访问功能通过Internet进行发布。
1.1. 网络实体
区域医疗服务平台需要对多种网络实体进行连接。根据各个网络实体的性质,本文将这些网络实体归纳为以下几类:
1.1.1. 各类基础数据中心
如户籍信息中心、社保信息中心、市民健康数据(卫生信息)中心。此类网络实体主要是进行各种基础数据的网络交互,数据敏感度高,对安全保密要求很高。
1.1.2. 政府职能部门
如卫生局、疾控中心等。此类网络实体主要是对市民健康数据中心进行信息查询、分析工作。
1.1.3. 各级医疗机构
各级医疗机构由于规模不同、发展不同,情况各不相同。医院、社区卫生服务中心等大都已经建设完善了内部网络,而小的乡卫生院、村卫生所可能仅有1台计算机采集、上报数据。此类网络实体需要和市民健康中心进行网络连接,提供在医疗机构中产生的相关医疗及健康信息。
1.1.4. 市民个人
市民个人需要方便、及时的通过各种方式来访问本人的健康档案。
1.1.5. 保险、健康咨询、医疗行为分析等第三方公司
此类第三方公司在获得授权的基础上,通过市民健康系统开放的网络接口,获取相关健康档案,对市民健康信息进行数据分析处理。
2 逻辑结构
厦门市建立的区域医疗服务平台的网络逻辑结构是:依托市民健康系统平台,通过与户籍信息中心和社保信息中心联网获取市民个人基本信息与体征信息。通过与各级医院、社区卫生服务中心、卫生院(所)等卫生机构联网,采集生成完整的市民健康档案。政府卫生机构通过对市民健康系统的医疗档案数据进行分析,可以对医疗机构的医疗行为进行监控,辅助政府进行卫生资源配置的决策;市民个人通过互联网访问市民健康系统提供的WEB服务器,可以根据需要能及时了解自己的健康状况,并可授权医生对自己健康数据进行调阅分析;第三方公司通过授权,访问市民健康系统提供的接口,可以基于完整、海量的市民健康信息进行数据挖掘,进行医疗行为分析、市民健康趋势分析。
3 网络设计
区域医疗服务平台的网络架构中不同网络实体之间的数据交互特点不同,之间的联网方式可分为以下几种:
3.1. 各级数据中心之间的网络连接
各级基础数据中心之间由于传输数据量较大,对网络传输质量要求较高,所以利用政府内部网络光纤专线接入,可有效保证数据安全性和传输可靠性。
3.2. 政府职能部门和市民健康数据中心的网络连接
各级卫生局、疾控中心与市民健康数据中心同属于卫生局内部专网,因此利用卫生局内部专网可以安全可靠的访问市民健康系统。
3.3. 各级医疗机构和市民健康数据中心的网络连接
各级医疗机构由于自身规模不同,分布地域广泛,因此可利用电信服务商提供的VPN专线加密连接到市民健康系统。根据医疗机构自身的规模和数据量,内部有局域网的医疗机构如医院、社区卫生服务中心等可以采用光纤专线接入;对于偏远的乡卫生院、村卫生院可以采用ADSL设备接入。
3.4. 市民个人访问市民健康系统
市民个体分布广泛、采用的通讯方式多种多样,因此,不能采用专线接入内部专网的方式直接访问市民健康数据中心。市民健康系统通过架设在互联网WEB服务器开放443(HPPTS)端口,来保障广大市民的数据访问需求。在这台服务器上只架设Web网站,数据访问须通过防火墙后利用应用服务器调用数据中心的各种健康信息,来解决互联网和内部专网之间的安全问题。
3.5 第三方公司访问市民健康系统
各类需要对医学健康信息进行数据挖掘的第三方公司和研究机构,自身的网络情况各部相同,处于安全性考虑,不适宜直接接入卫生系统内部专网。因此,此类公司和研究机构在通过取得授权的情况下,通过互联网访问市民健康系统WEB服务器,调用专用的数据接口,来获取需要的数据。
4 结论
厦门市市民健康系统网络架构设计正在逐步变为现实,在全市绝大多数医疗机构基础网络互联互通的基础上,为市民建立一份完整的健康档案,时间从新生命开始到生命消失的整个过程,内容包括出生信息、免疫息、体检、门急诊诊疗、住院诊疗、妇幼保健、健康调查、死亡证明等在医疗机构中产生的相关医疗及健康信息。市民健康系统可进一步满足疾控、医疗保险、个人保健、卫生统计、临床科研、行政管理等方面需求,为居民提供方便快捷的卫生服务环境,加强政府对卫生服务的监管力度和决策能力。
参考文献
[1]刘莉.区域医疗信息化工程规划的思考[J].中国西部科技,2008,(7):34-35.
[2]王继伟;陈新.厦门市区域电子病历系统认证和访问控制子系统设计方案[J].福建电脑,2005,(6):11-12.
[3]孙中海,孙卫,等.市民健康信息系统安全策略及架构[J].医学信息,2008,(12):2133-2136.
架构服务 篇10
登录爬虫是一套实时的系统, 用户输入待爬取网站的用户名和密码, 系统会自动登录账号, 并爬取账号内页面数据, 以报告的形式提供给用户。 通过爬虫系统爬取该用户的信用相关信息, 形成信用报告。 微服务架构的几个主要的设计理念: (1) 通过服务实现组件化。 微服务使用服务的形式来实现各个功能组件模块, 各个模块间的依赖通过服务的方式来组织, 即一个模块通过远程过程调用来依赖另一个模块, 每个模块是一个微服务。 (2) 企业按照业务功能来组织团队, 每个团队负责一个微服务, 可以做到 “谁构建, 谁运行”, 这将极大降低运维复杂度, 缩短上线周期。 (3) 微服务可以方便地做到离散化数据管理。 每个微服务可以自行管理各自的数据, 包括不同业务的数据、 不同微服务的配置等等, 更加切实匹配业务需求。 (4) 微服务构架使得持续集成和持续交付变得更加便捷。 有了微服务, 集成和交付的单元从大而全的整体应用变成了各个微服务, 每个微服务都可以灵活地集成和交付。 这个系统在设计之初就考虑采用微服务架构, 以便部署在DCOS环境, 并享受DCOS所带来的各种特性。
由于整个系统的每一个处理环节都是多实例的, 模块之间都不直接发生依赖关系, 而是采用消息队列或者存储系统进行解耦。 大部分服务之间都通过分布式消息队列或存储系统进行交互, 这样做的好处使得服务之间实现了异步交互, 降低了耦合性。 但这种异步方式并不适应于任何场合, 例如Loginer的设计就必须采用同步调用的方式, 主要原因是: 1.用户在输入用户名、 密码后, 需要Loginer立刻进行模拟登录以验证输入的正确性; 2.如果网站登录页的验证码是在用户名、 密码输入后才显示, 则还需要将验证码图片返回给用户, 由用户判别并输入验证码信息后, 再进行登录操作;3.Loginer采用Selenium或Http Client进行模拟登录, 当网站登录页需要进行JS渲染的时候, 就需要用到Selenium; Selenium通过浏览器driver打开浏览器, 访问登录页, 开始进行模拟操作; 为了简化浏览器状态的维护, 在设计时限定每个Loginer实例同时只能处理一个登录请求, 直到本次登录完全结束, 关闭浏览器, 才可以处理下一个登录请求。 可见, 每个Loginer需要维持一个状态机。 因此, Loginer需要部署较多的实例数; 另外, 由于浏览器driver不够稳定, 时而出现调用无效的情况, Loginer需要有重启机制。
架构服务 篇11
关键词: 面向服务架构(SOA) 标准化组织 标准 规范 技术标准 发展趋势
中图分类号: F270 文献标识码: A文章编号: 1007-3973 (2010) 04-133-03
SOA的概念最初由Gartner公司于1996提出,由于当时的技术水平和市场环境尚不具备真正实施SOA的条件,因此当时SOA并未引起人们的广泛关注。伴随着互联网的浪潮,越来越多的企业将业务转移到互联网领域,带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务,出现了Web服务的概念,这可以说是SOA的开端。
新技术的兴起必然伴随着一系列技术标准和规范的诞生,SOA也是如此。短短几年之内,在厂商、研究人员和标准化组织的共同努力下,已经制定出一大批SOA标准和规范,有力地推动了SOA的发展。据统计,目前有超过56个涉及SOA的各个方面的标准机构,但他们之间工作的不协调,也给SOA的发展带来的负面影响。
近年来,国内有关院校、研究单位、IT相关单位都比较重视软件体系结构的研究工作,面向服务软件体系结构的研究已经成为热点,比较多的研究项目尚处在概念研究阶段。随着SOA技术的不断发展,中国的SOA架构模型和应用推广已经有了良好的需求环境。为了进一步推进SOA在中国的发展,形成中国特色的SOA架构模型和规则规范,由东方通科技(TongTech)等民族软件企业发起倡议,宣告成立的“SOA-RA-TF(SOA Reference Architecture Technology Forum)组织”,成员单位包括太极、神州数码、国研科技、北京软件产品质量检测检验中心、中和威、有生博大、中科红旗、华迪等11家单位。东方通科技(TongTech)是国内领先的中间件厂商,也是中国SOA的探路者。2005年,东方通提出了“BOA=Business+SOA”的概念,为SOA填入了许多本土的行业特性和区域特性。有人评价BOA为“穿上唐装的SOA”。
SOA在中国的实施,主要是国外技术在中国市场的应用,一些成功案例的主要解决方案提供商都来自BEA和IBM等。作为支撑技术实现的标准规范,现在,国内几乎没有标准组织和厂商参与SOA标准的制定工作。目前,只有普元公司参与了SCA/SDO(服务构件架构/服务数据对象)标准的部分制定工作,它也是亚洲唯一一家成为OSOA(开放SOA合作组织)成员的企业。
1 SOA标准/规范的发展
“标准”与“规范”这两个术语通常被人们交替使用,但严格的讲,二者还是有一定差异的。规范是标准的建议文档,标准一般是由业界公认的标准化组织制定和发布,而规范要灵活的多,多为厂商或非标准化组织发布。
从上世纪九十年代末到本世纪初,可扩展标记语言(XML,Extensibl Markup Language)的出现,无疑为SOA的兴起奠定了稳固的基石。
2000年以后,人们普遍认识到基于公共――专有互联网之上的电子商务具有极大的发展潜力,因此需要创建一套全新的基于互联网的开放通信框架,以满足企业对电子商务中各分立系统之间通信的要求。于是,人们提出了Web服务的概念,希望通过将企业对外服务封装为基于统一标准的Web服务,实现异构系统之间的简单交互。这时,出现了三个著名的Web服务标准和规范:
(1)简单对象访问协议(Simple Object Access Protocal,SOAP);
(2)Web服务描述语言(Web Services Description Language,WSDL);
(3)通用服务发现和集成协议(Universal Discovery Description and Integration,UDDI)。
这三个标准可谓Web服务三剑客,极大的推动了Web服务的普及和发展。短短几年之间,互联网上出现了大量的Web服务,越来越多的网站和公司将其对外服务或业务接口封装成Web服务,有力的推动了电子商务和互联网的发展。Web服务也是互联网Web 2.0时代的一项重要特征。
经过几年的努力,Web服务标准集已经初具规模,内容涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性、事务处理、安全和管理等方面。
Web 2.0基于Web架构,这种架构可以作为SOA架构的子集。未来SOA与Web 2.0结合起来的想法并不是不可想象的。真正值得感兴趣的是SOA的发展前景,这其中包含了部分Web 2.0中的特性。
从2005年开始,各大厂商也逐渐放弃成见,通过建立厂商间的协作组织共同努力制定中立的SOA标准。这一努力最重要的成果体现在3个重量级规范上:SCA、SDO、WS-Policy。这三个规范的发布,标志着SOA进入了实施阶段。
2 SOA主要标准
SOA思想可以通过Web Services、CORBA、RosettaNet、ebXML、J2EE、WebSphere MQ等技术实现,但人们更普遍的还是会想到通过Web服务技术实现SOA。所以,Web服务对SOA的影响是什么呢。SOA是一种围绕服务(不是Web Service)的技术实现构架、方法、模式,SOA可以不依赖于Web Service而存在,没有SOA,Web Service依然能工作得很好,但使用Web Service,可以极大的提高SOA实现能力。
Web服务思路的更为成熟,带动了标准的日渐成熟,也为SOA架构走向应用创造了条件。SOA不但利用Web服务实现技术上的互动,同时,考虑如何去掉技术相关性、从业务的层次如何降低“耦合”度。Web服务中部分标准已经比较成熟,如用于通信的SOAP(XML消息传递),建立请求者与响应者关系的WSDL(Web服务描述语言),是目前发展比较快的两个标准。
但现有的一些Web Service 技术标准大都受个别厂商的约束与控制,没有实现开放标准。在由传统构架转换到SOA构架过程中,我们需要采用一些新的、开放的技术规范与标准。因此,在此基础上,一些国际标准化组织,包括:OASIS、WS-I等,都相继制定了针对SOA架构的标准,在这里介绍一些参与制定SOA方面标准的主要标准化组织,及相关技术性标准。
2.1 OASIS标准集
OASIS(结构化信息标准促进组织,Organization for the Advancement of Structured Information Standards)是一个非盈利的国际协会,致力于电子商务相关标准的制定和推广,也是目前制定Web服务标准最多的一个组织。除了制定通用的电子商务、Web服务和安全标准之外,OASIS还制定了很多针对行业的电子标准。OASIS最初在1993年由SGML Open改制而成,1998年改名为OASIS,理事会成员几乎全部来自微软、IBM、BEA system、Oracle、Sun、SAP AG、诺基亚等业界大公司。
OASIS为SOA专门成立了六个技术委员会(Technical Committees),分别负责制定电子商务、Web Service开发和部署、服务质量以及面向服务架构等方面的标准。
2.2 WS-I标准集
WS-I (Web服务互操作组织,Web Services Interoperability Organization)是一个开放的厂商联盟,鼓励任何对Web服务有兴趣的厂商加盟并贡献自己的力量。它主要致力于提升Web服务基于平台、操作系统和编程语言中立的互操作能力,其成员几乎覆盖了所有重量级厂商,如IBM、微软、Sun、Oracle和BEA等。
2.3 SCA/SDO
OSOA(开放SOA合作组织,Open SOA Collaboration)是一个非正式的厂商联盟,使得各厂商能够共同开发一个语言中立的编程模型。该编程模型帮助企业软件开发人员能够最大限度的发挥SOA架构的特性和优势。目前加入OSOA的厂商包括IBM、BEA、SAP、Oracle等。尽管OSOA不是一个标准化组织,但由于有IBM、BEA等业界厂商的支持,它制定的规范很可能会成为事实上的标准。因此,我们可以把它看作一个准标准化组织。OSOA成立了两个项目组,分别负责制定SCA(Service Component Architecture,服务组件架构)和SDO(Service Data Objects,服务数据对象)规范。
如果把SOA的思想类比为以插接积木的方式来构件灵活的、可复用的企业IT系统,那么SCA相当于做了那个带插孔的底板。SCA提供了一个统一的面向服务组件的调用方式,从而使得用户可以把不同的软件模块通过服务组件的标准化统一的封装起来和被调用访问。而SDO则作为一种数据编程架构和API,统一了不同数据源类型的数据编程,让开发人员可以从不同的数据源以统一的方式访问和操纵数据。可以说,SCA以面向构件的方法,简化了用户的业务逻辑编程,提高了应用的灵活性。而SDO则更进一步从数据对象上大大简化了开发。两者不是互相依赖的关系,SDO是SCA的优先但非必要的数据载体。SCA的实现可以支持其他数据形式,如JAXB等。但是SCA搭配SDO是最优组合,因为这样可以彻底排除系统实现的相关性。并且,SDO设计本身就是为了松散耦合而优化的。
2.4 W3C标准集
W3C(万维网联盟,World Wide Web Consortium)由Tim Berners-Lee于1994年创立,主要负责制定Web相关标准和规范,比如HTML、CSS等。W3C专门成立了Web服务专区,下辖六个工作组,负责制定Web服务相关的标准。W3C对Web服务的发展可谓功不可没,像非常著名的SOAP和WSDL皆出自于W3C。
为了发挥网络的最大潜能,最基础的网络技术必须要求硬件与软件之间相互兼容。W3C将这个目标称之为“网络共融化”。通过发布公开化,非私有化和为网络语言和协议提供标准,W3C制止和避免了很多因为网络混乱而产生的市场混乱。
上面提到的四个标准组织,在制定SOA标准方面各有侧重,WS-I组织主要制定WS-*(Web服务族)及相关的标准/规范;OASIS组织重点制定综合类和协同类的标准;OSOA组织制定了SCA/SDO标准;W3C组织则侧重在协议类等方面的标准制定。SOA的标准并不是完全与Web服务标准无关而独立存在的,它是建立在Web服务等技术基础上,更体现了SOA灵活、开放、粗粒度的特性。
那么在众多的SOA标准/规范中,首先应选取实现SOA的相对成熟和稳定的技术;其次,标准组织的权威性,上述介绍的四个标准组织是目前业界公认的制定SOA标准方面较有说服力的标准化组织;第三,尽量选取有相应产品支撑的标准。
3标准发展趋势
2007年将会有许多SOA的规范升级为标准。2007年会有三个重量级的标准问世,它们就是目前已经发布的SCA、SDO,和将要发布的WS-Policy。SCA和SDO构成了SOA组件开发的核心,而WS-Policy则成为SOA组件间安全通讯的标准。
今后标准开发将具有一个共同的特点,就是标准与SOA架构的协调性。也就是说,无论是已有的标准还是正在开发的标准,都必须符合SOA架构的要求,如,IBM、微软、BEA,及普元公司倡导的“中国SOA从面向构件开始”;同时要考虑单个标准与其它SOA标准之间的协调一致。基于市场的强劲需求,各标准化组织将继续加大在制定SOA相关标准上的投入力度,标准的制定和发布周期将大大缩短。
从BEA第一个举起SOA的大旗,紧随其后,IBM、Oracle、微软、SAP等软件业巨头也纷纷投身其中,相继推出了各自的SOA解决方案,并且鼓励其用户逐渐转向SOA。BEA推出了SOA 360?平台计划;IBM有On-Demand(随需应变)策略,推出了IBM WebSphere中间件,及IBM一直在强调的“总线”概念,它关注的领域是系统领域,为企业用户提供全套的架构服务;Oracle有强大的产品链条,从企业应用、数据库到中间件来带动其SOA服务;微软从操作系统到应用都有强大的技术支持,它推出的商务应用软件Dynamics,也是不可小看的;而SAP的Net Weaver同样为人关注。这些软件业巨头,他们推出的产品与其制定的标准是互惠互利、密不可分的,一边它们通过产品的推广,宣传自己制定的标准,一边是通过介绍标准来引起人们对支撑标准的产品的注意。但随着,竞争的白热化,目前各大主流厂商通过竞争能够诠释公认的SOA标准的软件产品,捍卫自己在SOA领域的地位。
4 结语
据Gartner最新研究成果,2007年全球50%的新的核心业务系统将会使用SOA架构,到2010年,这个比例将达到80%;同时,80%的现有应用系统也将在2011年前完全演进并融入到SOA的架构中。
随着技术的不断成熟,SOA发展的焦点应聚焦在关注业务而胜过技术,从技术层面来看,SOA是一种“抽象的、松散耦合的粒度软件架构”,而从业务层面来看,SOA的核心理念是“重用”和“互操作”,它将资源整合成可操作的、基于标准的服务,使其能被重新组合和应用;SOA的另一个发展焦点是,在开发基于SOA的架构时通过Web 2.0实现,SOA和Web 2.0的结合也指日可待。
业务和技术的发展趋势必然影响标准制定的方向,目前,我国SOA标准还处在借鉴和应用商业及国际标准的阶段,我们在明确SOA和Web 2.0能给我们带来怎样的优势的同时,还需要解决:
(1) 标准的不完备。Web服务是实现SOA最好的方式,但Web服务本身还有很多不成熟的方面。在可靠消息传递、安全Web服务、Web事务处理等方面的标准还有待完善;
(2) “服务”大小的问题,也就是所谓“服务”颗粒度粗细的问题。目前“服务”的大小还要根据经验来制定。因此实现真正标准化组件,还有很长的路要走。
但是,相对于民用领域SOA在理论和应用两方面如火如荼的发展,在军用综合电子信息系统应用方面,研究成果报道较少。我军军用综合电子信息系统的建设,面临军事转型,因此,非常需要软件技术的发展和创新。SOA是软件技术发展新的里程碑,是从高层次上解决军事综合电子信息系统互操作问题的一种重要技术途径,在标准方面,可参考美军NECC(以网络为中心的指挥能力,Net-Enabled Command Capability)等技术标准框架,结合我军实际应用情况,制定近五年内推荐使用的SOA相关标准。从面向对象方式跨越到面向服务方式的应用,将给我军综合电子信息系统的发展带来一次新的飞跃。
参考文献:
[1] WS-I.WS-I标准和其它审核工作[EB/OL].http://www.ws-i.org.
[2] OASIS.OASIS标准和其它审核工作[EB/OL].http://www.
oasis-open.org.
[3] W3C.W3C标准和其它审核工作[EB/OL].http://www.w3.org.
架构服务 篇12
传统信息运作方式虽然大大推进了企业生产力, 但又反作用于信息技术, 促使企业内外部商务信息的大规模集成。从面向过程到面向服务的4个关键阶段可以看出, 程序语言发展的过程实质为逐步降低耦合性的过程, 也是接口与接口实现逐渐分离的过程 (见表1) 。
在Web Service的基础上发展起来的面向服务架构 (Service-Oriented Architecture, SOA) 的思想将企业应用看作一些可跨越企业边界、自我描述、实现某一特殊功能的服务集合。通过标准化的机制, 能够将这些服务注册于公共数据库中, 并能被感兴趣的请求者发现;服务者和请求者之间能够进行动态绑定和直接交互, 实现一定的企业功能逻辑 (SOA模型如图1所示) 。而作为SOA的一种实现手段, Web服务以其完好的封装性、松散的耦合性、协议规范的标准性以及高度的可集成性等特点, 能够良好地满足SOA应用模式的需求。
2从BPM到SOA的跃迁
商务流程管理 (Business Process Management, BPM) 在SOA之前出现并已成功实施。早期企业通常会建立各业务部门相对独立且相互之间缺乏协同的流程系统。随着部门分工理论的没落, 各方面的困难使BPM产品一度丧失了竞争优势。而如今, 缺乏灵活性、
高昂的变革成本、以IT为中心的传统应用等因素又促使BPM市场急剧增长。同时, IDC提出流程企业应进化到2.0阶段, 使用SOA的思想方法和技术架构组装企业的BPM, 而BPM的重新崛起在很大程度上又推动着SOA的发展。
在商务流程自动化 (BPA) 、异构系统的无缝整合 (EAI) 、企业流程建模分析 (BPM的核心) 和监控企业活动以实现流程持续改进 (BAM) 等每个BPM的应用场合中, SOA都扮演着至关重要的角色。要从BPM迁移到SOA, 跨越信息技术与业务之间的鸿沟, 需引入一个服务层, 该层包含支持特定业务域的服务线、可跨多个业务域共享的可复用技术服务以及Web Services平台, 允许以各种独立于底层服务和技术平台的方式定义和利用服务。从技术层面看, SOA和BPM结合的方法主要有以下两种:
(1) BPEL+WSDL。先定义好一个BPEL流程, 然后将其纳入到SCA容器。在定义构件时, 可使用子元素的process属性指明这个可执行的BPEL流程的目标名称。
(2) BPEL应用SCA的某个构件。例如, 一个BPEL的变量声明可以包含一个SCA的扩展, 表明这个变量代表了一个SCA构件的属性。
3基于SOA的商务系统信息集成应用建模
某国内知名IT企业ABC公司内部先后实施了由不同厂家提供或自主开发的办公自动化、企业资源计划、决策支持、电子分销、供应链管理等相对独立的商务子系统。随着业务的不断进展, 以及与其他企业的海量信息流通, 需要部署一个基于SOA的商务系统门户集成方案。
考虑到业务需求, 通过集成中间件平台对各商务系统的流程与ERP核心子系统进行实时无缝的链接, 使企业内部整体的商务流程更加完整和流畅。此外, 通过集成中间件平台集成ABC公司与其供应商Z公司之间的异构ERP系统, 使整个供应链的商务流程更加完整和流畅。
集成后的SOA架构应用模式为:OA系统首先根据内部登录人员的配置信息确定用户身份并给予相应权限, 根据此权限范围内的工作流程和列表提供流程表单。用户需在表单上填写与流程控制、ERP系统相关的参数及其他字段信息。工作流引擎根据流程定义文档控制流程执行, 当流程流转到某个需要调用Web Ser-vice的活动时, 发送SOAP请求信息给服务提供者。Web Service利用数据访问逻辑组件操作数据库表。以采购申请为例 (图2为采购流程定义) , 用户调用ERP的采购管理Web Service的“采购信息保存”方法, 将采购的物料编号、采购数量、价格范围、供应商等信息存储到ERP的数据库。服务提供者实现服务之后, 将包括单据编号和状态等信息的SOAP返回信息传回OA系统。工作流引擎根据WSDL文档解析该SOAP返回信息, 将它自动存入流程表单并将表单传送给服务器, 然后根据工作流控制数据和组织/角色模型将流程表单传递给下一个执行者, 并同时发送E-mail通知。
4结 语
基于SOA架构的BPM可使企业机构快速部署和改变流程, 有助于满足跨越系统、地域和组织界限的端到端商务流程需求, 使企业具备敏捷的商务竞争优势。下一步面临的问题是:如何持续改进BPM流程, 识别出最有价值的商务流程模型去实施企业级SOA;在此基础上, 如何逐步积累经验, 更深入广泛地推广BPM应用。实践表明, 在影响项目成功实施的各种因素中, 除了在战术层面需要能正确实施BPM和SOA的混合分步部署的系统架构师以外, 管理理念与组织协调等人为方面的难题远大于技术难题。因此, 要成功部署SOA, 企业不能仅关注技术, 更应把持续改进流程作为先进的管理理念和必不可少的长期商务战略。
参考文献
[1]罗鸿, 王忠民.ERP原理、设计、实施[M].北京:电子工业出版社, 2003:45-60.