CN1585948A

CN1585948A - 用于系统整合的应用程序视窗部件

Info

Publication number: CN1585948A
Application number: CN 02825183
Authority: CN
Inventors: 米奇·厄普顿
Original assignee: BEA Systems Inc
Current assignee: BEA Systems Inc
Priority date: 2001-10-18
Filing date: 2002-10-17
Publication date: 2005-02-23
Also published as: AU2002347926A1; AU2002347927A1; WO2003034182A2; WO2003034182A3; EP1444609A4; EP1444609A1; WO2003034183A3; WO2003034285A1; AU2002347919A1; JP2005506618A; WO2003034183A2; WO2003034228A1; WO2003044661A1

Abstract

应用程序视窗(102)，或应用程序视窗部件可以表示对诸如应用程序或企业系统之类的资源中的功能的自描述界面。应用程序视窗可以使处理应用程序的复杂性降低很多，使得非程序员可以维护那个应用程序的适配器(106)展示的服务和事件。应用程序视窗还可以简化访问适配器(106、108和110)的方式，和可以使适配器展示的功能作为商业服务得到调用。应用程序视窗可以专用于单个适配器，和可以在相应应用程序上定义一组功能。

Description

用于系统整合的应用程序视窗部件

优先权要求

本申请要求如下申请的优先权，特此引用，以供参考。

美国临时专利申请第60/347,919号，2001年10月18日提出，发明名称：“应用程序视窗(APPLICATION VIEW)”。

美国临时专利申请第60/347,901号；2001年10月18日提出；发明名称：“事件适配器(EVENT ADPTPER)”。

美国专利申请第＿＿号；发明名称：“用于系统整合的应用程序视窗部件(APPLICATION VIEW COMPONENT FOR SYSTEM INTEGRATION)”；申请人：MitchUpton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“为工作流调用商业功能的系统和方法(SYSTEM AND METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR AWORKFLOW)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“实现事件适配器的系统和方法(SYSTEM AND METHOD FOR IMPLEMENTING AN EVENT ADAPTER)”；申请人：MitchUpton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“把连接器结构用于应用程序整合的系统和方法(SYSTEM AND METHOD FOR USING A CONNECTOR ARCHITECTURE FORAPPLICATION INTEGRATION)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“在应用程序整合中实现模式对象模型的系统和方法(SYSTEM AND METHOD FOR IMPLEMENTING A SCHEMA OBJECTMODEL IN APPLICATION INTEGRATION)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“利用界面部件查询文档的系统和方法(SYSTEM AND METHOD FOR UTILIZING AN INTERFACE COMPONENT TO QUERYA DOCUMENT)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“把异步消息传送用于应用程序整合的系统和方法(SYSTEM AND METHOD USING ASYNCHRONOUS MESSAGING FORAPPLICATION INTEGRATION)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“实现服务适配器的系统和方法(SYSTEM AND METHOD FOR IMPLEMENTING A SERVICE ADAPTER)”；申请人：Mitch Upton；2002年10月15日提出。

版权通告

交叉参考案例：

如下申请被交叉参考，特此引用，以供参考。

美国专利申请第＿＿号；发明名称：“向应用程序视窗部件提供JAVA界面的系统和方法(SYSTEM AND METHOD FOR PROVIDING JAVA INTERFACE TO ANAPPLICATION VIEW COMPONENT)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“与企业系统一起使用万维网服务的系统和方法(SYSTEM AND METHOD FOR USING WEB SERVICES WITH AN ENTERPRISESYSTEM)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第—号；发明名称：“把连接器结构用于应用程序整合的系统和方法(SYSTEM AND METHOD FOR USING A CONNECTOR ARCHITECTURE FORAPPLICATION INTEGRATION)”；申请人：Mitch Upton；2002年10月15日提出。

美国专利申请第＿＿号；发明名称：“用于整合适配器安全性的系统和方法(SYSTEM AND METHOD FOR INTEGRATION ADAPTER SECURITY)”；申请人：Mitch Upton；2002年10月15日提出。

技术领域

本发明一般涉及可用于使应用程序整合的部件。

背景技术

电子商务已经成为新经济中的主要驱动因素。为了取得长期成功，电子商务需求许多公司从事交叉企业协作。为了实现交叉企业整合，公司必须首先使它的内部应用程序整合。利用现有技术和工具，应用程序整合是一个昂贵的课题。不存在易于使用、负担得起、和基于工业标准的整合解决方案。没有一种解决方案是基于工业标准基础结构、具有通用连通性、能够大规模伸缩的并含有可访问商业进程工具。

关于这一方面的应用程序整合是高度向内聚集的。许多现有的整合系统还没有集中在使企业间的应用程序整合上。即使一些整合解决方案已用于交叉企业整合，这些解决方案也仍然狭窄地聚焦和针对垂直市场。这种向内聚焦对公司实现诸如可以利用因特网来产生效益和降低成本的应用之类的场外商家对消费者和商家对商家的应用几乎没有什么帮助。对启用因特网的应用的需求导致应用程序服务器市场的兴起。到目前为止，应用程序服务器主要用于寄存瞄准客户和伙伴的外部应用程序。应用程序服务器本身不是解决具体问题，而是寄存垂直解决方案的通用平台的打包应用程序。

对应用程序整合的初始尝试主要集中在数据的格式、机器之间的字节排序、和字符编码之类的低级实现细节上。把注意力集中在低级数据格式上是有必要的，因为，对于第一代应用程序整合解决方案，还没有广泛采用的可供多种垂直应用程序使用的数据编码标准。

传统的方法涉及到连接各个系统，事实上，将系统硬连接在一起。这种方法比较复杂，因为连接不同系统需要多个系统的专有技术的密切的、低级的知识。

已经远离将系统“硬连接”在一起的当前整合系统仍然缺乏标准。每个整合销售商通常提供应用程序整合、消息变换、消息格式、消息传输、和路由的专有解决方案。到目前为止这些系统没有一个已经实现了重要的市场共享，使它的技术成为事实上的标准。这种标准的缺乏几乎不能激励打包应用程序销售商将这些系统与他们的应用程序整合。而且，这些整合系统或服务器中的每一个都拥有它自己的专用API，使得打包应用程序销售商不能把钱冒险投资在单个整合服务器之外的开发上。整合市场的这种支离破碎几乎不能在金钱上驱动第三方。

发明内容

按照本发明的系统和方法通过利用应用程序视窗、应用程序视窗部件、和/或应用程序视窗对象可以为应用程序整合提供保证。资源适配器可以用于调用第一应用程序中的功能和展示那个功能。应用程序视窗部件可以用于提供第二应用程序通过资源适配器访问第一应用程序、和/或调用的功能的途径。第二应用程序无需知道有关第一应用程序的功能细节，应用程序视窗部件就可以使第二应用程序访问第一应用程序。应用程序视窗部件可以允许在第一应用程序与第二应用程序之间进行双向通信，和可以翻译应用程序之间的消息。

本发明的其它特征、方面、和目的可以通过考察说明书、附图、和权利要求书来获得。

附图说明

图1是可以根据本发明的一个实施例使用的整合系统的图形；

图2是显示创建和部署可以用在图1的系统中的应用程序视窗的方法的流程图；

图3(a)和3(b)显示了与和不与公用协议通信的计算机系统；

图4显示了利用应用程序视窗使请求进入各种系统的客户机；

图5是显示可以用在图1的系统中的应用程序视窗部件的生命周期的流程图；和

图6是显示根据本发明的一个实施例将Siebel和SAP系统整合的系统的示图。

具体实施方式

应用程序整合部件可以用于使企业信息系统(EIS)之类的各种应用程序和系统整合。信息技术(IT)机构通常利用几种高度专业化的应用程序。在没有便于应用级整合的公用整合平台的情况下，没有广泛的、高度专业化的开发努力，就不能使这些应用程序整合。

应用程序整合可以利用适配器来建立使任何当前或将来应用程序整合的企业范围的、统一框架。适配器通过使每个应用程序与应用程序服务器整合，而不是要求每个应用程序与所有其他应用程序整合，可以简化整合尝试。

像来自加州Santa Clara太阳微系统公司的Java2 Platform，EnterpriseEdition(J2EE)那样的标准，以及可扩充标记语言(XML)的开发和广泛接受奠定了开发这些适配器的标准化方法的基础。也许这些用于应用程序整合的标准的最重要部分是J2EE连接器结构。J2EE连接器结构为所有类型的应用程序，从像来自IBM的CICS那样的传统主机应用程序到像PeopleSoft、Siebel和SAP那样的成包应用程序，提供了开发适配器的标准化方法。采用这样的标准使商家能够开发出在，例如，遵从J2EE的应用程序服务器上工作的适配器。

整合结构

通过提供寄存基于J2EE连接器结构的适配器的基于标准的结构，应用程序整合可以建在应用程序整合框架下的这种标准化方法上。开发者可以在整合框架下，建造遵从J2EE连接器结构的适配器和部署这些适配器，以便将企业应用程序与应用程序服务器相连接。

