ERP,SOA与J2EE什么关系
j2ee
J2EE Java2平台企业版(Java 2 Platform,Enterprise Edition)
J2EE是一套全然不同于传统应用开发的技术架构,包含许多组件,主要可简化且规范应用系统的开发与部署,进而提高可移植性、安全与再用价值。 J2EE核心是一组技术规范与指南,其中所包含的各类组件、服务架构及技术层次,均有共通的标准及规格,让各种依循J2EE架构的不同平台之间,存在良好的兼容性,解决过去企业后端使用的信息产品彼此之间无法兼容,导致企业内部或外部难以互通的窘境。 在J2EE架构下,开发人员可依循规范基础,进而开发企业级应用;而不同J2EE供货商,同会支持不同J2EE版本内所拟定的标准,以确保不同J2EE平台与产品之间的兼容性。换言之,植基J2EE架构的应用系统,基本上可部署在不同的应用服务器之上,无需或者只须要进行少量的代码修改,即能大幅提高应用系统的可移植性(Portability)。 J2EE主由升阳(SUN)与IBM等厂商协同业界共同拟定而成的技术规范,以企业与企业之间的运算为导向的JAVA开发环境。J2EE架构定义各类不同组件,如Web Component、EJB Component…等,而各类组件可以再用(reuse),让已开发完成的组件,或者是经由市面采购而得的组件,均能进一步组装成不同的系统。 对于开发人员而言,只需要专注于各种应用系统的商业逻辑与架构设计,至于底层繁琐的程序撰写工作,可搭配不同的开发平台,以让应用系统的开发与部署效率大幅提升。 J2EE的核心规范是 Enterprise Java Beans(EJBs)。EJB依照特性的不同,目前共分为三种,分别是Session Bean、Entity Bean,以及 Message Driven Bean 。其中 Session Bean 与Entity Bean 算是EJB的始祖,这两种EJB规格在EJB 1.x版本推出时就已经存在,而Message Driven Bean则是出现在EJB 2.0的规格之中。 目前业界许多程序设计师,或者是网页设计人员,多利用JSP/Servlet的便利性,进而在J2EE服务器之上开发相关的应用,或是整合公司内部的各种资源。 Java 2平台依照应用领域的不同,共分为三大版本,分别是J2EE、标准版本J2SE(Java 2 Platform, Standard Edition)、微型版本J2ME(Java 2 Platform, Micro Edition),以及Java Card等。 从整体上讲,J2EE是使用Java技术开发企业级应用的一种事实上的工业标准(Sun公司出于其自身利益的考虑,至今没有将Java及其相关技术纳入标准化组织的体系),它是Java技术不断适应和促进企业级应用过程中的产物。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊病,迎合Browser/Server架构的潮流,为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台,从而简化企业应用的开发、管理和部署。J2EE是一个标准,而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器,J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范,因此,使用J2EE技术开发的企业级应用可以部署在各种J2EE应用服务器上。 为了推广并规范化使用J2EE架构企业级应用的体系架构,Sun同时给出了一个建议性的J2EE应用设计模型:J2EE Blueprints。J2EE Blueprints提供了实施J2EE企业级应用的体系架构、设计模式和相关的代码,通过应用J2EE Blueprints所描述的体系模型,能够部分简化架构企业级应用这项复杂的工作。J2EE Blueprints是开发人员设计和优化J2EE组件的基本原则,同时为围绕开发工作进行职能分工给出了指导性策略,以帮助应用开发设计人员合理地分配技术资源。 J2EE组成了一个完整企业级应用的不同部分纳入不同的容器(Container),每个容器中都包含若干组件(这些组件是需要部署在相应容器中的),同时各种组件都能使用各种J2EE Service/API。J2EE容器包括: ◆ Web容器 服务器端容器,包括两种组件JSP和Servlet,JSP和Servlet都是Web服务器的功能扩展,接受Web请求,返回动态的Web页面。Web容器中的组件可使用EJB容器中的组件完成复杂的商务逻辑。 ◆ EJB容器 服务器端容器,包含的组件为EJB(Enterprise JavaBeans),它是J2EE的核心之一,主要用于服务器端的商业逻辑的实现。EJB规范定义了一个开发和部署分布式商业逻辑的框架,以简化企业级应用的开发,使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。 ◆ Applet容器 客户端容器,包含的组件为Applet。Applet是嵌在浏览器中的一种轻量级客户端,一般而言,仅当使用Web页面无法充分地表现数据或应用界面的时候,才使用它。Applet是一种替代Web页面的手段,我们仅能够使用J2SE开发Applet,Applet无法使用J2EE的各种Service和API,这是为了安全性的考虑。 ◆ Application Client容器 客户端容器,包含的组件为Application Client。Application Client相对Applet而言是一种较重量级的客户端,它能够使用J2EE的大多数Service和API。 通过这四个容器,J2EE能够灵活地实现前面描述的企业级应用的架构。 在View部分,J2EE提供了三种手段:Web容器中的JSP(或Servlet)、Applet和Application Client,分别能够实现面向浏览器的数据表现和面向桌面应用的数据表现。Web容器中的Servlet是实现Controller部分业务流程控制的主要手段;而EJB则主要针对Model部分的业务逻辑实现。至于与各种企业资源和企业级应用相连接,则是依靠J2EE的各种服务和API。 在J2EE的各种服务和API中,JDBC和JCA用于企业资源(各种企业信息系统和数据库等)的连接,JAX-RPC、JAXR和SAAJ则是实现Web Services和Web Services连接的基本支持。 J2EE的各种组件 我们就J2EE的各种组件、服务和API,进行更加详细的阐述,看看在开发不同类型的企业级应用时,根据各自需求和目标的不同,应当如何灵活使用并组合不同的组件和服务。 · Servlet Servlet是Java平台上的CGI技术。Servlet在服务器端运行,动态地生成Web页面。与传统的CGI和许多其它类似CGI的技术相比,Java Servlet具有更高的效率并更容易使用。对于Servlet,重复的请求不会导致同一程序的多次转载,它是依靠线程的方式来支持并发访问的。 · JSP JSP(Java Server Page)是一种实现普通静态HTML和动态页面输出混合编码的技术。从这一点来看,非常类似Microsoft ASP、PHP等技术。借助形式上的内容和外观表现的分离,Web页面制作的任务可以比较方便地划分给页面设计人员和程序员,并方便地通过JSP来合成。在运行时态,JSP将会被首先转换成Servlet,并以Servlet的形态编译运行,因此它的效率和功能与Servlet相比没有差别,一样具有很高的效率。 · EJB EJB定义了一组可重用的组件:Enterprise Beans。开发人员可以利用这些组件,像搭积木一样建立分布式应用。在装配组件时,所有的Enterprise Beans都需要配置到EJB服务器(一般的Weblogic、WebSphere等J2EE应用服务器都是EJB服务器)中。EJB服务器作为容器和低层平台的桥梁管理着EJB容器,并向该容器提供访问系统服务的能力。所有的EJB实例都运行在EJB容器中。EJB容器提供了系统级的服务,控制了EJB的生命周期。EJB容器为它的开发人员代管了诸如安全性、远程连接、生命周期管理及事务管理等技术环节,简化了商业逻辑的开发。EJB中定义了三种Enterprise Beans: ◆ Session Beans ◆ Entity Beans ◆ Message-driven Beans · JDBC JDBC(Java Database Connectivity,Java数据库连接)API是一个标准SQL(Structured Query Language,结构化查询语言)数据库访问接口,它使数据库开发人员能够用标准Java API编写数据库应用程序。JDBC API主要用来连接数据库和直接调用SQL命令执行各种SQL语句。利用JDBC API可以执行一般的SQL语句、动态SQL语句及带IN和OUT参数的存储过程。Java中的JDBC相当与Microsoft平台中的ODBC(Open Database Connectivity)。 · JMS JMS(Java Message Service,Java消息服务)是一组Java应用接口,它提供创建、发送、接收、读取消息的服务。JMS API定义了一组公共的应用程序接口和相应语法,使得Java应用能够和各种消息中间件进行通信,这些消息中间件包括IBM MQ-Series、Microsoft MSMQ及纯Java的SonicMQ。通过使用JMS API,开发人员无需掌握不同消息产品的使用方法,也可以使用统一的JMS API来操纵各种消息中间件。通过使用JMS,能够最大限度地提升消息应用的可移植性。 JMS既支持点对点的消息通信,也支持发布/订阅式的消息通信。 · JNDI 由于J2EE应用程序组件一般分布在不同的机器上,所以需要一种机制以便于组件客户使用者查找和引用组件及资源。在J2EE体系中,使用JNDI(Java Naming and Directory Interface)定位各种对象,这些对象包括EJB、数据库驱动、JDBC数据源及消息连接等。JNDI API为应用程序提供了一个统一的接口来完成标准的目录操作,如通过对象属性来查找和定位该对象。由于JNDI是独立于目录协议的,应用还可以使用JNDI访问各种特定的目录服务,如LDAP、NDS和DNS等。 · JTA JTA(Java Transaction API)提供了J2EE中处理事务的标准接口,它支持事务的开始、回滚和提交。同时在一般的J2EE平台上,总提供一个JTS(Java Transaction Service)作为标准的事务处理服务,开发人员可以使用JTA来使用JTS。 · JCA JCA(J2EE Connector Architecture)是J2EE体系架构的一部分,为开发人员提供了一套连接各种企业信息系统(EIS,包括ERP、SCM、CRM等)的体系架构,对于EIS开发商而言,它们只需要开发一套基于JCA的EIS连接适配器,开发人员就能够在任何的J2EE应用服务器中连接并使用它。基于JCA的连接适配器的实现,需要涉及J2EE中的事务管理、安全管理及连接管理等服务组件。 · JMX JMX(Java Management Extensions)的前身是JMAPI。JMX致力于解决分布式系统管理的问题。JMX是一种应用编程接口、可扩展对象和方法的集合体,可以跨越各种异构操作系统平台、系统体系结构和网络传输协议,开发无缝集成的面向系统、网络和服务的管理应用。JMX是一个完整的网络管理应用程序开发环境,它同时提供了厂商需要收集的完整的特性清单、可生成资源清单表格、图形化的用户接口;访问SNMP的网络API;主机间远程过程调用;数据库访问方法等。 · JAAS JAAS(Java Authentication and Authorization Service)实现了一个Java版本的标准Pluggable Authentication Module(PAM)的框架。JAAS可用来进行用户身份的鉴定,从而能够可靠并安全地确定谁在执行Java代码。同时JAAS还能通过对用户进行授权,实现基于用户的访问控制。 · JACC JACC(Java Authorization Service Provider Contract for Containers)在J2EE应用服务器和特定的授权认证服务器之间定义了一个连接的协约,以便将各种授权认证服务器插入到J2EE产品中去。 · JAX-RPC 通过使用JAX-RPC(Java API for XML-based RPC),已有的Java类或Java应用都能够被重新包装,并以Web Services的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API,使开发人员可以方便地使用SOAP消息来完成RPC调用。同样,对于那些使用EJB(Enterprise JavaBeans)的商业应用而言,同样可以使用JAX-RPC来包装成Web服务,而这个Web Servoce的WSDL界面是与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web服务的部署和实现,对Web服务的开发人员而言,SOAP/WSDL变得透明,这有利于加速Web服务的开发周期。 · JAXR JAXR(Java API for XML Registries)提供了与多种类型注册服务进行交互的API。JAXR运行客户端访问与JAXR规范相兼容的Web Servcices,这里的Web Services即为注册服务。一般来说,注册服务总是以Web Services的形式运行的。JAXR支持三种注册服务类型:JAXR Pluggable Provider、Registry-specific JAXR Provider、JAXR Bridge Provider(支持UDDI Registry和ebXML Registry/Repository等)。 · SAAJ SAAJ(SOAP with Attachemnts API for Java)是JAX-RPC的一个增强,为进行低层次的SOAP消息操纵提供了支持。 企业级应用示例 下面我们通过假设一个企业应用的J2EE实现,来了解各种组件和服务的应用。假设应用对象是计算机产品的生产商/零售商的销售系统,这个销售系统能够通过自己的网站发布产品信息,同时也能将产品目录传送给计算机产品交易市场。销售系统能够在线接受订单(来自自己的Web网站或者来自计算机产品交易市场),并随后转入内部企业管理系统进行相关的后续处理。 参见图3,这个企业应用可以这种方式架构。该企业应用的核心是产品目录管理和产品定购管理这两个业务逻辑,使用EJB加以实现,并部署在EJB容器中。由于产品目录和定购信息都需要持久化,因此使用JDBC连接数据库,并使用JTA来完成数据库存取事务。 图3 J2EE应用示例 然后使用JSP/Servlet来实现应用的Web表现:在线产品目录浏览和在线定购。为了将产品目录发送给特定的交易市场,使用JMS实现异步的基于消息的产品目录传输。为了使得更多的其它外部交易市场能够集成产品目录和定购业务,需要使用Web Services技术包装商业逻辑的实现。由于产品定购管理需要由公司内部雇员进行处理,因此需要集成公司内部的用户系统和访问控制服务以方便雇员的使用,使用JACC集成内部的访问控制服务,使用JNDI集成内部的用户目录,并使用JAAS进行访问控制。由于产品订购事务会触发后续的企业ERP系统的相关操作(包括仓储、财务、生产等),需要使用JCA连接企业ERP。 最后为了将这个应用纳入到企业整体的系统管理体系中去,使用Application Client架构了一个管理客户端(与其它企业应用管理应用部署在一台机器上),并通过JMX管理这个企业应用。 |
ERP
所谓ERP是英文Enterprise Resource Planning(企业资源计划)的简写。
是指建立在信息技术基础上,以系统化的管理思想,为企业决策层及员工提供决策运行手段的管理平台。ERP系统集中信息技术与先进的管理思想於一身,成为现代企业的运行模式,反映时代对企业合理调配资源,最大化地创造社会财富的要求,成为企业在信息时代生存、发展的基石。 Gartner Group提出ERP具备的功能标准应包括四个方面: 1.超越MRPⅡ范围的集成功能 包括质量管理;试验室管理;流程作业管理;配方管理;产品数据管理;维护管理;管制报告和仓库管理。 2.支持混合方式的制造环境 包括既可支持离散又可支持流程的制造环境;按照面向对象的业务模型组合业务过程的能力和国际范围内的应用。 3.支持能动的监控能力,提高业务绩效 包括在整个企业内采用控制和工程方法;模拟功能;决策支持和用于生产及分析的图形能力。 4.支持开放的客户机/服务器计算环境 包括客户机/服务器体系结构;图形用户界面(GUI);计算机辅助设计工程(CASE),面向对象技术;使用SQL对关系数据库查询;内部集成 的工程系统、商业系统、数据采集和外部集成 (EDI)。 ERP是对MRPⅡ的超越,从本质上看,ERP仍然是以MRPⅡ为核心,但在功能和技术上却超越了传统的MRPⅡ,它是以顾客驱动的、基于时 间的、面向整个供应链管理的企业资源计划。 进一步地,我们可以从管理思想、软件产品、管理系统三个层次给出它的定义: 1.是由美国著名的计算机技术咨询和评估集团Garter Group Inc.提出的一整套企业管理系统体系标准,其实质是在MRP II(Manufacturing Resources Planning,“制造资源计划”) 基础上进一步发展而成的面向供应链(Supply Chain)的管理思想; 2.是综合应用了客户机/服务器体系、关系数据库结构、面向对象技术、图形用户界面、第四代语言(4GL)、网络通讯等信息产业成果,以ERP管理思想为灵魂的软件产品; 3.是整合了企业管理理念、业务流程、基础数据、人力物力、计算机硬件和软件于一体的企业资源管理系统。 它是从MRP(物料资源计划)发展而来的新一代集成化管理信息系统,它扩展了MRP的功能,其核心思想是供应链管理,它跳出了传统企业边界,从供应链范围去优化企业的资源,是基于网络经济时代的新一代信息系统。它对于改善企业业务流程、提高企业核心竞争力的作用是显而易见的。ERP是在20世纪80年代初开始出现的。从90年代开始,以SAP、Oracle为代表的国际著名ERP产品进入中国,并迅速扩展。接着,国内也相继出现了一些早期ERP产品,例如开思ERP、利玛ERP、和佳ERP及博科ERP等。 ERP系统的特点及核心内容包括有: •企业内部管理所需的业务应用系统,主要是指财务、物流、人力资源等核心模块。 •物流管理系统采用了制造业的MRP管理思想;FMIS有效地实现了预算管理、业务评估、管理会计、ABC成本归集方法等现代基本财务管理方法;人力资源管理系统在组织机构设计、岗位管理、薪酬体系以及人力资源开发等方面同样集成了先进的理念。 •ERP系统是一个在全公司范围内应用的、高度集成的系统。数据在各业务系统之间高度共享,所有源数据只需在某一个系统中输入一次,保证了数据的一致性。 •对公司内部业务流程和管理过程进行了优化,主要的业务流程实现了自动化。 •采用了计算机最新的主流技术和体系结构:B/S、INTERNET体系结构,WINDOWS界面。在能通信的地方都可以方便地接入到系统中来。 •集成性、先进性、统一性、完整性、开放性。 具体来讲,ERP与企业资源的关系、ERP的作用以及与信息技术的发展的关系等可以表述如下: 1. 企业资源与ERP 厂房、生产线、加工设备、检测设备、运输工具等都是企业的硬件资源,人力、管理、信誉、融资能力、组织结构、员工的劳动热情等就是企业的软件资源。企业运行发展中,这些资源相互作用,形成企业进行生产活动、完成客户订单、创造社会财富、实现企业价值的基础,反映企业在竞争发展中的地位。 ERP系统的管理对象便是上述各种资源及生产要素,通过ERP的使用,使企业的生产过程能及时、高质地完成客户的订单,最大程度地发挥这些资源的作用,并根据客户订单及生产状况做出调整资源的决策。 2. 调整运用企业资源 企业发展的重要标志便是合理调整和运用上述的资源,在没有ERP这样的现代化管理工具时,企业资源状况及调整方向不清楚,要做调整安排是相当困难的,调整过程会相当漫长,企业的组织结构只能是金字塔形的,部门间的协作交流相对较弱,资源的运行难於比较把握,并做出调整。信息技术的发展,特别是针对企业资源进行管理而设计的ERP系统正是针对这些问题设计的,成功推行的结果必使企业能更好地运用资源。 3. 信息技术对资源管理作用的阶段发展过程 计算机技术特别是数据库技术的发展为企业建立管理信息系统,甚至对改变管理思想起著不可估量的作用,管理思想的发展与信息技术的发展是互成因果的环路。而实践证明信息技术已在企业的管理层面扮演越来越重要的角色。 信息技术最初在管理上的运用,也是十分简单的,主要是记录一些数据,方便查询和汇总,而现在发展到建立在全球Internet基础上的跨国家,跨企业的运行体系,初略可分作如下阶段: A. MIS系统阶段( Management Information System) 企业的信息管理系统主要是记录大量原始数据、支持查询、汇总等方面的工作。 B. MRP阶段(Material Require Planning) 企业的信息管理系统对产品构成进行管理,借助计算机的运算能力及系统对客户订单、在库物料、产品构成的管理能力,实现依据客户订单,按照产品结构清单展开并计算物料需求计划。实现减少库存,优化库存的管理目标。 C. MRPⅡ阶段(Manufacture Resource Planning) 在MRP管理系统的基础上,系统增加了对企业生产中心、加工工时、生产能力等方面的管理,以实现计算机进行生产排程的功能,同时也将财务的功能囊括进来,在企业中形成以计算机为核心的闭环管理系统,这种管理系统已能动态监察到产、供、销的全部生产过程。 D. ERP阶段(Enterprise Resource Planning) 进入ERP阶段后,以计算机为核心的企业级的管理系统更为成熟,系统增加了包括财务预测、生产能力、调整资源调度等方面的功能。配合企业实现JIT管理全面、质量管理和生产资源调度管理及辅助决策的功能。成为企业进行生产管理及决策的平台工具。 E. 电子商务时代的ERP Internet技术的成熟为企业信息管理系统增加与客户或供应商实现信息共享和直接的数据交换的能力,从而强化了企业间的联系,形成共同发展的生存链,体现企业为达到生存竞争的供应链管理思想。ERP系统相应实现这方面的功能,使决策者及业务部门实现跨企业的联合作战。 由此可见,ERP的应用的确可以有效地促进现有企业管理的现代化、科学化,适应竞争日益激烈的市场要求,它的导入,已经成为大势所趋。 F: 无产阶级时代的ERP 将整个国家纳入统筹的ERP,将形成一门新的社会主义计划经济学。 G:现时代的ERP 现时代的ERP,紧紧抓住企业信息流程这条主线,以生产经营为目的,提供专业性非常强的针对行业的ERP。 这种ERP的出现为中国各个行业的ERP建设做出了积极的贡献。像开龙IT2000 ERP,商软ERP等ERP。都是现时代ERP的典故。 举个例子说明: 一天中午,丈夫在外给家里打电话:“亲爱的老婆,晚上我想带几个同事回家吃饭可以吗?”(订货意向) 妻子:“当然可以,来几个人,几点来,想吃什么菜?” 丈夫:“6个人,我们7点左右回来,准备些酒、烤鸭、番茄炒蛋、凉菜、蛋花汤……。你看可以吗?”(商务沟通) 妻子:“没问题,我会准备好的。”(订单确认) 妻子记录下需要做的菜单(MPS计划),具体要准备的东西:鸭、酒、番茄、鸡蛋、调料……(BOM物料清单),发现需要:1只鸭蛋,5瓶酒,4个鸡蛋……(BOM展开),炒蛋需要6个鸡蛋,蛋花汤需要4个鸡蛋(共用物料)。 打开冰箱一看(库房),只剩下2个鸡蛋(缺料)。 来到自由市场,妻子:“请问鸡蛋怎么卖?”(采购询价) 小贩:“1个1元,半打5元,1打9.5元。” 妻子:“我只需要8个,但这次买1打。”(经济批量采购) 妻子:“这有一个坏的,换一个。”(验收、退料、换料) 回到家中,准备洗菜、切菜、炒菜……(工艺线路),厨房中有燃气灶、微波炉、电饭煲……(工作中心)。 妻子发现拨鸭毛最费时间(瓶颈工序,关键工艺路线),用微波炉自己做烤鸭可能来不及(产能不足),于是在楼下的餐厅里买现成的(产品委外)。 下午4点,接到儿子的电话:“妈妈,晚上几个同学想来家里吃饭,你帮忙准备一下。”(紧急订单) “好的,你们想吃什么,爸爸晚上也有客人,你愿意和他们一起吃吗?” “菜你看着办吧,但一定要有番茄炒鸡蛋,我们不和大人一起吃,6:30左右回来。”(不能并单处理) “好的,肯定让你们满意。”(订单确定) “鸡蛋又不够了,打电话叫小店送来。”(紧急采购) 6:30,一切准备就绪,可烤鸭还没送来,急忙打电话询问:“我是李太,怎么订的烤鸭还不送来?”(采购委外单跟催) “不好意思,送货的人已经走了,可能是堵车吧,马上就会到的。” 门铃响了。 “李太太,这是您要的烤鸭。请在单上签一个字。”(验收、入库、转应付账款) 6:45,女儿的电话:“妈妈,我想现在带几个朋友回家吃饭可以吗?”(呵呵,又是紧急订购意向,要求现货) “不行呀,女儿,今天妈已经需要准备两桌饭了,时间实在是来不及,真的非常抱歉,下次早点说,一定给你们准备好。”(哈哈,这就是ERP的使用局限,要有稳定的外部环境,要有一个起码的提前期)。 送走了所有客人,疲惫的妻子坐在沙发上对丈夫说:“亲爱的,现在咱们家请客的频率非常高,应该要买些厨房用品了(设备采购),最好能再雇个小保姆(连人力资源系统也有缺口了)。 丈夫:“家里你做主,需要什么你就去办吧。”(通过审核) 妻子:“还有,最近家里花销太大,用你的私房钱来补贴一下,好吗?”(最后就是应收货款的催要) 记住,每一个合格的家庭主妇都是生产厂长的有力竞争者。 |
SOA
面向服务的体系结构(Service-Oriented Architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。而另一方面,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务,在按需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。 虽然面向服务的体系结构不是一个新鲜事物,但它却是更传统的面向对象的模型的替代模型,面向对象的模型是紧耦合的,已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务,但是其整体设计却是面向服务的。由于它考虑到了系统内的对象,所以虽然 SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构(Common Object Request Broker Architecture,CORBA),它已经出现很长时间了,其定义的概念与 SOA 相似。 然而,现在的 SOA 已经有所不同了,因为它依赖于一些更新的进展,这些进展是以可扩展标记语言(eXtensible Markup Language,XML)为基础的。通过使用基于 XML 的语言(称为 Web 服务描述语言(Web Services Definition Language,WSDL))来描述接口,服务已经转到更动态且更灵活的接口系统中,非以前 CORBA 中的接口描述语言(Interface Definition Language,IDL)可比了。 Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式,这样就有了面向消息的中间件(Message-Oriented Middleware)系统,比如 IBM 的 MQseries。但是为了建立体系结构模型,您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此,SOA 应该能够将业务的商业流程与它们的技术流程联系起来,并且映射这两者之间的关系。例如,给供应商付款的操作是商业流程,而更新您的零件数据库,以包括进新供应的货物却是技术流程。因而,工作流还可以在 SOA 的设计中扮演重要的角色。 此外,动态业务的工作流不仅可以包括部门之间的操作,甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此,为了提高效率,您需要定义应该如何得知服务之间的关系的策略,这种策略常常采用服务级协定和操作策略的形式。 最后,所有这些都必须处于一个信任和可靠的环境之中,以同预期的一样根据约定的条款来执行流程。因此,安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。 我可以用面向服务的体系结构做什么? 对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活,以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现,IT 系统既可以利用现有系统的功能,又可以准备在以后做一些改变来满足它们之间交互的需要。 下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店,它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色,甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容,那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性,每个公司都可以将它们的现有系统保持现状,而仅仅匹配 WSDL 接口并制订新的服务级协定,这样就不必完全重构它们的软件系统了。这是业务的水平改变,也就是说,它们改变的是合作伙伴,而所有的业务操作基本上都保持不变。这里,业务接口可以作少许改变,而内部操作却不需要改变,之所以这样做,仅仅是为了能够与外部合作伙伴一起工作。 另一种形式是内部改变,在这种改变中,零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店,这可以看作是采用店中店(store-in-store)的业务模型。这里,虽然公司的大多数业务操作都保持不变,但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修,但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下,SOA 模型保持原封不动,而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责,但是正常的零售管理系统继续如往常一样。 为了延续内部改变的观念,IT 经理可能会发现,软件的新配置还可以以另外的一种方式加以使用,比如出租粘贴海报的地方以供广告之用。这里,新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果,并且还是一个新的机会,而这样的新机会在以前可能是不会有的。 垂直改变也是可能的,在这种改变中,零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话,就会带来 SOA 模型结构的显著改变,与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下,SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题,这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式,而不是在许多现有的软件平台上常常看到的其他方式。 正如您可以看到的,在这里,改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说,这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生,这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是,架构师的作用就是引起对 SOA 模型大的改变。这种分工,就是让开发人员集中精力于创建作为服务定义的功能单元,而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起,它已经有十多年的历史了,通常用统一建模语言(Universal Modeling Language,UML),并且描述成模型驱动的体系结构(Model-Driven Architecture,MDA)。 对于面向同步和异步应用的,基于请求/响应模式的分布式计算来说,SOA是一场革命。一个应用程序的业务逻辑(business logic)或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如,服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用,而无须理解服务的底层实现。举例来说,一个服务可以用。NET或J2EE来实现,而使用该服务的应用程序可以在不同的平台之上,使用的语言也可以不同。 SOA有以下特性 SOA服务具有平台独立的自我描述XML文档。Web服务描述语言(WSDL, Web Services Description Language)是用于描述服务的标准语言。 SOA 服务用消息进行通信,该消息通常使用XML Schema来定义(也叫做XSD, XML Schema Definition)。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。 在一个企业内部,SOA服务通过一个扮演目录列表(directory listing)角色的登记处(Registry)来进行维护。应用程序在登记处(Registry)寻找并调用某项服务。统一描述,定义和集成(UDDI, Universal Description, Definition, and Integration)是服务登记的标准。 每项SOA服务都有一个与之相关的服务品质(QoS, quality of service)。QoS的一些关键元素有安全需求(例如认证和授权),可靠通信(译注:可靠消息是指,确保消息“仅且仅仅”发送一次,从而过滤重复信息。),以及谁能调用服务的策略。 为什么选择SOA? 不同种类的操作系统,应用软件,系统软件和应用基础结构(application infrastructure)相互交织,这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程(business processes),因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应,利用对现有的应用程序和应用基础结构(application infrastructure)的投资来解决新的业务需求,为客户,商业伙伴以及供应商提供新的互动渠道,并呈现一个可以支持有机业务(organic business)的构架。SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新服务或更新现有服务,以解决新的业务需要,提供选择从而可以通过不同的渠道提供服务,并可以把企业现有的或已有的应用作为服务, 从而保护了现有的IT基础建设投资。 如图1的例子所示,一个使用SOA的企业,可以使用一组现有的应用来创建一个供应链复合应用(supply chain composite application),这些现有的应用通过标准接口来提供功能。 服务架构 为了实现SOA,企业需要一个服务架构,图2显示了一个例子: 在图2中, 服务消费者(service consumer)可以通过发送消息来调用服务。这些消息由一个服务总线(service bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎(business rules engine),该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(service management infrastructure),用来管理服务,类似审核,列表(billing),日志等功能。此外,该架构给企业提供了灵活的业务流程,更好地处理控制请求(regulatory requirement),例如Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。 SOA基础结构 要运行,管理SOA应用程序,企业需要SOA基础,这是SOA平台的一个部分。SOA基础必须支持所有的相关标准,和需要的运行时容器。图3所示的是一个典型的SOA基础结构。 SOAP, WSDL, UDDI WSDL,UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP,作为传输层,用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制,其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表(registry)查找服务,取得服务的WSDL描述,然后通过SOAP来调用服务。 WS-I Basic Profile WS-I Basic Profile,由Web服务互用性组织(Web Services Interoperability Organization)提供,是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。 J2EE 和 .Net 尽管J2EE和。NET平台是开发SOA应用程序常用的平台,但SOA不仅限于此。像J2EE这类平台,不仅为开发者自然而然地参与到SOA中来提供了一个平台,还通过他们内在的特性,将可扩展性,可靠性,可用性以及性能引入了SOA世界。新的规范,例如 JAXB(Java API for XML Binding),用于将XML文档定位到Java类;JAXR(Java API for XML Registry)用来规范对UDDI注册表(registry)的操作;XML-RPC(Java API for XML-based Remote Procedure Call)在J2EE1.4中用来调用远程服务,这使得开发和部署可移植于标准J2EE容器的Web服务变得容易,与此同时,实现了跨平台(如。NET)的服务互用。 服务品质 在企业中,关键任务系统(mission-critical system,译注:关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的,那么该系统就是该企业的关键任务系统。比如,电话系统对于一个电话促销企业来说就是关键任务系统,而文字处理系统就不那么关键了。)用来解决高级需求,例如安全性,可靠性,事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候,基本的Web服务规范,像WSDL,SOAP,以及UDDI就不能满足这些高级需求。正如前面所提到的,这些需求也称作服务品质(QoS,quality of services)。与QoS相关的众多规范已经由一些标准化组织(standards bodies)提出,像W3C(World Wide Web Consortium)和OASIS(the Organization for the Advancement of Structured Information Standards)。下面的部分将会讨论一些QoS服务和相关标准。 安全 Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换, 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准,例如,SAML(as Security Assertion Markup Language)来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。 可靠 在典型的SOA 环境中,服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”( once-and-only-once delivery),“最多传送一次”( at-most-once delivery),“重复消息过滤”(duplicate message elimination),“保证消息传送”(guaranteed message delivery)等特性消息的发送和确认,在关键任务系统(mission-critical systems)中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。 策略 服务提供者有时候会要求服务消费者与某种策略通信。比如,服务提供商可能会要求消费者提供Kerberos安全标示,才能取得某项服务。这些要求被定义为策略断言(policy assertions)。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。 控制 当企业着手于服务架构时,服务可以用来整合数据仓库(silos of data),应用程序,以及组件。整合应用意味着例如异步通信,并行处理,数据转换,以及校正等进程请求必须被标准化。在SOA中,进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL(Web Service Business Process Execution Language)是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。 管理 随着企业服务的增长,所使用的服务和业务进程的数量也随之增加,一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM(Web Services for Distributed Management)规定了任何根据WSDM实现的服务都可以由一个WSDM适应(WSDM-compliant)的管理方案来管理。 其它的qos特性,比如合作方之间的沟通和通讯,多个服务之间的事务处理,都在WS-Coordination 和 WS-Transaction 标准中描述, 这些都是OASIS 的工作。 SOA 不是Web服务 在理解SOA和Web服务的关系上,经常发生混淆。根据2003年4月的Gartner报道,Yefim V. Natis就这个问题是这样解释的:“Web服务是技术规范,而SOA是设计原则。特别是Web服务中的WSDL,是一个SOA配套的接口定义标准:这是Web服务和SOA的根本联系。”从本质上来说,SOA是一种架构模式,而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台,来获得服务,而且随着越来越多的软件商支持越来越多的Web服务规范,你会取得更好的通用性。 SOA的优势 SOA的概念并非什么新东西,SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准,为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用;SOA能够使客户或服务消费者免予服务实现的改变所带来的影响;SOA能够升级单个服务或服务消费者而无需重写整个应用,也无需保留已经不再适用于新需求的现有系统。总而言之,SOA以借助现有的应用来组合产生新服务的敏捷方式,提供给企业更好的灵活性来构建应用程序和业务流程。 |
开放分类:
电脑系统 1.About the author 2. Raghu R. Kodali is consulting product manager and SOA evangelist for Oracle Application Server. Kodali leads next-generation SOA initiatives and J2EE feature sets for Oracle Application Server, with particular expertise in EJB, J2EE deployment, Web services, and BPEL. Prior to product management, Kodali held presales and technical marketing positions in Oracle Asia-Pacific, based in Singapore. Prior to Oracle, he worked as software developer with National Computer Systems, Singapore. He holds a master's degree in computer science and is a frequent speaker at technology conferences. Kodali maintains an active blog at Loosely Coupled Corner |