合应用可以包括若干独立应用构件，每个独立应用可以单独立项进行需求分析、设计开发和部署运行，因此复合应用系统生命期可以跨越若干独立信息系统项目。
在开发独立业务应用时，一个系统的立项、可行性分析、需求分析及实现都限制在预定的某个或某类业务流程内，如订单、人事、财务系统等。与其他系统的连接（数据和处理逻辑）通过接口或集成项目实现。由于工期和成本的限制，一般不必考虑与其他系统联合运行产生的问题。在复合应用的生命期中，各个系统常常处在各自生命期的不同阶段，这些系统的联合运行是复合应用开发和运行管理需要特别注意的地方。
在满足业务处理的要求下，一个信息系统的生命期越长，系统开发的效益成本比就越高，员工熟练程度也就越高。经过适当的设计和实施，复合应用系统可以通过对其内部组合的不断修改有效地延长整个信息系统的生命期。 1.5.2 复合信息系统的生命期
复合应用的方法使大系统的建立可以分解为大系统框架指导下的，若干小系统（构件）的实现和组合，提高了系统的灵活性，缩短了整体和修改项目的开发周期，从而可以更好地适应不断变化的业务和组织流程要求。 这个大系统的范围可以超过当前一般单一业务系统的规模，因此需要从更广泛的角度考虑系统内容和相互关系，使系统可以更好地支持业务流程及其优化。
复合应用所涉及的业务范围和信息系统，比各个独立应用系统广泛得多。例如采用复合应用的银行网点系统不仅需要考虑基本柜台业务，还要考虑人事、资产管理等网点各个员工可能涉及的所有业务信息系统功能。为了给网点员工提供多个应用的最佳组合，在复合应用生命期的各个阶段需要考虑整体框架与整体业务和组织的对应关系，以及整体框架中的各个独立应用的完整性和统一性。每个应用构件可以作为独立项目管理。每个构件在特定复合应用中使用的不同阶段也有不同特点。这个将在 5.6 节进一步介绍。
复合应用不仅适合为用户提供含有多个业务应用整合价值的综合业务系统，也适用于传统独立业务系统。以复合应用思想和技术实现的业务系统，具有使用更加方便、开发更加迅速的特点。这种状况下其生命期与传统系统类似。但其中的框架和构件都可能重用，因此有可能使系统不断变化， 从而延长其生命期。复合应用的生命期包括其框架的生命期和各个构件的生命期。框架生命期不一定要长过构件生命期，好的构件可以在多个复合应用框架中使用。 1.5.3 复合信息系统的需求分析和系统定义
复合应用的需求分析，包括系统所涉及的组织及其各个业务的整体要求和具体要求。复合应用在传统业务系统注重业务操作本身数据处理的基础上，强调通过多种应用的集成使用户能够实现高效的业务处理。因此在需求分析阶段不仅要了解业务处理本身，还要了解提供优化业务处理所需要的信息，进一步要了解一个业务流程中各个员工所负责业务的相互关系，以及每个员工所涉及的不同业务间的关系，了解如何使每个员工高效、高质量地完成所有相关业务，并使企业业务流程整体得到优化。通过分析的结果可以定义出权衡用户工作效率，企业组织和业务流程优化，开发成本 / 工期，以及现有系统限制的复合应用系统。
以银行网点系统为例，从提升网点效能的目的出发，网点系统要考虑如何给柜台人员提供整体操作界面，以方便切换业务处理操作，在复杂业务（理财、保险）处理时，如何根据不同业务和人员的技能，提供足够的信息，实现业务的优化处理。复合系统要定义已有的各种业务系统如何集成到统一的工作界面，从而减少操作步骤、提高操作质量。 1.5.4 复合信息系统的设计开发与测试
作为可以满足企业和市场竞争变化要求的信息系统技术，复合系统的设计和实现重点在于灵活的整体框架，集成各种应用构件和对应用构件的管理控制，以及数据接口和运行管理环境，充分利用已有业务系统作为应用构件并以最小的成本快速实现强大而丰富的信息处理功能。 SOA 和面向角色的分析设计是复合系统需求分析和系统设计的主要方法。本书第二章详细介绍复合应用的需求分析和系统定义方法。第三章介绍开发复合系统需要的各种技术和工具。第四章将详细介绍复合应用的整体框架与应用构件的组合和关系设计，以及应用构件本身的设计。
复合应用系统的测试与传统单一业务系统测试有很大不同，分为框架测试，构件测试和复合应用集成测试。当某个构件或框架部分更新后， 需要测试更改部分与其他部分的整合性。 1.5.5 复合信息系统的部署与运行管理
运行是信息系统生命期中最长的一个阶段。如果在需求和开发时考虑不周，则这个阶段会缩短很多，使整个系统生命期显著缩短。因此在需求和设计时应该认真分析和考虑该阶段的要求和问题，使系统生命期更长。
复合应用系统的运行阶段与传统信息系统有很大不同。其整合性使系统运行期跨越多个应用及其复合的运行期，具有天然的长运行周期特点。因此更要重视系统运行期的管理，争取延长系统生命期。
复合应用的管理是在各个应用管理基础上的综合管理，包括应用管理、用户和安全管理、数据管理、用户问题处理等。
应用管理是运行期间对复合系统中的框架和各个构件的部署、更新、访问控制管理。应用管理的灵活性与所选用的技术和框架设计有很大关系。在复合系统的运行过程中，工作框架和应用构件可以为适应业务和竞争变化的要求不断改进。如果应用管理能适应多种框架和构件的要求，则可以方便管理并使整个系统生命期延长。
用户管理包括管理业务用户的加入、修改和删除。由于各个构件系统可能拥有自己的用户管理系统，复合系统需要管理所有可能涉及的用户操作和安全控制。
复合应用中的数据管理分布在各个应用当中。在每个应用自身的数据管理基础上，要考虑多个应用之间的数据相关性，使复合应用中的应用构件数据保持一致。
复合应用给企业运行管理部门提供了提高效率和服务水平的机会，对问题处理提出了更高的要求。由于复合应用包含若干独立业务应用，其系统范围比独立应用要广泛。每个业务应用
的问题可能影响更多的岗位。因此在修改各个模块时，要统一考虑对复合系统中的其他模块的影响。
良好的复合系统运行需要完善的运行环境与各种监控和管理工具的支持。本书后面章节介绍可能满足复合运行管理要求的产品，包括 Eclipse 和 Lotus Expeditor 技术，以及如何利用它们实现特定的管理功能。 1.5.6 复合应用框架的生命期
复合应用中的框架是根据业务需求实现的多个应用构件组合。它随业务要求变化和应用构件变化而变化。应用框架是复合应用功能的集中体现。其生命期与复合应用本身一致。根据运行和开发工具的能力，框架可以在整个生命期中不断发展变化。有些复合平台只提供固定组合框架。
目前的复合业务框架可以分成两类，工具箱型和工作管理型框架。前者用某种方式给用户提供所有可用的构件或者构件组合列表，用户自己决定选择哪个组合框架执行。后者提供较复杂的框架编程控制能力，开发者可以定义各种用户工作内容和对应的应用组合，可以由框架根据工作内容自动选择构件组合。本书第三章介绍复合应用的技术时，将详细介绍各个应用技术的框架能力。第四章将详细介绍不同类型复合框架的设计和特点。
目前大部分相关技术只提供简单框架的平台。一般技术或产品只提供固定框架或者完全不提供框架，需要开发者或者用户自行组织构件复合。一些更高级的平台提供框架的开发和管理功能，使开发者和用户可以像管理其他应用一样管理复合框架，包括部署、授权、更新等。 1.5.7 复合应用中应用构件的生命期
构件是复合应用中的基本功能部件，要求其具有独立完成某个业务处理的功能，以及与其他构件及框架交互完成更复杂业务处理的能力。复合应用中的每个（界面）构件都可以与其后端处理和数据库一起形成一个有独立生命周期的系统。如复合型银行网点系统的储蓄系统构件，可以是完整的储蓄业务应用改造后的一个构件。在开发复合应用时，应用构件有两种实现方式：一是利用已有系统， 包装成应用构件；二是开发新的应用构件，各个界面构件的后端系统可以与界面紧密相关，也可以独立存在并为多个界面构件服务。
许多复合应用的构件是各个应用系统的前端表现，在满足复合应用整体框架的条件下，可以独立开发、部署和更新。所谓界面独立，包括独立于后端服务和独立于框架。 SOA 的设计思想是通过后端服务化减弱系统前端和后端的关联，提高构件独立能力，达到提高系统灵活性的目的。
随着构件接口和功能的标准化，未来会出现一些商品化构件。一些软件产品可以以构件方式独立销售、使用和更新。构件可以小到时钟、日历这样的小构件，大到 ERP 这样的完整系统。这些构件商品可以应用于不同的复合系统，其生命期则超过部署在特定复合应用中的构件，甚至复合应用的生命期。
复合系统中有些构件属于复合框架的一部分，用于控制各个工作空间的管理和切换，以及为其他构件提供本地服务等。这些构件的生命期与复合应用框架的生命期紧密一致。
为了保证复合应用的使用和管理的完整性，每个构件需要支持复合应用框架对构件的打包和接口规范，使其可以在框架中复合，相互协调完成复杂业务处理。并可以在统一平台上运行和接受应用部署管理。
应用构件的开发可以是对以有系统的简单包装，也可以与一个独立业务应用的开发一样，经过需求分析、设计、实现、测试、部署运行、更新等多个阶段。为了提高效率，一般是对现有应用和工具进行改造。在新业务系统开发时，可以将其加入作为复合应用构件的需求，使企业的系统既可以作为单个系统使用，也可以作为构件，在复合应用中与其他应用一起提供更方便的业务处理。
1.6 实现复合应用系统的技术和工具
任何信息系统的开发设计思想，都需要由某种技术及工具实现，并在这些技术和工具的发展过程中得到不断完善。在实践中，为了在规定时间内，可行和经济地实现满足用户要求的信息系统，需要许多开发、测试和运行管理工具。开发成的系统需要部署在特定运行环境上为最终用户使用，并为管理人员提供监控、数据备份等管理工具。这些工具和运行环境与采用的方法和技术有一定的关系。要想把理论设计变成实际的系统，必须掌握相应的工具。同样要使一个理论和设计被开发者接受，也需要有相应的工具。本节首先简述信息系统技术和工具，然后讨论复合应用系统的实现技术和工具，以及一些相应产品。为后续章节的详细介绍提供一个知识框架。 1.6.1 信息系统技术工具分类
信息系统技术理论及对应工具可以从不同角度进行分类。根据其在系统生命期使用阶段的不同，可以分为需求分析、设计、测试、部署和运行管理技术和工具。按技术所有属性可以分为开放技术和专有技术，商业产品和开源工具。专有技术包括各个厂商自己定义的技术标准和对应工具。按实现的系统架构的用户界面形态，可分为 Web 技术和富客户端技术。 各个理论、方法、技术和产品有一定相关性。一般而言，某种理论由相应的技术和产品在实践中应用，实现信息系统。例如面向对象的思想产生面向对象的 RUP 分析设计方法和编程技术（如 Java，C++），并进一步产生相应的开发和运行环境（Microsoft Studio， MFC 库等）。技术的发展往往从某个人或公司的专门技术和工具开始。有些被市场认可的技术会逐渐成为占市场统治地位的事实标准，例如 Windows 的 .NET 开发平台。有很多人和公司参与相应工具和应用系统的开发。厂商也有可能公开标准使其成为开放标准，例如 IBM 个人计算机。信息系统开发者可以根据客户的要求、项目的需要和自身技术特长采用某种技术，并采用相应厂商的技术工具和产品实现。
目前复合应用理论和技术都处于起步发展阶段，有各种各样的技术和产品，但还没有主导市场的技术和工具。由于对复合应用的理解不同，各种产品的功能和规模相差很大。在实践中需要分析企业具体应用复合的需求，考虑所开发复合应用的特点，选择相应技术和产品。 1.6.2 复合应用的技术和产品
目前许多公司和开发商看到了企业信息系统对复合应用的需求，纷纷在其应用和产品开发设计中有意识地实现某些复合应用的功能。由于对复合应用的理解不同，相应产品的功能和对应的技术有很大差异，下面从几种典型的技术和产品，介绍复合应用技术产品与其他技术产品的不同之处。使读者对复合应用的工具有更明确的认识。
复合应用技术和产品的特点，是定义了复合框架和构件的编程标准，提供框架和构件的开发、运行环境和部署管理工具。开发者可以独立开发并部署框架和构件。用户可以根据自己的需要，选择和修改框架，并部署和使用对应的构件。
目前使用较多的专有 Web 复合技术有 Google Gadget，Firefox Plugin，Wordpress 等，桌面专有技术有 Google 桌面，联众的游戏平台，Eclipse RCP 平台等。其中有些是商业厂商，有些是开源社区提供的。开源社区提供的 Eclipse RCP 平台，可以看作是开放的复合技术平台。
SUN 公司的 Web Start 技术和产品的思想，是将包括前端应用和后端服务的整个系统部署在服务器上，允许用户根据需要，将前端应用下载到本地运行，或者在服务器上运行而在本地显示结果。在这种技术中，应用可以在服务器端集中部署，每个应用还是独立的。这种技术消除了到客户端部署应用的麻烦，但它不能提供各个应用的界面集成，更不用说在应用之间交换数据和为了完成业务而操作协同了。因此它不能称作复合平台。
针对 Web 应用的复合，Web2.0 中的 Mushup 提出了整合不同来源 Web 应用的需求，但目前并没有整体标准。很多 Mushup 是个别网站提出的应用和部件技术。也有许多 Web2.0 技术用作集成某些特定内容，例如前面提到的 RSS 复合。这些单项技术不能实现前面所述的复合应用的整体要求，即整合各种技术应用，为最终用户提供一个简单、高效的使用界面，同时简化企业 IT 的管理。很多 Mushup 的厂商都在试图扩展其功能，达到成为通用复合平台的目标。因此了解目前的 Mushup 技术和产品可以为将来复合应用开发作准备。 Microsoft 的 Smart Client 技术借助 Windows 提供的 COM 组件技术，具有了复合应用的基本能力。但目前没有现成的复合框架和构件的开发和运行工具，需要开发者自己设计并实现相应框架和构件。
1.6.3 基于浏览器的 Web 复合技术
所有 Web 应用都运行在浏览器中。因此可以复合 Web 应用的技术，称为基于浏览器的复合技术。目前有多种技术可以实现用浏览器访问的复合应用的部分要求。如基于 JSR168 标准的 Web 门户（Portal）技术。还有一些针对特定厂商环境和技术的复合技术。如 Google Gadget 定义了 Gadget 标准。开发者可以开发 Web 构件，然后用 JavaScript 组合这些构件形成一定意义上的复合应用。 Wordpress 是一个 Blog 环境。它本身是 Blog 的复合框