这些适配器可以用于定义与EIS的聚焦商业的界面，下文把这些界面称为各个适配器的“应用程序视窗”。应用程序视窗可以向应用中的服务和事件提供简单、自描述、一致性的界面。应用程序视窗可以把适配器用于EIS，使它可以把现有信息系统展示成商业服务。但是，与适配器不同，应用程序视窗不需要用户拥有EIS或那个EIS的客户机界面的密切相关的知识，使得非程序员或技术分析者可以使用应用程序视窗。应用程序视窗可以提供商业分析者无需担心适配器中定义的编程细节就可以访问企业数据的面向商家的方式。另一方面，由于不熟悉EIS，这些相同的用户可能无法直接使用适配器。

针对企业应用程序整合的应用程序整合部件可以含有几个基本方面。如果像PeopleSoft系统或SAP系统那样的EIS的功能得到调用，可以使用J2EE连接器结构的实施方案。如果在EIS系统内部发生了什么事件，如触发消息了，可能生成一个事件。在一些实施例中，这个事件可能需要与外部应用程序通信。应用程序整合部件中的事件结构可以管理这种通信。

应用程序视窗

应用程序视窗可以把有效值提供给应用程序整合部件。应用程序视窗在处理像后端EIS系统那样的应用程序方面可以使复杂性降低很多。应用程序视窗还可以简化访问适配器的方式。应用程序视窗可以提供，例如，适配器和那个适配器展示的EIS功能之间的分离层。取代通过直接编程访问EIS，用户可以简单地编辑适配器的应用程序视窗，创建新应用程序视窗，或删除任何过时的应用程序视窗。由应用程序视窗形成的分离层可以帮助非程序员维护适配器展示的服务和事件。每个应用程序视窗可以专用于单个适配器，并且可以定义一组有关那个适配器的EIS的商业功能。在创建了适配器之后，适配器的基于万维网的界面可以用于定义应用程序视窗。

如果应用程序视窗用作适配器的基本用户界面，那么，可以包括在现有企业应用程序整合技术中通常找不到的许多特征。应用程序视窗可以，例如，把XML用作应用程序当中的公用语言。服务和事件定义可以用于展示应用程序能力。XML模式可以用于定义服务和事件的数据。在适配器中还可以支持双向通信。

当用作界面对象时，应用程序视窗可以是整合框架的整体部分。应用程序视窗可以提供用户可以定制成满足特定需要的适配器展示的应用程序能力的视窗。用户可以把应用程序视窗剪裁成适合，例如，特定商业用途。其结果是，应用程序视窗可以提供许多应用程序为设计客户机界面提供的“一个尺寸适合所有”方法的有效替代物。可以只为可应用于特定用途的商业或其它能力定义应用程序视窗。这些能力可以通过，例如，命名，描述和定义数据要求来定制。

在一个例子中，如图1所示，可以开发出通过利用应用程序视窗102使客户机应用程序100与企业信息系统104通信的适配器106、108、110。开发者可以从编码展示访问企业数据的企业应用程序中的功能的适配器开始。适配器展示的功能可以是，例如，利用SQL语句更新数据库中的记录，或可以利用它的BAPI或IDOC界面请求来自SAP系统的信息。然后，与开发者一起工作的商业分析者可以利用应用程序视窗界面定义适配器的应用程序视窗。

应用程序视窗是在一个实施例中可以作为无状态会话JavaBean实现的对象。可以存在与客户机应用程序的应用程序视窗的Java界面。Java应用程序可以通过，例如，传入XML和接收回XML被定制编码成使用那个对象。另外，可以包括使进程工程师定义工作流，和使应用程序视窗作为商业服务调用的商业进程管理部件。在工作流中，可以使说明文字变成获得诸如客户信用记录之类的信息的EIS。可以使进程和设计者不知道应用程序视窗是Java对象或企业JavaBean的事实。

万维网服务界面还可以与应用程序视窗一起使用。像SOAP那样的协议可以用于调用万维网服务。可以使用的另一种协议包括UDDI，一种描述服务、发现商家、和利用因特网使商业服务整合的平台无关的开放框架。也可以使用WSDL协议，它是描述网络服务的XML格式。可以将万维网服务层配备在应用程序视窗的顶部，以便可以调用任何应用程序视窗作为万维网服务。

在应用程序整合中，可以通过基于万维网的界面以现有EIS为背景热部署新应用程序视窗。当随着系统运行目标服务器，而不是重新启动目标服务器部署应用程序视窗时，应用程序视窗被热部署。例如，SAP的新客户管理工具也可以通过万维网浏览器来定义。用户还可以决定是否应该持久地部署应用程序视窗。持久部署意味着每当重新启动应用程序服务器时，可以重新部署应用程序视窗。

整合框架

应用程序整合可以利用整合框架，整合框架可以提供用于寄存应用程序视窗的系统的、基于标准的结构。这样的框架的特征可以包括展示应用程序功能的应用程序视窗、和像可以用于创建应用程序视窗的基于万维网的界面那样的设计时间图形用户界面(GUI)。整合框架利用适配器，而不是把企业系统“硬连接”在一起。一旦为EIS部署了适配器，其它部件和应用程序可以利用那个适配器来访问EIS上的数据。

按照本发明一个实施例的框架依赖于作为消息的标准格式的XML。XML包括XSLT，一种将XML文档变换成其它XML文档的标准。XSLT被设计成作为XSL的一部分来使用，XSL是XML的页面格式语言。在XSLT中，XML文档用于指定对一类XML文档进行的操作，以便变换文档的结构和内容。XSLT变换可以利用建成Java编程语言的任何操作，或可以利用以Java写成或以本机代码写成的定制操作。整合框架使商业进程可以调用XSLT引擎，以便变换XML消息。

整合框架也可以依赖于诸如Java消息服务(JMS)和HTTPS之类传输消息的标准。JMS是与消息传输系统交互的标准API。利用JMS，框架可以使用提供JMS界面的任何消息传输机制。J2EE连接器结构标准不规定消息传输机制，但应用程序整合框架可以规定这样的传输机制。

整合框架可以基于现有标准基础结构，如支持J2EE、JMS、和J2EE连接器结构的应用程序服务器。通过诸如分类归并和资源集中控制，利用这样的标准基础结构还为高度适用性和可伸缩性创造条件。通过构造可以与任何旧的成包应用程序连接的基于XML的应用程序适配器，该框架可以为通用连通性创造条件。适配器开发工具包可以用于使诸如客户、系统整合者、和成包应用程序销售商之类的用户可以迅速地开发遵从J2EE连接器结构和基于整合框架的适配器。该框架可以使用XML，由于许多电子商务系统把XML用作标准消息格式，这意味着同一数据格式可以用于企业内和企业间整合。

整合框架还可以使用商业进程引擎，使非程序员用图形构造和维护商业进程。整合框架可以在集中在商用级概念上的J2EE连接器结构的顶部实现公用模型。与适配器和它们的目标应用程序之间所需的界面无关，这种可以由XML编码事件和服务组成的模式使一致性整合环境得到管理。商业进程可以对应用程序生成的事件作出反应，它们可以通过应用程序适配器展示的服务调用应用程序的功能。

分离

如上所述，由于应用程序视窗可以是至应用程序的标准化、自描述界面，应用程序视窗可以在适配器的技术实现和适配器展示的能力的使用之间提供分离层。

在一个实例中，应用程序能力的商用级视窗可以提供程序员和商业分析者之间的逻辑分离。例如，这种分离使商业分析者无需必须知道诸如SQL语句之类创建数据库记录的语句，就能够创建数据库中的记录。

为了利用，例如，SQL语句更新数据库中的记录，商业分析者可以定义称为“UpdateRecords(更新记录)”的应用程序视窗。程序员可以供应更新数据库记录的SQL语句和使这些语句包括在UpdateRecords的定义中。在运行时，Update-Records可以被来自，例如，商业进程的XML消息调用。应用程序视窗又能调用适配器和把SQL语句传递给适配器。适配器可以访问企业数据和把结果返回给可以返回另一个XML消息中的结果的UpdateRecords应用程序视窗。

定义应用程序视窗

用户在某些情况下可能需要定义应用程序视窗和把定制代码写入其它应用程序视窗中。使用适配器的设计时间GUI不是展示EIS的功能的唯一方式，但是在某些情况下可能是最便利的。为了支持服务调用和事件，可以定义应用程序视窗或可以写入定制代码，以实现特定功能。在许多情况下，可以为展示应用程序功能的每个适配器定义应用程序视窗。在其它情况下，或对于要求更多控制的用户，可以写入定制代码，以访问适配器的资源。对于企业，可以使用这两种方法的组合。

一般说来，对于企业中存在多于一个的EIS系统的情况，尤其是，如果缺少拥有所有系统的详细、全面知识的开发者，可以定义应用程序视窗。例如，当整合工作室要用于构建和管理商业进程时，或者，在有必要更新适配器或它的进程之一的参数的情况下，也可以定义应用程序视窗。

应用程序视窗可以使用户能够通过浏览特定应用程序的字段和数据来定义整合点。通过定义应用程序视窗，用户可以为，例如，客户管理系统、销售、订购管理系统、或购买订单管理系统定义整合终点。用户可以创建供每种商业使用的应用程序视窗，并且，可以利用整合框架部件部署和管理这些应用程序视窗。

