服务器软件组件

HTTP 服务器可以是 HTTP Server (由 Apache 提供支持) 或商用 HTTP 服务器 (如 IIS)。HTTP Server 会随同 Windchill 一起提供。其他 HTTP 服务器可单独购买。各 Windchill 服务器主机上必须存在 HTTP 服务器。Web 服务器会提供 HTML 页面和 Java 类，并授予对 Windchill HTTP 网关 (请参阅本节稍后的说明) 的访问权限，该网关指进程内的 Java servlet。

Windchill 通过 web 服务器的用户验证功能，利用内置于 web 浏览和服务器中的改进验证标准。其中包括 HTTP 1.0 基本验证、HTTP 1.1 消息摘要验证、数字证书验证、Windows/NT 询问-响应验证和其他验证。因为 Windchill 是以 Web 为中心的，应务必利用服务器的用户验证，而不是由于使用未与客户机环境集成的旧验证方案而使安全性有漏洞。例如，站点使用的是 web 服务器，而且此服务器支持基于 LDAP 的集中式用户和访问管理，则该站点将自动与 Windchill 集成，进行用户验证，而不维护另一组用户首选项。

通过配置受保护的 Windchill HTTP 网关实例可实现集成。客户端将向此 URL 发送会话登录请求。直到用户满足了 Web 服务器的用户验证需求时，该服务器才允许访问。通常在此过程中，服务器将返回对客户端浏览器 (标识所要求的验证方案) 的未授权响应。然后可能在提示用户输入密码之后，浏览器使用合适的验证标题重新发送请求。

只有在 web 浏览器和 web 服务器完全确定用户身份后才能与 Windchill 连接。仅在此时它才会收到会话登录请求以及经过验证的用户身份。

有关验证和自定义验证方法的详细信息，请参阅位于 Windchill 帮助中心“基本自定义”和“高级自定义”区域的自定义信息。

HTTP 网关是作为 servlet 执行的 Java 应用程序。客户端浏览器和 Windchill 服务之间是通过它来进行初始连接的。HTTP 网关位于 Embedded Servlet Engine (嵌入在方法服务器中) 内，用作在 HTTP 服务器 (Web 服务器) 和 Windchill 方法服务器之间传送请求和响应的通路。

HTTP 网关调用特殊方法来处理 HTTP 请求。由 web 服务器设置的请求标题 (或 CGI 特性) 与任何提交的数据一起被传送到 Windchill 方法服务器。调用的方法根据提交的数据确定请求的内容。它将委派给相应的子方法以生成 HTTP 响应，通常采用的响应形式为 HTML 页面。

大多数传送至 HTTP 网关的请求均来自 HTML 浏览器窗口，或者源自所显示静态 HTML 页面中的嵌入式链接。

因为两个系统中的 Java 类不能直接通信，因此这是用于链接联合系统的基本机制。在标准 Web 浏览器的 HTML 窗口中显示来自多个 Windchill 系统的页面时允许客户端浏览器成为星型配置的中心。通过对 HTTP 网关编制适当的 GET 请求，并在 Web 浏览器 HTML 窗口内选用框架来提交这些请求，可在系统之间转发请求。

HTTP 网关是通过 HTTP GET 或 POST 请求来访问的。A Windchill URL 通常采用以下形式：

<类名> 和 <方法名> 由方法服务器使用，以发送对特定处理方法的请求，而 <参数> 是一个 URL 编码的查询字符串。该查询字符串用于提供特定于所调用方法的其他数据，如对象 ID。使用 POST 请求时，还可能在 POST 请求的正文中提供其他数据。

此数据范围较广，可以从简单 URL 编码的 HTML 表单数据到由多个部分组成的 MIME 邮件 (包含一个或多个文件的全部内容)。无论哪种情况下，目标类都将负责形成 URL，而目标方法应知道所需的内容。

许多目标方法都接受 GET 和 POST 请求，并需要 GET 请求的查询字符串或 POST 请求的主体，以包含 URL 编码的表单数据。这是标准编码，如果向 Web 服务器提交简单的 HTML 表单，就会产生这种编码。它允许使用 HTML 表单作为这些方法的测试驱动程序。

