问答题
请分析比较两种集成方案的优点和不足,将下表中的空缺处的内容填写完整。
【正确答案】(1)将现有系统看做抽象的服务提供者,集成方法统一明确。
(2)不同层次的集成方法关注点不同,功能组合方面能力较弱。
(3)强调功能的暴露与服务的组合,便于提供增值服务。
(4)一般为中心辐射型,系统的耦合程度较高。
(5)基于总线结构的体系结构,系统的耦合度低。
(6)集成系统具有模块化、松耦合的特点,可扩展性较强。
【答案解析】
问答题
企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。基于SOA的企业集成通过信息服务提供集成数据的能力,针对该企业的集成实际情况,请用300字以内的文字列举3种基于SOA的企业集成中的“数据整合——信息服务”,并给出简要说明。
【正确答案】(1)联邦服务:提供将各种类型的数据聚合的能力,它既支持关系型数据,也支持XML数据等非关系型数据,所有的数据仍然按照自己本身的方式管理。
(2)复制服务:提供远程数据的本地访问能力,它通过自动的实时复制和数据转换,在本地维护一个数据源的副本,本地数据和数据源在技术实现上可以是独立的。
(3)转换服务:用于数据源格式到目标格式的转换,可以是批量的或者是基于记录的。
(4)搜索服务:提供对企业数据的查询和检索服务,既支持数据库等结构化数据,也支持PDF等非结构化数据
【答案解析】[解析] 企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生,用于提供对分布式数据和异构数据的透明访问。以服务为中心的企业集成通过信息服务提供集成数据的能力,目前主要包括如下集中信息服务。
(1)联邦服务(Federation Service):提供将各种类型的数据聚合的能力,它既支持关系型数据,也支持XML数据、文本数据和内容数据等非关系型数据。同时,所有的数据仍然按照自己本身的方式管理。
(2)复制服务(Replication Service):提供远程数据的本地访问能力,它通过自动的实时复制和数据转换,在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
(3)转换服务(Transformation Service):用于数据源格式到目标格式的转换,可以是批量的或者是基于记录的。
(4)搜索服务(Search Service):提供对企业数据的查询和检索服务,既支持数据库等结构化数据,也支持如PDF等非结构化数据。
问答题
结合你的系统架构设计经验,请用300字以内的文字简要说明FT公司项目组在对该企业构建SOA架构时,除了注意原有系统架构中的集成需求之外,还需要在服务构建时重点关注哪些问题。
【正确答案】①对服务粒度的控制。通常情况下,对于将暴露在整个系统外部的服务推荐使用粗粒度的接口,而相对较细粒度的服务接口用于企业系统架构的内部,使用业务流程(BPEL)来创建由细粒度操作组成的业务流程的粗粒度的服务接口
②对无状态服务的设计。架构中的具体服务应该都是独立的、自包含的请求(或是无状态的服务),当某一个服务需要依赖时,可将它定义成具体的业务流程
【答案解析】[解析] 当基于SOA来构建一个企业级的系统架构时,一定要注意对原有系统架构中的集成需求进行细致的分析和整理。而关于系统中最重要的元素,也就是SOA系统中服务的构建有两点需要特别注意的地方:①是对于服务粒度的控制;②是对于无状态服务的设计。
SOA系统中服务粒度的控制是一项十分重要的设计任务。通常来说,对于将暴露在整个系统外部的服务推荐使用粗粒度的接口,而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲,粗粒度的服务接口可能是一个特定服务的完整执行,而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。虽然细粒度的接口能为服务请求者提供更加细化和更多的灵活性,但同时也意味着引入较难控制的交互模式易变性,也就是说服务的交互模式可能随着不同的服务请求者而不同。如果暴露这些易于变化的服务接口给系统的外部用户,就可能造成外部服务请求者难以支持不断变化的服务提供者所暴露的细粒度服务接口;而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。虽然SOA并不强制要求一定要使用粗粒度的服务接口,但是建议使用它们作为外部集成的接口。通常情况下,可以使用业务流程(BPEL)来创建由细粒度操作组成的业务流程的粗粒度的服务接口。
SOA系统架构中的具体服务应该都是独立的、自包含的请求,在实现这些服务的时候不需要前一个请求的状态,也就是说服务不应该依赖于其他服务的上下文和状态,即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时,最好把它定义成具体的业务流程(BPEL)。在服务的具体实现机制上,可以通过使用EJB组件来实现粗粒度的服务。通常情况下,可以利用无状态的Session Bean来实现具体的服务,如果基于Web Service技术,就可以将无状态的Session Bean暴露为外部用户可以调用到的Web服务,也就是把传统的Session Facade模型转化为EJB的Web服务端点。这样就可以向Web服务客户提供粗粒度的服务。
如果要在J2EE的环境下(基于Web Sphere)构建Web服务,Web服务客户可以通过两种方式访问J2EE应用程序。客户可以访问用JAX-RPC API创建的Web服务(使用Servlet来实现);Web服务客户也可以通过EJB的服务端点接口访问无状态的Session Bean,但Web服务客户不能访问其他类型的企业Bean,如有状态的Session Bean、实体Bean和消息驱动Bean。对于后一种访问方式(公开无状态EJB组件作为Web服务)的优势在于:基于已有的EJB组件,可以利用现有的业务逻辑和流程。在许多企业中,现有的业务逻辑可能已经使用EJB组件编写,通过Web服务公开它可能是实现从外界访问这些服务的最佳选择。EJB端点是一种很好的选择,因为它使业务逻辑和端点位于同一层上。另外,EJB容器会自动提供对并发的支持,作为无状态Session Bean实现的EJB服务端点不必担心多线程访问,因为EJB容器必须串行化对无状态会话Bean任何特定实例的请求。由于EJB容器都会提供对于Security和Transaction的支持,因此Bean的开发人员可以无须编写安全代码及事务处理代码。性能问题对于Web服务来说一直都是一个问题,由于几乎所有EJB容器都提供了对无状态会话Bean群集的支持,以及对无状态Session Bean池与资源管理的支持,因此当负载增加时,可以向集群中增加服务器数目。Web服务请求可以定向到这些不同的服务器,同时由于无状态Session Bean池改进了资源利用和内存管理,使Web服务能够有效地响应多个客户请求。由此可以看到,通过把Web服务模型化为EJB端点,可以使服务具有更强的可伸缩性,并增强了系统整体的可靠性。