在试图定义应用程序视窗之前，可能需要满足某些先决条件。首先，应该利用，例如，ADK开发适当的适配器。某些应用程序视窗只能为现有适配器创建和配置的。还应该确定哪些进程需要配置的应用程序视窗支持。任何所需的进程都可以确定要包括在应用程序视窗中的服务和事件的类型。这可以要求，例如，收集与某些商业进程一起使用的有关来自商业分析者的应用程序商业要求的信息。一旦必要的进程被确定下来，就可以定义和测试适当的服务和事件。

当定义应用程序视窗时，可以在应用程序服务器和企业内的特定EIS应用程序之间创建诸如基于XML的界面之类的界面。一旦创建了应用程序视窗，商业分析者就可以把它用于，例如，创建使用应用程序的商业进程。对于一个适配器，可以创建任何数量的应用程序视窗，每一个可含有任何数量的服务和事件。

图2显示了按照本发明的一个实施例定义应用程序视窗的方法的概况。尽管该方法是利用应用程序视窗控制台来描述，但是，应该明白，也可以使用使数据和/或选项得到输入和/或选择的任何其它适当用户界面。首先，用户登录到应用程序视窗控制台200。用户可以通过控制台选择加入或创建应用程序视窗的选项，以便为适当的适配器创建应用程序视窗。这个新的应用程序视窗将为这个适配器的目标EIS应用程序启用一组商业进程。用户可以定义适配器、EIS、和/或商业进程所需的应用程序视窗202。用户可以输入和配置应用程序连接参数204。信息可以由控制台核实，和应用程序视窗可以被配置成与特定系统连接。用户可以加入事件208或服务206，并且可以为这个应用程序视窗定义适当的事件和服务。然后，可以在应用程序服务器上部署应用程序视窗210，以便至少根据任何安全设置，其它项目可以与应用程序视窗交互。可以测试服务212，和可以测试事件214，以保证它们适当地与目标EIS应用程序交互。一旦服务和事件得到测试和正在起作用，应用程序视窗就可以用在工作流中。如有必要，可以取消应用程序视窗的部署，以重新配置连接参数或添加服务和事件。

通过将EIS适配器的例子用于称为简单“DBMS”的假想数据库EIS，可以显示定义和维护应用程序视窗的一种方法。当为企业创建应用程序视窗时，应用程序视窗屏幕看起来可能与别的企业的屏幕不同。应用程序视窗的适配器可以确定每个应用程序视窗页面所需的信息，和每个企业可以拥有它自己的专用适配器。

创建这个新应用程序视窗的第一步是登录到应用程序视窗“控制台”页面。控制台可以显示应用程序整合环境下的所有应用程序视窗，譬如，可以被组织成文件夹。为了登录到控制台，用户可以打开把URL用于适当应用程序视窗控制台的万维网浏览器窗口。在登录到控制台和导航到文件夹或创建了新文件夹之后，用户可以点击加入或定义应用程序视窗。然后，可以显示“定义”页面。在一些实施例中，一旦得到定义，应用程序视窗可能没有被移动到另一个文件夹。

“定义”页面可以是用户可以输入应用程序视窗的名称，譬如描述这个应用程序执行的一组功能的名称的字段。每个应用程序视窗名称对于它的适配器来说可以是唯一的，并且可以包括字母和数字。在描述字段中，用户可以输入任何相关注释。用户在他们把这个应用程序视窗用在工作流，譬如使用商业进程管理(BPM)的工作流中的时候可以观看这些注释。从相关适配器的列表中，用户可以选择用于创建这个应用程序视窗的适配器。

接着，用户可以导航到使适当连接参数得到配置的页面。这里，用户可以定义应用程序视窗与目标EIS交互所需的网络相关信息。可以按应用程序视窗一次性输入这个信息。

在创建和配置应用程序视窗之后，用户可以加入支持应用程序功能的服务。在打开应用程序视窗的同时，用户可以导航到“管理”页面。这里，用户可以加入服务，赋予服务以描述这个服务执行的功能的名称。每个服务名称对于它的应用程序视窗来说可以是唯一的。用户可以在描述或类似字段中输入任何相关注释。用户在他们把这个应用程序视窗服务用在使用BPM的工作流中的时候可以观看这些注释。当完成时，用户可以通过如下与加入服务类似的步骤，把事件加入应用程序视窗中。

事件和服务

应用程序视窗可以通过底层适配器支持有关应用程序的事件和服务。这些事件和服务可以为特定使用，譬如为特定商业进程而建立。在一个例子中，“事件”使应用程序生成的消息能够遵从公布/预订模型得到管理。在这种模型中，用户可以“预订”，以接收应用程序“公布”的消息。每个消息可以被称为公开事件。这样的模型可以通过，例如，多点广播实现。

“服务”可以起可以被用户调用的商业功能的作用。服务调用可以使消息发送到遵从请求/响应模型的应用程序。这种模型可以与公布/预订模型不同，不同之处在于，当用户请求时，只发送消息。这可以利用，例如，点到点消息传送系统实现。事件和服务都可以作为XML文档穿过系统。

服务可以构成应用程序视窗为重新使用展示的应用程序中的商业逻辑单元。当应用程序视窗接收到包含调用商业服务的请求的XML文档时，应用程序视窗可以调用它的目标应用程序内的那个功能和返回描述结果的XML文档。应用程序视窗上的每个服务可以代表目标应用程序内，诸如单个、逻辑商业功能之类的单个功能。服务可以以，例如，XML文档的形式获得请求数据，并且返回也可以采取XML文档的形式的响应数据。这些服务可以代表应用程序视窗客户机和目标应用程序之间的双向通信。这些服务可以顾及应用程序之间的同步或异步通信。

元数据

基于一个实施例的应用程序视窗的关键特性之一是提供描述与EIS系统交互的过程的元数据的能力。应用程序视窗可以通知可以使用的所有适用服务的客户机应用程序。对于客户管理例子，这些可以是诸如“GetCustomer-Detail”或“CheckOrderStatus”的服务。应用程序视窗可以以，例如，XML模式的形式提供有关其本身的元数据。

应用程序视窗还可以包括自描述元数据。应用程序视窗可以把XML模式用作描述事件、服务请求和响应的XML信息的元数据。这个元数据可以帮助用户了解感兴趣事件或服务的数据要求。

由于应用程序视窗的能力可以被表示成元数据，可以在一个系统上创建应用程序视窗和在另一个系统上部署该应用程序视窗。应用程序视窗可以提供，例如，程序员和商业分析者之间的逻辑分离。商业分析者无需必须知道SQL就可以创建数据库中的记录，或者无需从技术上了解SAP就可以请求来自SQP的信息。应用程序视窗可以与适配器使用的底层实施方案无关地提供一致性的数据表示。例如，每个EIS也许拥有XML界面。对于适用于客户机的每种交互，可以存在描述那种交互的有效XML文档的准则的相应XML模式。应用程序视窗可以使企业整合点通过商业语义关系，譬如，CustomerManagement(客户管理)、Order Processing(订单处理)和Inventory Control(库存控制)来组织。

应该注意到，在某些情况下可以向应用程序视窗展示至少三种特征，包括向外消息、返回消息的向内请求、和观看可以向外发送或向内处理的任何消息的描述的方式。一旦适配器的可能连接得到展示，应用程序视窗就可以不让商业分析者知道技术细节。适配器可以负责从EIS专用连接到应用程序视窗能够使用的方法的过渡。

公用协议

应用程序视窗可以利用公用协议。由于每个应用程序只需要与公用协议整合，而不是与所有其它应用程序整合，公用协议可以有助于使应用程序整合成为可能。借助于公用协议，应用程序可以利用诸如XML之类的标准语言进行通信。一种这样的公用协议可以是基于通过XML文档表示的事件和服务的。适配器可以通过应用程序视窗，以XML格式展示作为事件和服务的应用程序功能和数据格式，以便事件和服务可供整合服务的所有客户机使用。

在没有公用协议的情况下，可能存在许多种需要相互翻译的不同语言。图3(a)和3(b)例示了利用公用协议的应用程序整合对不利用公用协议的应用程序整合。在图3(a)中，显示了没有利用公用协议进行通信的4个计算机系统300、302、304、306。在这种情况下，中央集线器320必须管理用于计算机300的协议308，以及分别用于计算机302、304、和306的协议310、312、和314。集线器320还必须管理协议308、310、312、314每一种的所有字节格式、字符编码、和类型转换。

在图3(b)中，整合框架在J2EE连接器结构的顶部提供应用程序整合的公用协议318。这个协议318可以通过应用程序视窗316受到支持，并且可以由编码成XML文档的事件和服务组成。通过使用应用程序视窗316，每个计算机系统300、302、304、306无需必须了解其它协议，就可以与使用公用协议的计算机系统通信。并且，中央集线器不需要管理多种协议308、310、312、314，而是只需要处理公用协议318。应用程序视窗316的每一个可以在整合框架下加强相容数据格式和相容行为。