基本上，URL 编码的表单数据发送任意的“名称=值”对，由问号 (?) 分隔开来。所有空格都由加号 (+) 代替，所有特殊字符都按十六进制转换成 %dd 格式，其中 dd 是代表原字符的十六进制 ASCII 值。

建立已经验证的用户凭证时要使用 HTTP 网关。通过配置两个相同的 HTTP 网关即可完成此操作：一个是公共网关，另一个是受 Web 服务器用户访问控制保护的网关。当 Java 客户程序需要核实有效的凭证 (以便对 Windchill 方法服务器执行安全 RMI 调用) 时，它通过受保护的 HTTP 网关提交登录请求。Web 服务器向 HTTP 网关提供已验证的用户名和验证类型后，该信息将被传送到 Windchill 方法服务器。

HTTP 网关是向 Windchill 方法服务器传送请求，并通过 HTTP 服务器返回响应的通路。响应的内容通过在 Windchill 方法服务器中使用的方法进行控制。为了管理一个或多个 Windchill 系统的 HTML 浏览器窗口和独立的 Java 窗口，这些方法可能在响应中使用了复杂的 JavaScript (或 Jscript)，因而显示出无缝集成的环境。

要利用 web 浏览器的功能查看、保存和操作各种内容类型，必须使来自 Windchill 系统的文件内容能够连续通过 HTTP 网关传输至浏览器。如下图所示，文件传送请求被编码为对服务器 HTTP 网关的相应 HTTP 请求。然后，将这些请求发送到 Web 浏览器的 HTML 窗口内的框架中，以提交这些请求并接收响应。

在 Windchill 方法服务器中，HTTP 响应是使用流式界面生成的，允许响应可以任意大。如下所示，这是通过调用一种方法来实现的，该方法从 RMI 的答复封送中生成响应，以使该响应可直接写到 RMI 结果封送流中。这样就使所有文件可直接从数据库中连续取出，而无需将文件暂时保存在磁盘或内存中。

在下图中，上载流使用 HTTP POST 请求，以类似的方式执行。这种情况下，读取上载内容的方法是从 RMI 参数封送中调用的，这样就可直接从 RMI 参数封送流中进行读取。

服务器管理器是运行在每个服务器主机上的 Java 应用程序。其主要作用是管理一组方法服务器，此外还维护用户会话凭证，并管理后台处理和其他系统管理功能。

在每个 Windchill 服务器主机上都有一个服务器管理器实例。它在自己的 Java 虚拟机 (VM) 中运行，并且必须针对考虑使用的 Windchill 系统来运行。由于此进程必须一直运行，故可将此进程看作是 Windchill 后台程序。

运行多个服务器 VM 并不是 Java 体系结构的要求。Windchill 实施此体系结构是出于对可靠性和可伸缩性的考虑。当单个 VM 中的共享资源争用成为限制因素时，可以使用多个方法服务器，以减少单个VM无法充分使用高性能的多处理器硬件这种情况。通过使用多个进程，系统本身处理大量事务处理的能力可超过单个 VM 的集合。

例如，如果给定的类型 II (本机方法) JDBC 驱动程序执行时在一些并发的 DB 事务处理线程中开始显示同步瓶颈，则使用第二个方法服务器可使系统处理并发事务的能力加倍。

这种体系结构特性还提高了可靠性，因为方法服务器与服务器管理器不同，方法服务器将执行由非 Windchill 编程人员开发的自定义 Java 代码。Java VM 提供非常可靠的、线程安全的环境，使错误代码很难影响其他线程，但仍可能出现一些不稳定情况，如内存消耗或资源死锁。此外，在数据库界面或其他应用程序特定界面中，方法服务器可能会使用本机 (非 Java) 存储库。这些本机存储库可能包含一些错误，会导致整个 VM 不稳定。通过在各个 VM 中分别保留 Windchill 系统后台程序 (服务器管理器) 和方法服务器的实例，个别方法服务器可终止运行，而不会使 Windchill 系统不可用或丢失用户验证信息。

通过最大限度地降低方法服务器和服务器管理器，以及客户端和服务器管理器之间所需的进程间通信，可解决性能问题。客户端使用服务器管理器绑定到方法服务器一次后，它们便可直接调用该方法服务器。如果该方法服务器以后变得不可用 (终止) 了，则自动例外处理机制会透明地将客户端重新绑定到一个新的方法服务器。

