面向服务架构中的改进和与面向服务构架有关的改进的制作方法

专利名称：：面向服务架构中的改进和与面向服务构架有关的改进的制作方法
技术领域：
：本发明涉及分布式网络，更具体地说，涉及但不限于对具有面向服务架构的分布式网络中的系统管理的改进。
背景技术：
：术语面向系统架构在计算中用于表述一种软件架构概念，其定义对服务的规定和使用来支持软件使用者的需求。在SOA中，在开发者可以访问的网络上可以获得离散的、独立的服务，以允许开发者通过对SOA服务的组合来创建软件解决方案。在其他架构中，软件解决方案被设计为专用(applicationspecific),并且设计和实施软件系统来为客户满足特定范围的任务。例如，在组织具有若干分离业务，各分离业务具有特定计算要求的情况下，各分离业务将开发专门编写的应用程序来满足所述要求。显然，在许多组织中，不同应用程序上包含的功能可能相同或者相似，存在大量冗余，因为该功能存在于若干应用程序上。进一步，应用程序的设计及其处理数据的方法可能是高度专用的，数据可能被以针对该应用程序的特定方式格式化。SOA的实施将在理论上避免这种冗余，因为业务服务可以在整个组织中为客户所获得。这些服务不会是专用的，但是会被设计为由所有客户使用。显然，SOA将非常有益，因为其允许对软件业务过程和所谓的复合应用程序进行快速构造和改写；业务服务功能将作为自治服务传递；服务将彼此独立并且独立于任何特殊的实施策略。然而，实施SOA的尝试具有若干问题。SOA的实施要求整个组织的高度标准化以便服务可以容易地被使用。因此，习惯于具有被设计为满足特定应用程序需要的软件的组织将被要求改变其方式。这要求实施用于设计面向SOA的软件的规则和程序。此外，在大型组织中，提高SOA的比例表现出对交互进行追踪的问题和收集与使用服务的方式有关的信息的问题。
发明内容本发明的目的在用于提供一种改进的实施面向服务架构(SOA)的系统。本发明提供用于运行一个以上软件应用程序的计算机系统，该计算机系统具有至少一个节点，并且包括至少一个业务服务软件应用程序，这些业务服务软件应用程序可以被组合在一起以提供业务功能，并且适于操作SOA。优选地，SOA提供软件框架以支撑所述业务服务软件应用程序，所述业务服务软件应用程序是可重用的。根据本发明的第一方面，提供了一种具有面向服务架构的计算机系统，其适于运行至少一个业务服务应用程序，该计算机系统包括至少一个信道依赖的客户层；至少一个信道独立的服务层；和综合层，其包括用于从所述至少一个客户层接收服务请求消息的请求接收装置、适于将该服务请求消息发送到所述至少一个服务层的消息路由器，该服务层适于读取所述请求消息，并且作为响应，运行所述业务服务应用程序。优选地，所述客户层包括表现层，该表现层具有用于向端用户表现信息的处理装置和逻辑。优选地，所述表现层对所述正在被构建的应用程序而言是特定的，对已被选择向端用户传送该应用程序的信道或平台而言也是特定的。优选地，所述客户层还包括应用程序控制层。优选地，所述服务层具有业务服务层。优选地，所述服务层具有数据服务层。优选地，所述应用程序控制层作为针对所述业务服务层中的业务服务的控制部件。优选地，所述表现层能够通过发送数据请求给所述应用程序控制层来选择性地调用所述应用程序控制层的部件。优选地，所述应用程序控制层确定哪个业务服务被要求来满足所述请求。优选地，所述业务服务层适于提供一般的业务功能。优选地，所述业务服务层中的业务服务被设计为可重用的。优选地，所述服务层被设计为可重用的。优选地，所述业务服务由至少一个数据服务组成。优选地，在所述客户层和所述服务层之间分割对来自所述客户层的请求进行的端到端处理。优选地，其中所述综合层将服务的名称映射到业务服务的名称和版本，并且将该消息路由到一队列。优选地，所述综合层使用业务服务名称和版本作为关键字访问一业务服务目录。优选地，所述综合层进一步包括一消息队列。优选地，所述业务服务层适于从所述消息队列读取所述请求消息，并且作为响应，运行该业务服务应用程序。优选地，在所述消息队列中所述请求消息的到达触发调用被请求服务的业务服务框架代码。优选地，所述业务服务层产生答复消息，并将其发送到答复消息队列。优选地，所述答复消息所发送到的答复消息队列在所述请求消息中指定。优选地，所述综合层读取所述的答复消息。优选地，所述综合层向所述应用程序控制层返回所述答复消息。优选地，所述应用程序控制层处理所述业务服务答复并且返回数据以备在所述表现层中呈现。优选地，由所述消息发生器生成的所述请求消息包括一使得可穿过该系统路由所述消息的首标。优选地，所述消息首标使得用户和系统定义的上下文信息可穿过该系统流动。优选地，所述消息首标向所述消息提供唯一的标识符，该标识符允许关于该消息的信息在逻辑控制间流动。优选地，所述消息具有会话ID,该会话ID提供关于用户会话的信息，所述消息在该会话中执行。优选地，所述消息具有上下文链标识符，该标识符使得该消息在消息链中的位置得以被识别。优选地，所述消息具有包含请求数据的有效载荷。优选地，所述请求数据包括可以传送到所述业务服务的输入参数。优选地，该系统进一步包括系统管理器。优选地，所述系统管理器包括一日志机构，其用于探测与系统活动有关的曰志事件。所述日志机构提供对SOA中的部件如何交互，即哪个应用程序正在调用哪个业务服务，进行日志记录的能力。优选地，当所述请求消息在穿过系统中的层流动时，所述日志机构根据请求消息发送多个事件。优选地，所述事件发送可以被动态地调高或调低，以便使得可以改变所生成的日志量。优选地，所述日志事件被捕获并保留在中心数据库中以备后续的查询。优选地，所述日志机构适于对系统和SOA的部件间交互进行日志记录。这样就可以确定哪个应用程序调用哪个业务服务。优选地，所述日志机构提供应用程序性能监视。优选地，所述日志机构提供容量/能力监视。优选地，所述日志机构提供与绝对数目和/或吞吐量趋势和/或并发信息有关的信息。优选地，所述日志机构具有用于分析日志数据的分析工具。优选地，所述分析工具具有图形用户界面，所述图形用户界面图形化地表现所述日志数据。优选地，所述日志机构是可配置的，从而使得可以对不同的事件类型进行日志记录。优选地，所述日志机构收集应用程序专用审核和管理信息。优选地，根据本发明的第二方面，提供了一种用于操作面向服务架构的方法，该方法包括以下步骤从至少一个客户层向综合层发送服务请求消息，通过所述综合层将所述服务请求消息路由到至少一个服务层，该服务层适于读取所述请求消息，并且作为响应，运行一业务服务应用程序。优选地，所述客户层包括表现层，该表现层具有用于向端用户表现信息的处理装置和逻辑。优选地，所述客户层包括应用程序控制层。优选地，所述服务层具有业务服务层。优选地，所述服务层具有数据服务层。优选地，所述应用程序控制层控制所述业务服务层中的业务服务。优选地，所述应用程序控制层确定哪个业务服务被要求来满足所述服务请求。优选地，所述表现层能够通过发送数据请求给所述应用程序控制层来选择性地调用所述应用程序控制层的部件。优选地，在所述客户层和所述服务层之间分割对来自所述客户层的服务请求进行的端到端处理。48、根据权利要求39到47所述的方法，所述综合层使用业务服务名称和版本作为关键字访问一业务服务目录。优选地，所述业务服务层适于从所述消息队列读取所述请求消息，并且作为响应，运行该业务服务应用程序。优选地，在所述消息队列中所述请求消息的到达触发调用被请求服务的业务服务框架代码。优选地，所述业务服务层产生答复消息，并将其发送到答复消息队列。优选地，所述答复消息所发送到的答复消息队列在所述请求消息中指定。优选地，所述应用程序控制层处理所述业务服务答复消息并且返回数据以备在所述表现层中呈现。优选地，由所述消息发生器生成的所述请求消息包括一使得可穿过该系统路由所述消息的首标。优选地，所述消息首标使得用户和系统定义的上下文信息可穿过系统流动。优选地，所述消息首标向所述消息提供唯一的标识符，该标识符允许关于该消息的信息在逻辑控制间流动。优选地，所述消息具有会话ID，该会话ID提供关于用户会话的信息，所述消息在该会话中执行。优选地，所述消息具有上下文链标识符，该标识符使得该消息在消息链中的位置得以被识别。优选地，所述消息具有包含请求数据的有效载荷。优选地，对与系统活动有关的事件进行日志记录。优选地，当所述请求消息在穿过系统中的层流动时，根据请求消息发送至少一个事件。优选地，所述事件发送可以被动态地调高或调低，以便使得可以改变所生成的日志量。优选地，所述日志事件被捕获并保留在中心数据库中以备后续的查询。优选地，所述日志机构是可配置的，从而使得可以对不同的事件类型进4亍日志"i己录。优选地，所述日志机构收集诸如应用程序专用审核和管理信息的事件类型。优选地，一图形用户界面表现一个以上不同的事件类型。优选地，至少一个事件类型被显示在与另一个事件类型相分离的窗口中。优选地，事件类型数据包括在系统中并发的请求的平均数目。优选地，事件类型数据包括响应时间数据。现在通过仅仅例子的方式，参照附图描述本发明，在附图中图1是示出根据本发明所使用的层和实施技术的示意图2是示出根据本发明的SOA中的层间关系的方框图3是示出根据本发明的在SOA中重用业务服务的方式的方框图4是示出根据本发明的业务服务和数据服务之间的关系的方框图5示出根据本发明的由数据服务提供的业务服务；图6是示出是示出根据本发明的系统的操作的流程图7是示出用于本发明的消息结构的示意图8示出根据本发明的日志机构的例子；图9示出在根据本发明的使用SOA进行的交易期间的日志事件；图10示出对从根据本发明的系统提取的日志信息进行显示的图形用户界面；图11示出根据本发明的提供部件交互信息的图形用户界面。具体实施例方式SOA应用程序建立于公共的程序框架和基础构造之上，其导致与代码和运行时能力一致的高度信任。这一方式避免拥有一套具有显著不同特性的应用程序。本发明提供一种SOA，在其中信道依赖服务和信道独立服务由综合层链接起来。所述综合层详细地识別信道依赖客户层所要求的业务服务的类型，并且创建一个以上包含允许信道独立业务服务提供这些服务所必需的信息的消息。在与可缩放日志机构结合时，对这些消息的创建和使用可以提供对系统的更加有效的管理。根据本发明所设计的SOA允许端到端处理被分割到若干层。图1是根据本发明的SOA系统的示意性表现，该SOA系统具有客户43、综合层51、信道独立业务服务53、系统管理61,外部客户63作为存在于SOA框架之外的客户。还示出了业务服务目录55。信道依赖客户43包括表现层45、应用程序控制层47和信道网管49。综合层51提供允许客户调用业务服务的功能。业务服务功能53包括业务服务层57和数据服务层59。系统管理层61用于通过收集关于系统中各种功能的信息和对业务服务的使用进行日志记录来管理整个系统。图2是本发明的作为替换的表现，其中示出了本发明的分层结构。表现(GUI)层70具有用于向端用户表现信息的处理和逻辑，并且对于正在被构建的应用程序而言是特定的，从而对于已经被选择来向使用者传递系统的信道(平台)而言是特定的。这样，表现层45以预定的适合于显示的方式呈现由业务服务层提供的信息。应用程序控制层(ACL)72对于正在被构建的应用程序而言也是特定的，因为该层承担为该应用程序控制部件。ACL由GUI部件以适于使得应用程序能够产生所需结果的方式调用。这也是信道依赖的。业务服务层74独立于应用程序。因此，当对业务服务功能的原始要求从应用程序发起时，该要求已经被增强为针对更加一般的业务功能，并且以其他应用程序可以在没有跨平台问题的情况下使用的方式被部署。本发明允许在业务服务层74进行重用，使得新的应用程序通过重用关键的根本业务服务来被构建。业务服务软件应用程序被通过综合层51经由应用程序控制层47传送到客户43。业务服务软件应用程序可以被定义为可重用的、信道独立的、面向业务的、粗略的部件，该部件进行特定的业务目的，例如改变地址、创建工作流对象或者提供分布信息。信道独立意味着业务服务软件应用程序可以从多个信道调用；可以从业务规则和逻辑与数据服务的组合构建；其本身不需要进行任何直接的运行数据访问；可以被构建为满足特定的业务服务需要，而不是特定的图形用户界面(GUI)需要；可以在多个数据访问应用程序上运行；可以反映业务数据或过程(非用户界面)；并且可以包括业务逻辑(例如，计算)。数据服务是物理地访问根本运行数据的部件。数据服务可以被设计为可重用部件，取决于开发项目希望如何构造其部件。在这一级别的重用不是最为重要的，因为业务服务层才会通常通过所公布的业务功能提供到数据的接口。综合层(REF)在本发明的信道依赖和信道独立层之间路由信息。其运行的方式将在下面详细描述。图3示出类似于图2所示的分层结构，并且示出了3个在图1中也示出的分离的软件应用程序或客户的表现层(80A、80B、和80C)和应用程序控制层(82A、82B和82C)。每个软件应用程序和客户具有不同的功能，但是使用某些共同的业务服务来实现其功能。还示出了业务服务层84和数据服务层86。在本发明一个例子中，定义了以下业务服务。ChangeAddress■ProvideCustomerlnformationGetSurrenderValue这些业务服务是信道独立的并且进行那些被设计为以"现成"的方式重用的业务功能。在第一次定义业务功能时，重用要求额外的开销来确保对处理的原始要求满足使得可以由其他的重用的规范。因此，开发应用程序的初始成本可能比專交大。虽然开发本发明SOA系统成本可能在初始时较高，但是重用业务服务的能力提供了更大的长时间效率和更低的成本。因此，如果接受了小开销并创建了服务业务，未来的项目将受益于对时间和资源的节约，因为大量的功能已经可以得到。随着时间推移，增长的对服务的重用将减少开发成本。图4示出业务服务和数据服务之间的关系。在本例中，软件应用程序或客户涉及财务产品策略和税务信息。称为"Providecontributioninfo"的业务服务92直接链接到三个数据服务——称为"GetContributions"的数据服务94、称为"GetBenefits"的数据服务96和称为"ContractData"的数据月l务98。"GetContractData"数据服务98自身链接到对外的称为"GetPolicyData"的数据服务100。本发明的SOA清晰地区分业务服务层和数据服务层。业务服务层可以是数据服务的集合-即一个业务服务由许多数据服务组成-并且业务服务层作用于从许多数据服务返回的数据。可能已有的数据服务将提供嚢括整个服务业务的功能，如图5所示。在本例中，CreateQuote104是现有的服务，其可以被视作业务服务。在这种情况下，写入了包装数据服务的业务服务，其提供了信道独立的、标准化的到数据服务的业务服务接口。期望仅仅对于现有服务才需要以这样的方式包装大的数据服务。新的服务将作为第一实例中的业务服务被写入。参照图6提供根据本发明的系统的运行的例子。图6涉及由端用户对系统的操作。表现层110将对数据的请求发送到应用程序控制层112。生成、存储请求标识并用该请求标识来将所有与该请求有关的日志消息关联起来。应用程序控制层112确定要求哪个业务服务来满足该请求。对服务的请求被传递到综合层的业务服务调用框架114。在该点，综合层的调用框架114仅仅知道逻辑上的业务服务名。调用框架使用该逻辑名作为关键字来访问查找配置文件112。这是提供待使用业务服务的全企业名称和版本的专用资源。调用框架114现在可以使用该业务服务名称和版本作为关键字来访问业务服务目录124。业务服务目录124提供关于业务服务的进一步的信息；例如可以用于对服务进行寻址的消息队列。所述消息由3部分组成MQMD首标、RFH2首标和消息有效载荷。消息的属性将确定如何对该消息进行处理，例如，对业务服务的临界设置将控制该消息是否持续到非易失性存储器(以便确保传送)。下面提供对消息结构的更详细的描述。一旦被构造，消息将被分派到合适的队列116。该框架也支持有状态的业务服务。在这种情况下，路由机构必须遵从由之前的请求建立的任何亲和性。这通过MQ聚类和定制聚类退出算法而得到支持。综合层的调用框架114具有允许复杂的消息发送/接收方案的手段，所述方案例如阻塞或非阻塞模式。阻塞模式是业务服务返回响应且发送者等待接收该响应的情况。非阻塞模式是发送者调用业务服务但是不希望接收响应的情况。可以在单批中发送多个请求，并且可以动态或者静态地配置可接受的响应时间。可以在对接收堵塞之前发送多个消息。这样可以利用后端服务器的并4亍性。业务服务层120从MQ队列116读取请求消息并且运行业务服务。业务服务框架代码由队列中消息的到达触发，所请求的服务被调用。有业务服务产生的答复消息被发送到答复MQ队列118,该队列由请求中的调用框架指定。调用框架114从MQ队列118读取答复消息，并且将该答复消息返回给应用程序控制层112。应用程序控制层112处理该业务服务答复并且返回数据以备在表现层110中呈现。图7示出在综合层的业务服务调用框架中创建的消息的消息结构。在本例中，该消息具有WebsphereMQ所支持的格式，并且使用Java消息月良务(JMS)API产生。消息中的首标用于使得语境信息可以在系统中流动。该消息包括第一和第二首标77和79。第一首标77(称为MQMD首标)处于WebsphereMQ产品控制下，用于路由消息。第二首标79(称为RFH2首标)向使用者定义的信息可以流动的区域提供业务服务请求。该首标中的信息在SOA框架控制下组装，其目的主要在于促进系统管理功能。本发明提供标准日志机构，其可以在请求穿过系统中的层流动的时候，根据请求提出多个事件。此外，事件的探测标准可以被动态地调节，以便使得所产生的日志量可以被改变。其用处在于允许对系统误差和系统使用进行详细的探索和分析。事件可以在整个异构系统中被端到端地关联起来。对日志事件的记录非常灵活、动态并且可重新配置。该系统提供用于对日志事件进行集中式集合和处理并且将这些日志事件存储在数据库中的手段，以便允许后续的数据挖掘和分析。此外，特定的事件可以被配置为提出系统管理警报。系统管理信息可以在正常的端到端交互期间在许多点生成。以下解释四类日志和相关事件，它们是1、普通日志事件2、审核和管理信息事件3、部件交互事件4、误差和系统管理警报在图11中图示这4种类型的日至机构的概览130。所有的事件都通过SOA框架132提出。部件交互事件被发送给部件交互机构138然后被存储在日志数据库140中。其他日志事件134被发送给日志机构142并且被细分为系统管理警报144、普通事件146和专用审核和系统管理信息148A到148C。图1中描述各种一般日志事件以及发起者的标引。<table>tableseeoriginaldocumentpage20</column></row><table>这些事件通常在两种场景中被提出1、在应用程序/服务开发者的控制下创建专用调试信息。这通常在应用程序/服务开发期间有用，但也可以在生产期间被激活以加快问题的分辨。2、在SOA框架的控制下。这里在请求/交易生命周期的良好定义的点对事件进行日志记录。曰志被捕获并且保留在中央数据库中以便后续由形成本发明一部分的工具查询。这些日志数据的典型应用是1、应用程序性能监视2、在开发和生产中的问题分辨。日志信息具有足够的细节来允许对特定用户、及其或业务案例(策略、帐目等)的问题进行识别。3、容量/能力监视。提供关于绝对数目的信息以及趋势和并发性信自4、用户统计数据，例如应用程序每天的使用者数目。针对复杂的分析和数据的可视化提供模具。所记录的信息量可以被非入侵性地逐步提高或逐步降低。通常在生产系统中，只有往返信息和误差事件是默认被记录的。然而可以配置该机构以使得任何数目的事件类型(如表1所述)被记录。这也可以被精细地调节以便仅仅为了任意数目的使用者*机器应用程序应用程序中的层来记录数据。这里典型的场景是你希望解决系统问题，并且要最大化你所收集的运行时信息的量，但是你不想影响系统的性能。在这种情况下，你将识别一个或两个代表性的使用者，并且仅仅为他们逐步提高日志记录。提供额外的工具来收集专用的审核和管理信息。这不是通用的工具；SOA框架除了对非常专用的事件进行响应外不会生成审核/管理事件。在以下情况下使用存在为法律目的捕获数据的要求。存在捕获可以用于管理报告目的的专用信息的要求。存在确保创建日志记录的要求。如图8所示，向分离的、应用程序/分区专用的数据库写入审核和MI记录。这在存在限制对数据的访问的法律要求时有用。对这些信息的使用是专用的。根本的消息产品的"得到保证的传递"工具用于确保事件的传送。SOA框架在交易/请求生命中所定义的点处生成部件交互事件。如图12所示，这捕获应用程序控制、业务服务和数据服务部件之间的交互。所捕获的信息关于部件网络关系部件使用的级别本发明包括信息查询工具，其被设计为支持信道规划-对共享部件的变化的影响进行的评估问题诊断容量规划对SOA标准的符合性对重用的规模和取值的客观且自动的测量。在交易寿命期间发生的误差由标准日志机构处理。如图8所示，该机构可以干涉组织的系统管理机构以便提出系统管理警报。在本例中，提供了到IBMTivoli企业控制台的接口。根据误差是否被预见到，以两种方式中的一种来处理误差。预见到的误差是由于应用程序或框架开发者预见到的情形而发生的误差。可以这样处理预见到的误差1、将条目放到日志数据库。2、日志机构检查该误差是否是要求系统管理干预的误差。该判断以在应用程序拥有者和运行功能之间所达成的元数据为基础。3、如果要求干预，那么向系统管理解决方案分派警报。未预见到的误差将被记录到日志数据库，但是在业务服务层发生未预见到的误差时也会进行额外的处理来判断是否需要系统管理干预。这将是以下两种情况之一1、业务服务在业务服务目录中具有被配置为真的临界性标志。2、非临界性业务服务超过了预订的给定时段内故障的阈值。在业务月l务目录中再次配置故障的数目和时段。提供工具来允许将优先级信息传送到系统管理机构。应用程序所有者通常监视作为服务测量质量的误差事件。所提供的模具还可以用于浏览/分析误差信息。图10示出可获得的日志信息的示例，以及以图形的形式对该信息的表现。图10示出具有三个打开的窗口93、95和97的用户界面91。窗口93示出所有日志记录，窗口95示出无误差的往返统计数据，窗口97示出被图形化表现的往返并发性。这组数据是可以使用本发明获取的日志信息类型的代表。被图形化表现的信息显示在整个系统中给定时段内并发请求的平均数目，还显示响应事件的详细分解的图示。本发明提供标准化的部件交互日志。对那种作为SOA特点的复合应用程序进行整体观察；围绕影响分析的基于事实的决策更精确的资源规划收集有助于量化收益的重用统计数据。图11示出来自所提供的数据挖掘工具的用户界面，其允许用户查看和识别系统中的部件交互。左手边的屏幕显示若干应用程序。列1103表示应用程序名称，歹ll2105指示命中应用程序的数目，列3107表示命中的相对百分比。在本例中，突出显示应用程序CSOL111。右手边屏幕的上半部分113示出突出显示的CSOL应用程序111的细节，并且通过示出由前缀A表示的应用程序控制层部件115、由前缀B表示的业务服务部件117和由前缀D表示的数据服务部件119来提供关于CSOL应用程序的结构的信息。右手边屏幕的下半部分113A图形化地表现了被突出显示的CSOL应用程序对业务服务的使用。因此，本发明提供了公共的框架来给出标准化。这允许应用程序以一直的方式被创建和传送。除了对框架加工具进行组合之外，对日志事件的询问可以在不同的平台之间被端到端地关联[如同查询部件交互信息和支持系统管理的能力]。你需要改写这句，不知所云现在描述根据本发明的SOA设计软件应用程序的方式。应用程序设计阶段开始和识别于对业务和数据访问逻辑的高级别要求(以及一般来说总是要从划痕开发出来的表现层逻辑)。参考业务服务编目以便判断已有的业务服务满足这些要求中的任意一个。业务服务编目是对已经被开发并且部署为可重用部件的服务的完整列举。每个条目包括充分的关于服务的细节来帮助对可重用的可能性进行评估，并且提供与服务有关的一般信息。针对并非已经能够得到的功能，开始详细的分析和设计以便识别业务服务构成和界面。构建应用程序。在构建阶段，开发者通常会调用已经存在的业务服务和正在开发的新业务服务的混合。通过BSIF及其对应的配置来控制对业务服务的评估。通常对应用程序的开发包括构建和重用的混合。在采用SOA方法的两个例子中，在35个所识别出的业务服务要求中的30可以重用已有的业务服务，在17个所识别出的业务服务要求中的12可以重用已有的业务服务。一旦业务服务被重用，依赖性将在两个以上客户应用程序和业务服务之间存在。本发明支持版本划分模型，其允许新的业务服务版本在现有的版本旁被导入。当新的版本被部署时，其在现有版本旁被部署。客户应用程序不会自动采取新的版本，需要显式地更新客户应用程序来采取新的版本。一般来说客户应用程序将仅仅在要求其中要求的功能时才会采取新的版本。需要实施处理来将同时运行的版本的数目限制到可以管理的数目。在任何大规模SOA中，以非中断性的方式引入变化的能力是非常重要的。客户应用程序在其要求额外的功能时转向新的版本。如果需要，可以在原位对已有版本进行调试修复或立法改变。改进和修改可以在不脱离本发明范围的情况下并入于此。权利要求1、一种具有面向服务架构的计算机系统，其适于运行至少一个业务服务应用程序，该计算机系统包括至少一个信道依赖的客户层；至少一个信道独立的服务层；和综合层，其包括用于从所述至少一个客户层接收服务请求消息的请求接收装置、适于将该服务请求消息发送到所述至少一个服务层的消息路由器，所述至少一个服务层适于读取所述请求消息，并且作为响应，运行所述业务服务应用程序。2、根据权利要求1所述的计算机系统，其中所述客户层包括表现层，该表现层具有用于向端用户表现信息的处理装置和逻辑。3、根据权利要求2所述的计算机系统，其中所述表现层对所述应用程序而的。4、根据以上任意一项权利要求所述的计算机系统，其中所述客户层包括应用程序控制层。5、根据以上任意一项权利要求所述的计算机系统，其中所述服务层具有业务服务层。6、根据以上任意一项权利要求所述的计算机系统，其中所述服务层具有数据服务层。7、根据权利要求4所述的计算机系统，其中所述应用程序控制层作为针对所述业务服务层中的业务服务的控制部件。8、根据权利要求7所述的计算机系统，其中所述应用程序控制层确定需要哪个业务服务来满足所述服务请求。9、根据权利要求2所述的计算机系统，其中所述表现层能够通过发送数据请求给所述应用程序控制层来选l奪性地调用所述应用程序控制层的部件。10、根据权利要求5所述的计算机系统，其中所述业务服务层适于提供一般的业务功能。11、根据以上任意一项权利要求所述的计算机系统，其中在所述客户层和所述服务层之间分割对来自所述客户层的服务请求进行的端到端处理。12、根据以上任意一项权利要求所述的计算机系统，其中所述综合层将服务的名称映射到业务服务的名称和版本，并且将该消息路由到一队列。13、根据以上任意一项权利要求所述的计算机系统，其中所述综合层使用业务服务名称和版本作为关键字访问一业务服务目录。14、根据以上任意一项权利要求所述的计算机系统，其中所述综合层进一步包括一消息队列。15、根据权利要求5所述的计算机系统，其中所述业务服务层适于从所迷消息队列读取所述请求消息，并且作为响应，运行该业务服务应用程序。16、根据以上任意一项权利要求所述的计算机系统，其中在所述消息队列中所述请求消息的到达触发调用被请求服务的业务服务框架代码。17、根据权利要求16所述的计算机系统，其中所述业务服务层产生答复消息，并将其发送到答复消息队列。18、根据权利要求17所述的计算机系统，其中所述答复消息所发送到的答复消息队列在所述请求消息中指定。19、根据权利要求17所述的计算机系统，其中所述应用程序控制层处理所述业务服务答复消息并且返回数据以备在所述表现层中呈现。20、根据以上任意一项权利要求所述的计算机系统，其中由所述消息发生器生成的所述请求消息包括一使得可穿过该系统路由所述消息的首标。21、根据权利要求20所述的计算机系统，其中所述消息首标使得用户和系统定义的上下文信息可穿过该系统流动。22、根据权利要求20或21所述的计算机系统，其中所述消息首标向所述消息提供唯一的标识符，该标识符允许关于该消息的信息在逻辑控制间流动。23、根据权利要求20到22所述的计算机系统，其中所述消息具有会话ID,该会话ID提供关于用户会话的信息，所述消息在该会话中执行。24、根据权利要求20到23所述的计算机系统，其中所述消息具有上下文链标识符，该上下文链标识符使得该消息在消息链中的位置得以被识别。25、根据权利要求20到24所述的计算机系统，其中所述消息具有包含请求数据的有效载荷。26、根据权利要求25所述的计算机系统，其中所述请求数据包括可以传送到所述业务服务的输入参数。27、根据以上任意一项权利要求所述的计算机系统，其中该系统进一步包括系统管理器。28、根据权利要求27所述的计算机系统，其中所述系统管理器包括一曰志机构，该日志机构用于探测与系统活动有关的日志事件。29、根据权利要求27和28所述的计算机系统，其中当所述请求消息穿过该系统中的层流动时，所述日志机构根据请求消息发送至少一个事件。30、根据权利要求29所迷的计算机系统，其中所述事件发送可以被动态地调高或调低，以便使得可以改变所生成的日志量。31、根据权利要求28到30所述的计算机系统，其中所述日志事件被捕获并保留在中心数据库中以备后续的查询。32、根据权利要求28到31所述的计算机系统，其中所述日志机构具有用于分析日志数据的分析工具。33、根据权利要求28到32所述的计算机系统，其中所述日志机构是可配置的，从而使得可以对不同的事件类型进行日志记录。34、根据权利要求28到32所述的计算机系统，其中所述日志机构收集诸如应用程序专用审核和管理信息之类的事件类型。35、根据权利要求28到32所述的计算机系统，其中所述分析工具使用图形用户界面，所述图形用户界面表现一个以上不同的事件类型。36、根据权利要求33所述的计算机系统，其中至少一个事件类型被显示在与另一个事件类型相分离的窗口中。37、根据权利要求35或36所述的计算机系统，其中事件类型数据包括在该系统中并发的请求的平均数目。38、根据权利要求35到37所述的计算机系统，其中事件类型数据包括响应时间数据。39、一种用于操作面向服务的架构的方法，该方法包括以下步骤从至少一个客户层向综合层发送服务请求消息，通过所述综合层将所述服务请求消息路由到至少一个服务层，所述至少一个服务层适于读取所述请求消息，并且作为响应，运行一业务服务应用程序。40、根据权利要求39所述的方法，其中所述客户层包括表现层，该表现层具有用于向端用户表现信息的处理装置和逻辑。41、根据权利要求39或40所述的方法，其中所述客户层包括应用程序控制层。42、根据权利要求39到41所述的方法，其中所述服务层具有业务服务层。43、根据权利要求39到42所述的方法，其中所述服务层具有数据服务层。44、根据权利要求39所述的方法，其中所述应用程序控制层控制所述业务服务层中的业务服务。45、根据权利要求39到44所述的方法，其中所述应用程序控制层确定需要哪个业务服务来满足所述服务请求。46、根据权利要求45所述的方法，其中所述表现层能够通过发送数据请求给所述应用程序控制层来选择性地调用所述应用程序控制层的部件。47、根据权利要求39所述的方法，其中在所述客户层和所述服务层之间分割对来自所述客户层的服务请求进行的端到端处理。48、根据权利要求39到47所述的方法，其中所述综合层使用业务服务名称和版本作为关键字访问一业务服务目录。49、根据权利要求42所述的方法，其中所述业务服务层适于从所述消息队列读取所述请求消息，并且作为响应，运行该业务服务应用程序。50、根据权利要求49所述的方法，其中在所述消息队列中所述请求消息的到达触发调用被请求服务的业务服务框架代码。51、根据权利要求50所述的方法，其中所述业务服务层产生答复消息，并将其发送到答复消息队列。52、根据权利要求51所述的方法，其中所述答复消息所发送到的答复消息队列在所述请求消息中指定。53、根据权利要求51所述的方法，其中所述应用程序控制层处理所述业务服务答复消息并且返回数据以备在所述表现层中呈现。54、根据权利要求39到53所述的方法，其中由所述消息发生器生成的所述请求消息包括一使得可穿过该系统路由所述消息的首标。55、根据权利要求54所述的方法，其中所述消息首标使得用户和系统定义的上下文信息可穿过该系统流动。56、根据权利要求54或55所述的方法，其中所述消息首标向所述消息提供唯一的标识符，该标识符允许关于该消息的信息在逻辑控制间流动。57、根据权利要求54到56所述的方法，其中所述消息具有会话ID,该会话ID提供关于用户会话的信息，所述消息在该会话中执行。58、根据权利要求54到57所述的方法，其中所述消息具有上下文链标识符，该上下文链标识符使得该消息在消息链中的位置得以被识别。59、根据权利要求54到58所述的方法，其中所述消息具有包含请求数据的有效载荷。60、根据权利要求39到59所述的方法，其中对与系统活动有关的事件进4亍日，志、十己录。61、根据权利要求60所述的方法，其中当所述请求消息穿过该系统中的层流动时，根据请求消息发送至少一个事件。62、根据权利要求61所述的方法，其中所述事件发送可以被动态地调高或调低，以便使得可以改变所生成的日志量。63、根据权利要求60到62所述的方法，其中所述日志事件被捕获并保留在中心数据库中以备后续的查询。64、根据权利要求60到63所述的方法，其中所述日志机构是可配置的，从而使得可以对不同的事件类型进行日志记录。65、根据权利要求60到64所述的方法，其中所述日志机构收集诸如应用程序专用审核和管理信息之类的事件类型。66、根据权利要求60到65所述的方法，其中一图形用户界面表现一个以上不同的事件类型。67、根据权利要求66所述的方法，其中至少一个事件类型被显示在与另一个事件类型相分离的窗口中。68、根据权利要求65所述的方法，其中事件类型数据包括在该系统中并发的请求的平均数目。69、根据权利要求65或69所述的方法，其中事件类型数据包括响应时间数据。全文摘要一种使用在分布式网络上运行业务服务应用程序的面向服务架构的计算机系统与方法。该系统具有包括表现层和应用程序控制层的信道依赖的客户层，包括业务服务层和数据服务层的信道独立的服务层，以及综合层。该综合层能够从该客户层接收服务请求，并具有将请求消息发送给该服务层的消息发生器，该服务层适于读取该请求消息，并作为响应，运行所述业务服务应用程序。文档编号G06Q10/00GK101288091SQ200680037010公开日2008年10月15日申请日期2006年9月7日优先权日2005年9月9日发明者大卫·查理斯·埃夫亚德,德雷克·约翰·帕通,约瑟夫·彼得·菲利普斯申请人:优质生活联合服务有限公司