尽管对目标应用程序所作的请求可以使用SQL或直接API调用，但对应用程序视窗的请求可以以XML的形式作出。例如，如图4所示，客户机400可以通过两个分离的应用程序视窗部件402、404调用三个分离的应用程序406、408、410。对应用程序视窗402、404之一的请求不需要寻址任何登录信息。在调用A和调用B中，由于与对“西海岸”应用程序视窗404的调用B一样，对“东海岸”应用程序视窗402的调用A试图获取客户信息，这两个调用请求相同的信息。但是，实际数据是分别从PeopleSoft 406和SAP 408中检索出来的。开始调用的客户机400意识不到哪个应用程序实际正在处理每个请求。在调用B和C中，这两个调用与同一应用程序404相联系，但是由于获取客户信息的调用B从SAP 408获取信息，和获取客户历史信息的调用C从传统系统410获取信息，每个请求得到不同管理。这使得信息的逻辑分组受单个应用程序视窗404管理。客户机400或用户可以看到一小组可从目标应用程序获得的功能，和这些功能可以以更有用的形式分组。

应用程序视窗可以是将XML消息翻译成EIS要求的必要界面和反过来翻译的中介。另外，应用程序视窗可以提供自省特征，以便对使用应用程序视窗感兴趣的客户机可以确定哪些能力是可用的，以及每种能力将接受和返回的XML文档的类型。

在应用程序视窗中，可以存在相容交互。向外消息可以通过事件生成和向内消息可以通过服务处理。应用程序视窗可以通过元数据动态地得到实现和配置。有可能不需要代码生成。这种方法顾及对商业事件和变化的可变适应。可以不需要编译器，也无需担心与，譬如，Java新版本的兼容性。

图形用户界面(GUI)

整合框架可以为每个适配器提供开发者提供设计时间GUI的方式。设计时间GUI可以提供创建应用程序视窗、把服务和事件加入应用程序视窗中、和部署、测试和编辑应用程序视窗的方式。应用程序视窗控制台可以包括在GUI中，以有助于用户访问、组织和编辑企业中的所有应用程序视窗。应用程序视窗控制台可以用于创建新文件夹和把新应用程序视窗加入文件夹中。这些新文件夹使用户可以与应用程序视窗使用的适配器无关地根据特定导航方案组织应用程序视窗。

当应用程序视窗过时或应用程序退役时，可以移走应用程序视窗。在一些实施例中，只有当某些条件成立时，才可以移走应用程序视窗。一个这样的条件是用户已经取消了应用程序视窗的部署。另一个条件是利用适当写特权把用户登录到应用程序服务器中。为了移去文件夹，用户必须首先移走所有文件夹应用程序视窗和子文件夹。然后，用户可以导航到控制台中的文件夹和移去或删除文件夹。

可以将应用程序整合配置数据存储在与商业进程管理(BPM)的数据相同的贮藏库中。因此，当移植BPM数据时，同一工具可用于移植应用程序整合。但是，对在目标环境下移植应用程序整合数据和部署移植数据可以作一些特殊考虑。当情况没有发生改变时，在应用程序服务器域与EIS之间移植应用程序整合数据可以是直截了当的。但是，如果EIS情况发生改变，可能需要遵从特定过程，以便确保目标环境下的工作解决方案。

在一些情况中，当所涉及的EIS情况发生改变时，最好在应用程序服务器域之间移植应用程序整合数据。这种类型移植的一个例子涉及在应用程序整合的不同域的贮藏库之间移动应用程序视窗定义。在这种情况下，只有应用程序整合域发生改变，但在应用程序视窗中涉及的目标EIS事例保持不变。这里，使用输入/输出实用程序可以使移植数据变得简单。对于BPM，这可以涉及从源域中的BPM输出软件包，和把那个软件包输入到目标域中的BPM。

XML

可扩充标记语言(XML)是用于编码数据的自描述、可扩充、基于文本的格式的工业标准。XML提供了可以扩充成供任何垂直应用程序使用的通用数据格式。由于XML是专门为万维网开发的，它迅速地被接纳为用于交叉企业数据交换的语言。由于XML是通用的，对于内部和外部企业整合，将它用作在具有不同本机语言的两个或更多个组之间通信的语言是有道理的。通过使用XML，企业对于可以用于促进交叉企业整合的内部和外部数据，可以具有共同格式。应用程序整合的第一次浪潮缺乏数据和元数据的共同表示法。XML提供了两者。

应用程序视窗可以接受XML文档和为服务返回XML文档，并且可以把事件公布成XML文档。即使EIS系统不了解XML或把它用作本机数据格式，这种功能也可用在降低EIS的复杂性中。XML是一种更易于用在整合情节中的格式。应用程序视窗和适配器可以一起工作，给出EIS的XML界面。

在整合环境下，几乎所有消息都可以作为XML文档来发送。对于每种服务，应用程序视窗可以要求XML请求消息和提供XML响应消息。当生成事件时，登记的事件收听器可以接收作为XML的事件信息。应用程序视窗可以依赖于它的适配器将EIS专用格式翻译成XML和从XML翻译成EIS专用格式。

使用应用程序视窗可以使把现有企业应用程序展示成接受作为输入的XML数据和返回作为输出的XML数据的商业服务成为可能。把XML用作公用格式来表示企业数据使得以相似的方式对待不同系统成为可能。从商业分析者的角度来看，与SAP系统整合和与Siebel系统整合之间的一个基本差异是XML消息的内容。可以使整合的系统的技术细节是透明的，从而使商业分析者能够把注意力集中在被调用来解决商业问题的商业服务上。

XML模式

每个应用程序视窗可以把XML模式用作元数据来描述事件、服务请求、和服务响应的XML数据。这种元数据可以帮助用户了解任何应用程序视窗事件或服务的数据要求。应用程序视窗可以把描述应用程序视窗展示的服务的数据要求的XML模式提供给它的客户机。

J2EE连接器结构

在应用程序整合市场中广泛采用的标准的缺乏正通过引入诸如J2EE连接器结构和Java消息传送服务(JMS)之类的标准得到解决。JMS提供了与消息传输机构的标准编程界面。J2EE连接器结构为应用程序适配器提供了标准。J2EE连接器结构适配器可以在支持J2EE连接器结构标准的任何整合服务器内运行。

诸如J2EE连接器结构之类的标准的采用使成包应用程序销售商可以构造在任何顺从性应用程序服务器内工作的应用程序适配器。但是，该结构是只解决低级整合问题的新标准。例如，连接器结构是单向的，便于从整合服务器到外部应用程序的同步通信。但是，连接器结构不规定外部应用程序如何可以异步地把数据发送到整合服务器。它既不为应用程序适配器提供任何公用的或所需的界面，也不规定如何编码在适配器和应用程序之间传递的数据。

像事件、接收XML、返回XML、和自描述可用服务/事件那样的基本服务不是在J2EE连接器结构中得到解决。这对使用根据本发明一个实施例的应用程序视窗是一个优点。

J2EE连接器结构也未能在商用级上解决应用程序整合。基于本发明的应用程序框架通过为商业进程级整合和框架整合服务器与外部应用程序之间的双向数据流提供支持，把值加入连接器结构中。商业级视窗可以在由事件和服务组成的连接器结构的顶部实现。一个事件可以是通过，譬如，应用程序适配器从应用程序到框架服务器的、通过JMS异步传送的消息。一种服务可以是任何商业进程可以通过应用程序适配器调用的应用程序提供的功能。

商业进程管理(BPM)

使用在企业商业进程中的应用程序视窗的一种方式是在BPM下设计工作流。BPM可以为设计商业进程工作流提供基于GUI的环境。这些工作流可以包括利用应用程序整合定义的应用程序视窗服务和事件。

在使用BPM的工作流中可以存在至少四种使用应用程序视窗的方式。在第一种情节中，建立调用应用程序视窗服务的任务节点。在第二种情节中，建立等待来自异步应用程序视窗服务的响应的事件节点。在第三种情节中，创建由应用程序视窗事件启动的工作流。在第四种情节中，建立等待应用程序视窗事件的事件节点。如果BPM没有被使用，使用企业中的应用程序视窗的一种可选方式是写入实现商业进程的定制Java代码。

对于实现的每个商业进程，有必要决定实现方法。虽然利用BPM可以将任何商业进程当作工作流来实现，但是如果商业进程是简单的和/或是专门的，应该只定制编码该商业进程。

一般说来，BPM应该用于实现某些情况下的商业进程。使用BPM来实现商业进程是有利的一种情况发生在实现需要复杂的错误管理、持久的处理、和精细的条件转移的时候。例如，如果商业进程接收事件，只选择一小组事件，进行复杂的转移行动，然后，生成许多复杂消息和把消息发送到各种应用程序服务器客户机，那么，使用BPM来实现商业进程是有利的。

当只需要把偶然改变变成商业进程时，也可以使用BPM。BPM可以减少编译/测试/调试循环的次数。当像在大多数机构中那样，开发者既重要又稀缺时，也可以使用BPM。

在用户在BPM下调用应用程序视窗服务或接收应用程序视窗事件之前，某些先决条件能够得到满足。首先，用户已经创建了应用程序视窗和定义了应用程序视窗的服务和事件。此外，应用程序视窗和它的适配器可以起作用和得到保存。如果用户正计划从运行工作流中调用应用程序视窗服务和事件，还应该部署应用程序视窗。BPM和应用程序整合这两者应该正在运行，并且应该装载应用程序整合插入小程序。用户应该拥有有关定义的工作流的任何所需商业逻辑关系的信息。这个信息可以来自，例如，商业分析者。此外，可以打开工作流模板定义。