Windchill Java 客户端使用 Java RMI 与 Windchill 服务器进行通信。要使用 RMI，客户端必须首先获取对远程对象的引用，以便调用方法。Java RMI 运行时通过使用“启动注册表对象”来开始此操作，客户端有构建此对象的内置功能。这样，客户机就可对注册表进行查询，并可收到对远程对象的其他引用。

为降低系统的复杂性并减少客户端与服务器之间的网络连接的数量，Windchill 在服务器管理器中使用可配置的端口号来运行自己的注册表对象。此注册表中唯一注册的对象是已安装的本机服务器管理器。其他 Java RMI 应用程序不共享此注册表，而且 Windchill 不依赖任何其他 Java RMI 应用程序可能正在使用的注册表。

与默认的 RMI 注册表建立方式不同，服务器管理器内部使用的注册表允许对客户端连接进行超时处理，这样可以提高多用户环境中系统的可缩放性。这种灵活性要求对作为 Windchill 系统内部组成部分的启动注册表加以控制。

Windchill 服务器管理器的主要用途是按照需要将客户端引荐给方法服务器。为了获得更好的可靠性和可缩放性，Windchill 体系结构将服务器管理器 VM 与方法服务器 VM 分开。客户端调用服务器管理器，以获得对方法服务器的引用，然后就尽量直接与该服务器通信。当有多个方法服务器可用时，服务器管理器将返回多个引用，以便在可用的服务器中分配负载。

客户端上用于获取方法服务器引用的协议被封装到调用远程方法的类中。该协议包含对网络故障和服务器管理器重新启动的容错能力，Windchill 自定义者一般从不直接访问它。

服务器管理器负责维护方法服务器。

服务器管理器根据需要将方法服务器作为子进程执行。负载较高时，如果出现利用率下降，它就会在管理阈值的一定范围内扩展可用服务器的 Pool。

通常，所有的 Windchill 方法服务器都是平等地创建的。它们都是同一实现过程的实例，该实现过程动态装载必需的 Java 类，以执行从客户端收到的请求。但是，为了满足专业服务器可能的独特管理需求 (例如由于特定应用程序的本机库所造成的限制)，服务器管理协议允许分配独特的服务名称，来控制管理阈值和方法服务器的启动参数。

多数生成的界面都是调用默认方法服务，但您也可以构建请求特定服务名的自定义界面。

有时在系统执行操作时需要不与终端用户直接连接。定期 (基于一定时间) 活动以及由用户操作触发的操作 (但在这种情况下用户不等待) 即属于这种情况。例如，执行一项操作，以将对象升级到新的生命周期状态。此生命周期状态的变化可能会触发与用户操作不直接相关的其他处理过程。这些活动应该在后台执行。

Windchill 服务器管理器负责保证后台处理的发生。处理队列和触发机制执行时，实际上驻留在 Windchill 方法服务器中。服务器管理器只负责保持方法服务器的实例一直运行，以使后台处理能够发生。

如高级部署所述，您可以这样配置环境：准备多个方法服务器，其中一个专用于运行后台处理队列。

有关队列配置和维护的详细信息，请参阅关于后台队列。

Windchill可利用 HTTP 服务器的用户验证能力。对于使用 RMI 而非 HTTP 的客户端请求，需要一个用于缓存 HTTP 验证用户名的地方，以便该客户端请求可以与后续 RMI 调用可靠地关联。由于服务器管理器的后台程序进程比个别方法服务器进程时间更长，所以该位置在服务器管理器 VM 内。

如前所述，当客户端需要有效的凭证时，在 HTTP 服务器允许对保护的 Windchill HTTP 网关进行访问之前，不会涉及到 Windchill。接下来网关将已验证的 HTTP 请求传送到方法服务器以进行处理。方法服务器处理对凭证的请求，其处理方式是用运行在服务器管理器 VM 中的会话管理器来存储已验证的用户名和请求时传送的关联会话特性。