在为企业创建了必要应用程序服务和事件之后，用户可以使用那些应用程序视窗来执行商业进程。BPM可以用于设计使用应用程序视窗服务和事件的商业进程工作流。BPM可以为设计商业进程工作流提供基于GUI的环境。这些工作流可以包括利用应用程序整合定义的应用程序视窗服务和事件。

在BPM下存在至少四种使用应用程序视窗服务和事件的主要方式。一种方式是建立调用应用程序视窗服务的任务节点。另一种方式是建立等待来自异步应用程序视窗服务的响应的事件节点。另一种方式涉及创建由应用程序视窗事件启动的工作流。最后，可以建立等待应用程序视窗事件的事件节点。这些情节可以相互组合在一起用于创建个性化工作流。

事件路由器

应用程序编程界面(API)可以用于与XML文档交互，譬如把基本数据放置在XML文档上。如果新客户处在EIS系统中，可以存在诸如客户名和地址之类与客户有关的信息。事件发生器可以完成将事件“邮寄”给事件路由器的“邮寄”事件。事件路由器可以将事件从事件发生器传送到应用程序整合服务器，以便应用程序整合服务器可以通知为那个事件登记的收听器。事件路由器可以知道如何与应用程序整合服务器通信。

事件路由器可以位于与主服务器或应用程序服务器不同的服务器。由于与SAP系统紧密耦合的某种东西可能继续与SAP系统，而不是与主服务器保持密切联系，所以这可能是普通情节。

事件路由器可以利用“事件消息”的“公布”调用，向应用程序整合服务器公布事件消息。然后，可以向应用程序视窗主题栏公布这个消息。一旦这个主题栏接收到事件，它就可以将客户机通知登记的事件收听器。这可以全部，至少一部分基于JMS/XML标准。

应用程序视窗生命周期

图5是显示根据本发明一个实施例的应用程序视窗的生命周期的图形。最初，需要创建应用程序视窗500。用户可以在父辈名称空间内创建应用程序视窗和为新应用程序视窗提供名称。一旦应用程序视窗存在，它就可以存在需要作出和保存到贮藏库的编辑502。存储器内对象的状态可能还没有与贮藏库中对象的永久状态匹配。由此处，用户可以保存应用程序视窗504和/或部署应用程序视窗506，应用程序视窗可以自动保存。可选地，用户可以请求删除应用程序视窗508和确认请求。用户可以通过，例如，从名称空间浏览器中挑选一个和指示要编辑应用程序视窗，编辑现有应用程序视窗。如果用户请求编辑应用程序视窗，那么，可以发生转换，在这种情况下，在提醒用户和用户确认之后，取消应用程序视窗的部署。

应用程序视窗可以适合于供运行时客户机使用。对于可以为对应用程序视窗的请求服务的应用程序视窗，应用程序视窗可以含有带有所分配资源的容器。运行时客户机可以从应用程序视窗容器中获得这个应用程序视窗的事例，并且调用它的服务和收听它的事件。应用程序视窗的生命周期内的其它步骤包括定义应用程序视窗和使用应用程序视窗。当定义应用程序视窗时，可以在加入服务和/或事件之前配置通信参数。应用程序视窗的服务和事件可以展示应用程序的特定功能。应用程序视窗的通信参数可以支配应用程序视窗将如何与目标EIS连接。

定义应用程序视窗可以包括诸如为应用程序视窗输入唯一名称和配置建立应用程序视窗和应用程序本身之间的网络连接的参数之类的任务。其它任务可以包括配置建立应用程序视窗和应用程序之间的网络连接的参数，以及配置应用程序专有的参数、应用程序视窗用于负载均衡的参数、和用于管理适合于应用程序视窗的连接库的参数。另一个任务可以涉及为应用程序视窗的用户定义安全特权。

在定义了应用程序视窗之后，可以将它部署在应用程序服务器上。部署的应用程序视窗可以用于实现商业进程工作流中的企业商业进程。在使用了商业进程工作流中的应用程序视窗之后，最后结果是那个企业商业进程的部署的电子表示。工作流可以规定应用程序如何相互交互以完成商业进程。应用程序视窗本身可以进行事件处理。

当为适配器定义应用程序视窗时，可以在寄存应用程序视窗的应用程序服务器和特定EIS应用程序之间创建基于XML的界面。定义应用程序视窗至少可以涉及几个基本步骤，包括为应用程序视窗命名和配置连接参数。其它步骤可以包括把服务和事件加入应用程序视窗中，以及测试服务和事件。

编辑应用程序视窗

可以将现有应用程序视窗修改成计及定义错误、不完整定义、商业用途方面的改变、或底层应用程序连通性方面的改变。所得的应用程序视窗可以满足商业数据需求和可以与应用程序进行适当交互。为了编辑应用程序视窗，首先识别应用程序视窗和核实它是否存在是有必要的。技术分析者可以谋求主题专家的帮助，以便通过提供应用程序专门知识，和可能地，通过把应用程序或它的元数据修改成满足应用程序视窗的需要，帮助定义应用程序视窗。在一些实施例中，已经安装了技术分析者选择的应用程序的适配器，和已经安装了适当的基于JSP的设计时间GUI是有必要的。寄存适配器和设计时间界面的服务器也应该建好和正在运行。

基本流程和可选流程可以假设商业分析者、技术分析者、或主题专家在应用程序视窗的创建/定义期间都相互交互。但情况往往不是这样。在每个用户轮流审查应用程序视窗的当前状态的情况下，事件流可以采取让多条路径穿过事件流的形式，每条路径只代表单用户交互。

为了编辑应用程序视窗的服务和事件，技术分析者可以浏览应用程序的元数据树和识别代表事件或服务的适当元数据。然后，技术分析者可以创建适配器和它的设计时间界面能力专有的事件或服务。可以创建事件或服务定义和将它加入应用程序视窗中。定义所包含的内容可以是适配器专有的，但是定义可以包含事件适配器适当地生成在运行时所请求的类型的事件的足够信息。

系统实例

图6的简单例子显示了如上所述的一些特征的相互关系。这个图形显示了涉及把最初在Siebel系统或事例600中创建的客户加入SAP事件616中引起的示范情况。在本例中，在Siebel 600中创建新客户602。通过SiebelCode，通知Siebel专用事件适配器604和Siebel专用事件适配器604传递客户信息。事件适配器创建包含客户信息的基于XML对象，并且把事件通知Siebel应用程序视窗608。然后，Siebel应用程序视窗608把事件传递给商业进程612。商业进程612可以确定是否需要将客户信息复制到SAP系统616。商业进程612把客户的Siebel XML表示变换成SAP XML表示。然后，商业进程调用SAP应用程序视窗610提供的服务，SAP应用程序视窗610可以是与Siebel应用程序视窗608相同的整合框架606的一部分。SAP应用程序视窗610又调用SAP服务适配器614和传递XML消息，XML消息现在具有SAP适配器614可以了解的格式。SAP适配器614可以将XML消息转换成特定BAPI(商业应用程序编程界面)和可以调用SAP事件616。SAP 616可以处理请求，插入客户618，和返回SAP 616指定的客户号。

可以将应用程序视窗对象创建成含有反映它的商业用途名称和在描述它在商业的组织结构内的位置的名称空间内。所得应用程序视窗可以满足商业数据需求和可以进行与应用程序的适当交互。应用程序视窗的用户可以包括商业分析者、技术分析者、和主题专家。商业分析者可以决定应用程序视窗的商业用途是什么。技术分析者可以决定哪个应用程序最适合应用程序视窗的用途。技术分析者可以谋求主题(应用程序)专家的帮助，以便通过提供应用程序专门知识，和可能地，通过把应用程序或它的元数据修改成满足应用程序视窗的需要，帮助定义应用程序视窗。技术分析者选择的应用程序的适配器应该已经安装好，和适当的基于JSP的设计时间GUI也应该已经安装好。在创建新应用程序视窗之前，寄存适配器和设计时间界面的服务器也应该建好和正在运行。

在基本流中，技术分析者打开万维网浏览器和指向适配器设计时间界面的URL。技术分析者和商业分析者决定应用程序视窗属于哪个商业组织，和核实适当的应用程序视窗名称空间是否存在。这可以利用适配器设计时间界面的主页上的名称空间浏览器来完成。如果不存在合适的名称空间，可以利用名称空间浏览器创建它。

技术分析者和商业分析者商定应用程序视窗的名称。该名称可以反映应用程序视窗的商业用途。技术分析者可以在识别的名称空间内创建新的应用程序视窗和赋予它商定的名称。商业分析者给出应用程序视窗商业用途的简要描述和商业分析者把它打字到新应用程序视窗的描述字段中。如有必要，复核和编辑应用程序视窗的该组事件和服务。然后，技术分析者可以保存新的应用程序视窗。此时，可以保存应用程序视窗供以后使用，可以测试应用程序视窗，或者可以把应用程序视窗部署到运行时应用程序视窗引擎中。

适配器

正如上面所讨论的那样，可以将适配器开发成服务或事件适配器。服务适配器可以调用与它连接的企业系统中的特定功能。事件适配器可以将信息从企业系统传送到整合环境。对于每个应用程序视窗，商家可以将任何数量的服务和事件加入应用程序视窗定义中，以支持应用程序服务器和目标企业系统之间特定类型的交易。由于适配器可以将XML用于翻译应用程序的数据格式，商业分析者无需了解格式。如果商业分析者想要使用适配器，唯一必要的是知道如何定义和使用应用程序视窗。最好，由于所有适配器都可以将基于万维网的相似界面用于定义应用程序视窗，学会使用当前和未来适配器是轻而易举的。无论对于开发者来说还是对于商业分析者来说，XML都可以使应用程序整合变得顺畅。

J2EE规范当前不为EIS启动与应用程序服务器或客户机的通信提供指导原则。应用程序整合可以通过事件适配器的用户提供这种能力。应用程序视窗的另一个重要特征是支持双向通信的能力。J2EE规范当前不为EIS启动与应用程序服务器或客户机的通信提供指导原则。这种能力可以由事件适配器来提供。当被加入应用程序视窗中时，每个事件对应于特定企业应用状态。当特定事件被触发时，应用程序视窗可以从企业系统中提取有关事件的数据和将XML文档中的数据传送到整合环境。

当被加入应用程序视窗中时，每种服务可以代表企业系统中的特定功能。当应用程序视窗接收到映射到特定服务器的XML文档时，它利用服务适配器调用企业系统中相应功能。在一些实施例中，企业系统可以把响应发送给该服务。

商业方法

如果商业分析者或技术分析者利用适配器定义应用程序视窗，那么，可以为特定商业用途定制应用程序视窗。商业用途可以由商业分析者来定义。例如，如果为客户关系管理(CRM)系统定义有关适配器的“客户管理”应用程序视窗，只能加入与客户管理有关的服务和事件。可以创建包罗万象的应用程序视窗。由于可以为特定商业用途定制应用程序视窗，应用程序视窗可以比许多其它企业应用程序整合系统使用的“一个尺寸适合所有”方法工作得好得多。

应用程序能力的商业级视窗可以提供程序员和技术分析者之间的逻辑分离。例如，这种分离使技术分析者无需必须知道SQL就能够创建数据库中的记录。

部署应用程序视窗

当已经存在至少一个加入其中的事件或服务时，可以部署应用程序视窗。应用程序视窗可能需要在它的服务和事件可以被测试之前，以及在应用程序视窗用在应用程序服务器环境中之前部署。应用程序视窗部署可以把有关它的服务和事件的相关元数据放置在运行时元数据贮藏库中。部署使应用程序视窗适用于其它应用程序服务器客户机。然后，商业进程可以与应用程序视窗交互。

为了部署应用程序视窗，用户可以打开应用程序视窗控制台和从应用程序视窗管理页面中选择“部署”选项。为了使BPM或其它授权客户机能够异步地调用这个应用程序视窗的任何现有服务，用户可以启用异步服务调用。调用应用程序视窗服务的实体可以异步地继续它的进程，无需等待来自服务的响应。如果这个应用程序视窗含有事件，用户可以输入适配器的事件路由器的URL。用户还可以输入要供这个应用程序视窗使用的连接池的最小个数，例如，“1”。类似地，用户可以输入连接池的最大个数。在“最大池尺寸的目标分数”或类似字段中，用户可以输入，譬如，可能从0测量到1.0的理想池尺寸。例如，可以输入“0.7”的值。如果最大池尺寸是10和目标分数是0.7，这意味着适配器将进行试图将连接池尺寸保持在最大值的70％上，在这种情况下，意味着7个连接的负载均衡。为了自动地删除未用连接，用户可以选择使池可以缩小的选项。

在控制台的“日志配置”区域中，用户可以根据记录日志偏好，譬如，记录错误和审计消息日志；记录警告、错误、和审计消息日志；记录通知、警告、错误、和审计消息日志；和记录所有消息日志，选择选项。如果有必要，用户可以利用J2EE或其它适当安全措施限制访问。应用程序视窗“安全”页可以包括在控制台中，它可用于准许或取消用户对这个应用程序视窗的读写访问。当完成了设立许可之后，用户或团体可以选择申请改变。用户也可以选择在任何改变之后部署应用程序视窗。

例如，当用户想要编辑应用程序视窗的连接参数，加入服务和事件，或禁止客户机使用应用程序视窗时，可以取消应用程序视窗的部署。用户可以选择显示应用程序视窗的“总结”页面。为了从应用程序服务器中取消应用程序视窗的部署，用户可以选择“取消部署”选项。

当定义应用程序视窗时，用户可以配置它的连接参数。在加入和测试服务和事件之后，用户可能想要重新配置连接参数或除去服务和事件。为了编辑现有应用程序视窗，用户可以打开应用程序视窗和点击“总结”选项，或简单地显示应用程序视窗“管理”页面。由此处，用户可以重新配置应用程序视窗的连接参数或加入服务和事件。

同步方法

为了同步调用应用程序视窗，用户可以从适当的应用程序视窗控制台中选择“同步”选项。同步调用服务的节点可以被配置成在工作流可以继续下去之前，等待服务返回响应文档。如果节点打算异步调用服务，工作流将能够继续下去。对于要求存储响应的同步服务，用户可以从，譬如，响应文档变量列表中选择预定XML变量。当BPM接收到来自应用程序视窗服务的响应时，响应文档变量可以存储响应。如果用户不关心响应数据，用户可以让这个字段空着。

如果适不存在当的XML变量，用户可以选择创建新XML变量的选项。如果有必要检查响应文档的XML模式，用户可以观看响应定义。

异步方法

对于譬如，可能要求存储请求ID的异步服务，可以从应用程序视窗控制台中选择预定字符串变量。如果不存在适当的字符串变量，可以打开可以创建新字符串变量的“变量特性”对话框。当任务节点被建立成调用异步应用程序视窗服务时，可以将结果返回给BPM。工作流可以利用所选择请求ID变量识别这个响应。为了把事件节点设置成接收响应，应该将同一请求ID变量用于事件节点。

用户可能希望把事件节点设立成等待来自异步应用程序视窗服务的响应。在工作流中，无论什么时候一个动作异步调用应用程序视窗服务，应用程序视窗服务都将返回响应。通常，如果用户想要了解响应，用户可能想要把相应异步事件节点设立成等待响应。为了把异步事件节点配置成等待来自异步应用程序视窗服务的响应，可以创建把事件节点设置成等待像类型“异步响应”的事件那样的事件的事件节点。

在这个实施例中至少存在两种可以用于把事件节点设立成接收异步服务响应的基本方法。在第一种方法中，用户可以选择“响应文档”选项。当使用这种方法时，用户可以通过选择请求ID变量和响应文档变量接收异步服务响应。请求ID变量是字符串和响应文档变量具有类型XML。第二方法使用“异步变量”选项。当使用这种方法时，异步服务响应可以通过选择请求ID变量和异步服务响应变量来接收。请求ID变量是字符串和异步服务响应变量可以具有诸如“AsyncServiceResponse”之类的类型。优选方法可能是响应文档方法，因为它可以提供接收异步响应和同步响应两者的通用手段。当使用响应文档方法时，可以与响应是异步的还是同步的无关地接收XML文档。并且没有必要查询异步服务响应变量的值。

只要有可能，响应文档变量可以用于接收异步服务响应。无论什么时候“事件特性”对话框被设置成等待异步响应类型的事件，用户总可以选择使用异步变量来接收响应。如果编辑以前被设立成使用异步服务响应变量来接收响应的异步响应事件，那么，可以在事件特性对话框中显示两个选项：异步变量选项和响应文档选项。在这种情况下，用户可以选择两种方法之一来接收服务响应。

如果编辑没有使用异步服务响应变量的现有异步响应事件节点或创建新异步事件节点，事件特性对话框可以显示使用户可以把响应文档设置成接收服务响应的对话框。

尽管这个情节不管理在应用程序视窗服务响应中返回的错误，但用户可能想要管理特定用户工作流中的错误。为了管理在这些可能使用，例如，AsyncServiceResponse变量的工作流中的异步服务响应错误，用户可以使用包括在应用程序整合插件程序中的特征。基于本发明一个实施例的应用程序整合插件程序可以包括诸如AsyncServiceResponse之类的变量类型和诸如AIHasError()、AIGetErrorMsg()、和AIGetResponseDocument()之类的函数。

为了把异步事件节点设立成等待来自异步应用程序视窗服务的响应，可以将事件节点创建和设置成等待诸如“Al Async Response”的类型的事件。将事件节点设置成使用XML变量来接收异步服务响应的步骤可以包括首先打开工作流模板定义。如果不存在将等待来自指定应用程序视窗服务的异步响应的事件节点，用户可以创建一个事件节点。用户可以选择已经定义的字符串变量，和BPM将收听带有与这个变量匹配的ID的异步响应。

事件节点可以等待对一个动作，譬如，对工作流中较早时间异步调用的应用程序视窗服务的调用的响应。“调用应用程序视窗服务”动作可以设置请求ID变量。为了使该动作和这个事件节点一起工作，它们都可以使用同一个请求ID变量。

对于要求存储响应的异步服务，用户可以从，譬如，响应文档变量列表中选择预定XML变量。当BPM接收到来自应用程序视窗服务的响应时，响应文档变量可以用于存储响应。如果不存在适当的XML变量，用户可以创建新变量。接收异步服务响应的优选方法可能是使用类型XML的响应文档变量。但是，如果现有工作流包含事先被设置成使用AsyncServiceResponse变量来等待来自异步应用程序视窗服务的响应的异步事件节点，用户可以修改事件节点。