不使用活动连接来维护服务器管理器中的会话数据库。为了减少资源消耗，即使客户端与服务器管理器断开连接，方法服务器仍要对凭证进行验证。使用一种小规模的、根据最近使用原则的缓存运算法则，而不是活动连接，来判断凭证是否有效。当客户端在其会话凭证已失去时效后仍为活动状态的情况下，自动例外处理将透明地重建凭证。

可缩放性要求个别客户端不能无限消耗大量的服务器资源。大量的非频繁使用用户不应当要求将系统安装在超级服务器硬件上。服务器主机的大小调整应基于事务处理吞吐量，而不是用户计数。

Java I/O 模型，尤其是 Java RMI 执行方式，为每个网络连接至少专用一个线程。为容纳大量用户，Windchill 执行两种机制以释放网络连接和线程。第一种，在连接保持为空闲状态达到指定时间后，作超时处理。第二种，限制 RMI 运行时可消耗的客户端套接字的总数量。此限制是通过关闭最近最少使用的连接而强制实现的。所以，新的客户端连接就不会被拒绝，而且当客户端负载大时连接超时更快。客户端自动从断开连接状态恢复。

作为 Windchill 体系结构的后台程序进程，服务器管理器成为执行 Windchill 系统管理功能 (如启动和停止方法服务器) 的关键进程。

您可以使用 JMX MBean 来执行系统管理功能，尽管某些操作 (如关闭服务器) 被限制为经验证的用户名。

有关 JMX 的详细信息，请参阅使用 Java Management Extensions (JMX)。

此组件是 Java 应用程序，它执行代表业务对象事务处理的所有方法。就结构而言，它只作为基干进程使用，其作用是根据服务客户端的请求动态装载特定 Java 类。下图显示了方法服务器的结构。

当方法服务器进程启动时，它创建一个方法服务器对象的实例，作为远程对象导出到服务器管理器。客户端通过从服务器管理器检索此对象引用以绑定到方法服务器，然后与方法服务器直接进行交互。

通过实用程序类和生成的帮助程序类，应用程序开发人员察觉不到绑定和方法调用机制。其结构上的重要性是它有助于说明 Windchill 运行时是如何操作的。

使用 Java RMI 调用服务器方法的最大好处在于，它为在客户端与服务器之间传输任意复杂的对象图形提供了内置的支持。这样，事务处理就可以使用复杂的参数和结果，而无需对客户端与服务器接口进行复杂的编程。

通过使用对应于每个业务类的帮助程序类，客户端可以访问服务器端的方法。这些帮助程序类将其相应业务类的外部可用服务器端方法与实施过程相结合，后者将把调用转发给方法服务器，以激活实际方法。

有关接口建模和帮助程序类生成的详细信息，请参阅 Windchill 帮助中心的“基本自定义”和“高级自定义”区域中的自定义信息。

方法服务器是唯一与数据库直接通信的 Windchill 进程。在这一意义上，Windchill 运行时是典型的三层体系结构。通过使用共享数据库登录，方法服务器保存多个数据库连接，这些连接按照需要分配给工作线程，以执行各个事务处理。

数据库的接口是通过服务器中的持续对象管理器 (POM) 层来实现的，此层的作用是将实际的数据库接口从业务逻辑中抽象出来。

有关持续性的详细信息，请参阅 Windchill 帮助中心的“基本自定义”和“高级自定义”区域中的自定义信息。

类似于服务器管理器，可缩放性要求单个客户端不应无限地大量消耗方法服务器资源。所以，Windchill 方法服务器实行与服务器管理器相同的机制，将空闲连接作超时处理，并限制 RMI 运行时可消耗的客户端套接字的数量。

尽管当今一些分布式对象技术 (包括 Java RMI) 允许服务器通过反馈来回调客户端对象，但这种流行的回调客户端对象的方法存在一些问题。

首先，它强制地逻辑去除了来自操作的反馈，因为客户端必须创建对象才能接收反馈调用。这些对象必须维持该操作的状态，或在以后被调用时传送充足的信息，以将反馈与操作重新关联起来。无论是哪种情况，如果服务器不产生反馈，这些额外的工作就会浪费。例如，如果产生例外的操作与该例外相分离，则会造成例外处理的困难。应该说，在操作反馈和例外处理之间有逻辑上的相似之处。