如果事件节点使用AsyncServiceResponse变量来接收异步服务响应，修改事件节点的一种方法使用如下步骤。打开工作流模板定义和选择异步变量类型。用户选择已经定义的字符串变量，和BPM收听带有与这个变量匹配的ID的异步响应。

回叫收听器

如果是长期服务，客户机可以选择异步调用服务。例如，一些SAP请求可以花费大约两三分钟来处理。请求的处理通常对客户机来说是透明的。如果用户正坐在网页前，他不希望将页面简单地“挂起”两分钟而什么也不做。最好发出一些响应，然后，一旦接收到适当响应，譬如，来自SAP新的消息，就更新网页。这就是将回叫收听器用于异步响应的一个理由。这样，客户机不需要必须处处等待响应，而是当回叫收听器接收到响应时，就通知它。

收听和接收事件是按照本发明的某些实施例的另一个有价值部分，因为在J2EE连接器结构下不寻址收听和接收事件。在EIS中可以出现触发，和外部应用程序可能需要了解触发器的启动。换句话说，会发生需要向外传送给某些应用程序的事件。可能还需要通知所有登记的收听器。

如前所述，客户机可以创建应用程序视窗和可以加入事件收听器。创建一旦接收到来自应用程序视窗的事件就知道该做什么的处理器。一个实施例中的应用程序视窗预订JMS主题栏和在那个主题栏上登记收听器。JMS主题栏是与收件箱类似，可以把JMS消息邮寄给它的JMS功能件。

可以定义称为“事件发生器”的一个对象，或应用程序整合部件。事件发生器的一项工作是监视EIS和与EIS通信，以确定事件发生的时间。对于DBMS适配器，这可以涉及到对升级表的查询。用户可以作出诸如“从事件中选择*”之类的请求。那个事件表中的任何记录将是DBMS中新事件的记录。事件发送器周期性地对EIS寻找新事件。

例如，当订单处理系统发现库存中的某个项目缺货，事件可以导致系统触发需要重新进货某个产品的通知。这个事件可以发生在，例如，EIS中。触发器可以用于DBMS。一旦在某个表上出现插入，触发器可以利用，例如，“插入事件中...”语句，启动和把有关新数据的信息放到事件表中。然后，一旦出现新事件，事件发生器就可以牵引那个事件。

安全性

用户可以通过以适当形式指定用户或组名。准许或取消用户的访问特权。每个应用程序视窗可以拥有至少两种类型的访问，包括读访问和写访问。读访问使用户可以进行服务和预订事件。写访问使用户可以部署/编辑/取消部署应用程序视窗。

如果有必要，可以在应用程序视窗上调用使安全级在在应用程序视窗上调用服务之前得到设置的方法。像“setConnectionSpec()”和“getConnec-tionSpec()”那样的方法可以用于利用“ConnectionSpec”对象为EIS设置证书。为了例示ConnectionSpec对象，可以在，譬如，ADK中提供像“ConnectionRequestInfoMap”那样的类。用户还可以实现由那个用户创建的那个类。如果用户创建了唯一类，用户可能需要包括某些界面，譬如，ConnectionSpec界面(JCA类)、ConnectionRequestInfo界面(JCA类)、映射界面(SDK类)、和串行化界面(SDK类)。

在实现ConnectionSpec类和例示ConnectionSpec对象之后，用户可以与setConnectionSpec()和getConnectionSpec()方法一起使用Connection-Spec。为了设置ConnectionSpec，用户可以传递适当初始化的ConnectionSpec对象。为了清除ConnectionSpec，用户可以传递带有零值的ConnectionSpec对象。

移植数据

由于相对于一个EIS事例定义的应用程序视窗可以包含那个EIS事例专有的标识符和数据，当在应用程序服务器域之间和在EIS的不同事例之间移植数据时，可能需要作出特殊考虑。这对于应用程序视窗使用的连接工厂也是同样正确的。用户也许不能够人工改变应用程序视窗或连接工厂中的EIS事例专用数据。但是，这些改变可以通过导航到所需的应用程序视窗和编辑应用程序视窗，从应用程序视窗控制台作出。用户可以识别和更新应用程序视窗，以及任何事件、服务和相关连接工厂中的所有EIS专用数据。

在目标环境下任何EIS事例专用引用都可以被对新EIS事例的引用所取代。具体地说，用户可以编辑应用程序视窗和连接工厂定义。应用程序视窗定义可能需要改变，譬如，可以通过应用程序视窗“部署”屏幕访问的“Event-RouterURL”或类似参数。在目标环境下这个参数可以用于引用事件路由器。也可能需要对服务定义中的参数加以改变。这些可以是引用EIS事例专用数据的适配器专用数据。编辑功能件可以用于为服务改变任何EIS事例专用参数。还可能需要改变事例定义参数，这些参数包含引用EIS事例专用数据的适配器专用数据。每个适配器可以把不同特性放入服务和事件中。

与事件和服务适配器一起，ADK设计时间框架可以提供建造适配器用户需要定义、部署、和测试他们的应用程序视窗的基于万维网GUI所需的工具。尽管每个适配器可以具有EIS专用功能，但所有适配器需要部署应用程序视窗的GUI。这个框架可以使创建和部署这些界面所需的努力最小化。这种最小化至少部分地可以利用两个基本部件来完成。这些部件之一是使用户可以利用，例如，Java服务器页面(JSP)建造基于HTML的GUI的万维网应用程序部件。这个部件可以通过诸如JSP模板、标签库、和JavaScript库之类的工具得到扩大。第二个部件是可以为在应用程序服务器上部署、取消部署、和编辑应用程序视窗提供简单API的部署帮助程序部件或请求处理器。

虽然应用程序视窗可以代表与应用程序中的特定功能的商业级界面，但适配器可以代表与应用程序中的所有功能的系统级界面。应用程序视窗可以为单个商业用途而配置，并且可以包含与那个商业用途有关的服务。这些服务只能要求要在请求文档中指定的商业相关数据和只返回响应文档中的商业相关数据。应用程序视窗可以将这个商业相关数据与适配器所需的存储元数据组合在一起。适配器可以取出商业相关数据和存储元数据，并且可以执行应用程序上的系统级功能。

应用程序视窗可以表示支持商业用途的事件和服务。这可以使商业用户为了与应用程序的所有通信而与应用程序视窗通信。这种双向通信可以受事件适配器和服务适配器支持。应用程序视窗可以使用户注意不到这个事实，并且把与应用程序的统一商业界面呈现给用户。

一个事件可以是当在EIS内出现感兴趣事件时，应用程序视窗公布的XML文档。想要得到事件通知的客户机可以利用应用程序视窗登记它们的兴趣。应用程序视窗起目标应用程序和客户机之间的中介器的作用。当客户机已经预订了应用程序视窗公布的事件时，无论什么时候在目标应用程序内出现感兴趣事件，应用程序视窗都会通知客户机。当通知事件订户已经发生感兴趣事件时，传递描述事件的XML文档。公布事件的应用程序视窗还可以把可公布事件的XML模式提供给客户机。应用程序视窗代表与应用程序中的特定功能的商业级界面。

服务可以是应用程序视窗展示的应用程序内的商业操作。服务可以作为请求/响应机构存在。当应用程序接收到调用商业服务的请求时，应用程序视窗可以在它的目标应用程序内调用那种功能，和返回或回复描述结果的XML文档。

为了定义服务，用户可能需要确定和定义输入需求、输出预期、和交互规范的内容。

当应用程序视窗得到部署时，它可以具有相关J2EE连接器结构CCI连接工厂部署。例如，如果用户部署abc.xyz应用程序视窗，应用程序整合可以部署新ConnectionFactory和将它与JNDI定位ConnectionFactoryInstance结合。为了有效起见，新连接工厂部署可以使用设置在weblogic-ra.xml部署描述符中的<ra-link-ref>。

<ra-link-ref>元素可以便于多个部署连接工厂与单个部署适配器的逻辑联系。带有识别分离部署的连接工厂的值的可选<ra-link-ref>元素的规范可以导致这个新部署的连接工厂与所提及的连接工厂共享已经部署的适配器。另外，除非得到指定，在提及的连接工厂的部署中定义的值可以被这个新部署的连接工厂继承。适配器逻辑名可以用作<ra-link-ref>元素的值。

设计时间特征

设计时间开发可以具有它自己的特征，这些特征可以不同于与运行时适配器开发相联系的那些特征不同。例如，设计时间GUI可以由，例如，一组10个Java服务器页面(JSP)组成，JSP是调用Java服务小程序以请求事务处理的HTML页面。对于用户来说，JSP看起来与任何其它网页一样。包括设计时间GUI的JSP可以包括，例如：

display.jsp-显示页面，也称为适配器网页；这个页面可以包含创建应用程序视窗的外视感觉所需的HTML

login.jsp-适配器设计时间登录页面

confconn.jsp-确认连接页面；这个页面可以为用户指定EIS的连接参数提供格式

appvwadmin.jsp-应用程序视窗管理页面；这个页面可以提供取消部署的应用程序视窗的总结

addevent.jsp-添加事件页面；这个页面可以使用户把新事件加入应用程序视窗中

addservc.jsp-添加服务页面；这个页面可以使用户把新服务加入应用程序视窗中

edtevent.jsp-编辑事件页面是可以使用户编辑事件的可选页面

edtservc.jsp-编辑服务页面是可以使用户编辑服务的可选页面

depappvw.jsp-部署应用程序视窗页面；这个页面可以使用户指定部署特性

appvwsum.jsp-总结页面；这个页面可以显示有关应用程序视窗的信息，包括部署/取消部署状态；连接准则；诸如共享配置、日志级别、和安全性之类的部署信息；事件列表；和服务列表。

JSP模板

设计时间框架可以为适配器提供迅速地汇集万维网应用程序以定义、部署和测试新应用程序视窗的JSP模板。模板是Java服务小程序根据在HTTP请求中提供的参数动态生成的HTML页面。模板可以用于使定制页面的个数最小化和定制万维网应用程序所需的HTML。模板可以提供部署应用程序视窗所需的大多数HTML格式。在许多情况下，只有定制格式才可以包括收集EIS专用连接参数的格式、收集加入事件所需的EIS专用信息的第二格式、和收集加入服务所需的EIS专用信息的第三格式。另外，可以为浏览EIS的元数据目录而供应定制JSP。

模板还可以对Java平台的国际化和本地化特征起到杠杆作用。万维网应用程序中每个页面的内容被存储在消息束中。因此，可以使适配器的万维网界面迅速国际化。模板还可以使外视感觉集中在单个位置上。

使用命名惯例

命名惯例可以用于设计时间万维网应用程序和连接器部署。当把.ear文件部署到整合系统中时，通过把适配器逻辑名用作文件名，可以将文件标识成诸如config.xml之类的配置文件。这可以通过，例如，如下程序来完成：

＜Application Deployed＝“trueName＝“ALN”

        Path＝“WLI_HOME/adapters/ADAPTER/lib/ALN.ear”＞

        ＜ConnectorComponent Name＝“ALN”Targets＝“myserver”

             URI＝“ALN.rar/”＞

        ＜WebAppComponent Name＝“ALN_EventRouter”

             Targets＝“myserver”

             URI＝“ALN_EventRouter.war”/＞

        ＜WebAppComponent Name＝“ALN_Web”

             Targets＝“myserver”URI＝“ALN_Web.war”/＞

    ＜/Application＞

可选地，名为webcontext.txt的文本文件可以包括在.ear文件的根部。诸如webcontext.txt之类的文件可以用于包含适配器的设计时间万维网应用程序的范围。这个文件可以用UTF-8格式编码。

上面为了例示和描述的目的提供了对本发明优选实施例的描述。它的目的不是穷尽的，或使本发明局限于所公开的确切形式。对于本领域的普通技术人员来说，许多修改和改变是显而易见的。选择和描述这些实施例是为了最好地说明本发明的原理和它的实际应用，从而使本领域的其它技术人员能够透过各种实施例和适合于所设想的特定使用的各种修改理解本发明。本发明的范围是通过所附的权利要求书和它的等效物来限定的。

Claims

1.一种整合应用程序的系统，包括：

资源适配器，适合于调用第一应用程序中的功能并展示那个功能；和

应用程序视窗部件，适合于提供第二应用程序通过资源适配器访问第一应用程序的途径。

2.根据权利要求1所述的系统，其中：

应用程序视窗部件还适合于提供在第二应用程序不知道有关第一应用程序的功能细节的情况下第二应用程序访问第一应用程序的途径。

3.根据权利要求1所述的系统，其中：

应用程序视窗部件是聚焦于商业的界面。

4.根据权利要求1所述的系统，其中：

应用程序视窗部件向第一应用程序中的服务和事件提供自描述界面。

5.根据权利要求1所述的系统，其中：

应用程序视窗部件适合于展示第一应用程序中作为商业服务的功能。

6.根据权利要求1所述的系统，其中：

应用程序视窗部件专用于资源适配器。

7.根据权利要求1所述的系统，其中：

应用程序视窗部件适合于为第一应用程序定义一组商业功能。

8.根据权利要求1所述的系统，其中：

资源适配器适合于调用构成企业系统的第一应用程序中的功能。

9.根据权利要求1所述的系统，其中：

应用程序视窗部件适合于允许第一应用程序与第二应用程序之间的双向通信。

10.根据权利要求1所述的系统，其中：

应用程序视窗部件将在第一应用程序与第二应用程序之间解释消息。

11.根据权利要求1所述的系统，其中：

应用程序视窗部件还包括用于第二应用程序的Java界面，其中，第二应用程序包括可以使用应用程序视窗部件的Java应用程序。

12.根据权利要求1所述的系统，其中：

应用程序视窗部件是无状态会话豆。

13.根据权利要求1所述的系统，还包括：

商业进程管理部件，适合于使应用程序视窗部件作为商业服务得到调用。

14.根据权利要求1所述的系统，还包括：

万维网服务界面，适合于与应用程序视窗部件一起使用，使万维网服务通过应用程序视窗部件得到调用。

15.根据权利要求1所述的系统，还包括：

整合框架，适合于寄存应用程序视窗部件。

16.根据权利要求15所述的系统，其中：

整合框架包括可以用于创建应用程序视窗部件的图形用户界面。

17.根据权利要求15所述的系统，其中：

应用程序视窗部件提供资源适配器与适配器展示的功能的使用之间的分离层。

18.根据权利要求1所述的系统，其中：

应用程序视窗部件适合于使与应用程序的数据相对应的整合点得到定义。

19.根据权利要求18所述的系统，其中：

应用程序视窗部件还适合于使整合点通过商业语义学得到组织。

20.根据权利要求1所述的系统，其中：

应用程序视窗部件是基于XML的界面；和

其中，第一程序是企业系统；和

其中，第一程序是应用程序服务器。

21.根据权利要求1所述的系统，还包括：

第二应用程序视窗部件，适合于提供第三应用程序通过资源适配器访问第一应用程序的途径。

22.根据权利要求1所述的系统，其中：

应用程序视窗部件还适合于展示作为逻辑商业功能的第一应用程序的每种服务。

23.根据权利要求1所述的系统，其中：

应用程序视窗部件还适合于提供描述与企业系统交互的过程的元数据。

24.根据权利要求23所述的系统，其中：

应用程序视窗部件以XML模式的形式提供元数据。

25.根据权利要求1所述的系统，其中：应用程序视窗适合于展示由下列内容组成的小组中选择的特征：向外消息、返回消息的向内请求、和可以向外发送或向内处理的消息的描述的视窗。

26.根据权利要求1所述的系统，还包括：

应用程序视窗控制台，适合于为访问应用程序视窗部件提供用户界面。

27.根据权利要求1所述的系统，还包括：

用于应用程序视窗部件的容器，该容器含有分配给可以服务于请求的应用程序视窗部件的资源。

28.根据权利要求1所述的系统，其中，资源适配器是从由服务适配器和事件适配器组成的小组中选择出来的。

29.一种更新数据库中的记录的方法，包括下列步骤：

利用应用程序视窗部件来接收XML消息，以调用更新方法，该更新方法包含更新数据库记录的SQL语句；

从应用程序视窗部件中调用资源适配器和把SQL语句传递给资源适配器；

利用资源适配器访问企业系统中的企业数据和把结果返回给应用程序视窗部件；和

返回来自应用程序视窗部件的结果作为响应XML消息。

30.一种定义应用程序视窗部件的方法，包括下列步骤：

为企业系统开发资源适配器；

确定受应用程序视窗部件支持的进程；

通过收集要与某些商业进程一起使用的有关来自商业分析者的应用程序商业要求的信息，确定要包括在应用程序视窗部件中的服务和事件的类型，一旦必要的进程得到确定，就可以定义和测试适当的服务和事件。

31.一种整合应用程序的系统，包括：

调用第一应用程序中的功能的装置；和

向第二应用程序展示那种作为商业服务的功能的装置。

32.一种整合应用程序的方法，包括下列步骤：

提供资源适配器以展示应用程序中的功能；和

为资源适配器提供界面，以调用作为商业服务的所展示功能。

33.一种整合应用程序的系统，包括：

降低底层应用程序的复杂性的装置；和

提供对底层应用程序中的功能的访问的装置。

34.一种计算机可读媒体，包括：

调用第一应用程序中的功能的装置；和

向第二应用程序展示那种作为商业服务的功能的装置。

35.一种由服务器计算机执行的用于整合应用程序的计算机程序产品，包括：

调用第一应用程序中的功能的计算机代码；和

向第二应用程序展示那种作为商业服务的功能的计算机代码。

36.一种整合应用程序的系统，包括：

调用第一应用程序中的功能的装置；和

向第二应用程序展示那种作为商业服务的功能的装置。

37.一种计算机系统，包括：

处理器；

由所述处理器执行的目标代码，所述目标代码被配置成：

调用第一应用程序中的功能；和

向第二应用程序展示那种作为商业服务的功能。

38.传输媒体中记录的计算机数据信号，包括：

包括调用第一应用程序中的功能的指令的代码段；和

包括向第二应用程序展示那种作为商业服务的功能的指令的代码段。