第二，如果服务器不执行回调，则传送远程对象引用将导致浪费额外工作。如果想通过将这些引用保留在缓存中 (即，发送一次，以后再次使用) 来消除这种额外工作，则会损害系统的耐用性，因为导出原始对象的通信传输到被使用时可能已断开连接。客户端不能接受引入的连接，所以无法重新连接失去时效的客户端引用。试图对超时的连接进行回调，只会在服务器中产生例外。

Windchill 体系结构在远程方法调用协议中采用一种轻型反馈机制，解决了这些问题。其方法为：允许从服务器向客户端发送反馈对象，作为 RMI 答复封送流的一部分。这些对象在执行调用的线程内进行接收和处理，它们与调用共享同一通信连接，从而与调用保持逻辑上的结合。

当处理来自客户端的方法调用时，是从 RMI 答复封送代码内调用服务器端的方法，允许服务器端的方法随意将反馈对象刷新到答复流。客户端答复拆收代码将这些对象识别为反馈，并调用其初始方法，然后继续等待实际的答复。当启动长时间操作时，服务器方法可发送 GUI 组件，如进度条和取消按钮。服务器可定期刷新附加的反馈对象，更新此组件。“取消”按钮用来调用第二个线程中取消方法的操作，该线程能够中断方法服务器中的第一个线程。

要授予用户访问给定对象或操作的权限，方法服务器必须能够可靠地识别执行该操作的用户。有关用户验证 (安全地建立会话凭证) 的各个方面已进行了讨论。所有这些验证措施在方法服务器中结合起来，实现一种方法，来查询与当前执行线程关联的用户。这种能力允许应用程序实施访问控制策略 (将在帮助中心中的策略管理一节中详细说明)。

Java RMI 没有提供可靠识别执行调用的用户的内在方法。但是，Windchill 运行时体系结构通过方法服务器的远程方法调用接口满足了这种需求。RMI 方法参数中隐含了客户端凭证，还使用了数字签名以安全地将 RMI 线程与已验证的用户关联起来。该关联是在调用目标方法之前建立的，所以方法签名不需要包含其他环境或用户参数。这些信息可在需要时检索。

此外，在执行操作的过程中可动态修改此关联。例如，某事务的一些特定步骤可能必须由参与者执行，而不是由启动该事务的用户执行。要实施任意的身份验证委派方案，可通过一些方法来推送和弹出当前与执行线程关联的参与者。

Windchill 通过使用存储在数据库中的后台方法队列进行后台处理。此队列是方法调用规范的表，须通过后台处理管理器予以执行。这些规范本质上是方法名称和序列化参数 (存储为 BLOB)，而且出于可靠性考虑将它们存储在数据库中。

触发后台处理的事务处理包含将后台方法队列作为整个事务处理的一部分进行更新。一旦提交，即通知后台管理器。然后，后台处理器继续异步执行所有方法。队列条目的删除操作是在执行该方法的事务处理中执行的，所以能保证条目一次性全部处理完成，同时仍能确保在系统出现故障后重新启动未完成的事务。出现故障后，条目被标记为“需要管理员干预”和“忽略”。

例如，生命周期处理、工作流自动化和全文检索 (FTR) 索引维护都属于后台处理机制。

有关队列配置和维护的详细信息，请参阅关于后台队列。

日志文件用于捕获例外/错误记录和调试追踪消息。在第一种情况下，标记例外事件的日志条目一般说来极为少见。不过，为了排除故障，可以启用更为详细的日志记录级别。(运行某些 JIT 编译器实施方案时，可能无法获得全部追踪消息。)

从 Windchill 9.0 开始，Apache log4j 已被用作管理和发布日志消息的主要机制。已对一些旧的日志记录进行了修改以使用 log4j，但是之前存在的大量 Windchill 日志记录功能依然存在，就像在先前的版本中一样，而且仍由 Windchill 特性文件配置设置进行管理。在 10.0 版本中，其他原有的 Windchill 日志记录功能已迁移到 log4j。

日志记录的确对性能有影响，所以如果不进行调试应关闭详细模式。

每个服务器应用程序 (服务器管理器和方法管理器) 都具有一个单独的日志。在方法服务器日志文件中捕获 Servlet 和 JSP 日志记录。