《课程设计报告-平台化软件开发支撑平台研究.docx》由会员分享，可在线阅读，更多相关《课程设计报告-平台化软件开发支撑平台研究.docx（38页珍藏版）》请在三一文库上搜索。
1、软件学院课程设计报告题目全称： 平台化软件开发支撑平台研究 学生学号： 姓名： 指导老师： 指导老师评语： 签字： 课程设计成绩：设计过程表现设计报告质量总分目录一、关于SOA的基本理解31.1 面向服务的体系结构（SOA）概述31.2 SOA的发展历史及认证机构31.3 面向服务的体系结构做用31. 4构成 SOA 的技术31. 5 SOA 与其他技术的关系31.6 构建 SOA 系统3二、对IBM WebSphere的研究32.1 WebSphere介绍32.2 WebSphere安装32.3 WebSphere数据32.4 WebSphere应用服务器32.5 WAS管理配置3三、行业发
2、展状况33.1 SOA行业发展状况33.2 IBM的WebSphere行业发展状况33.3 国内SOA技术发展状况33.4 对SOA技术的发展展望33.5 现在国内SOA发展面临的挑战3一、关于SOA的基本理解1.1 面向服务的体系结构（SOA）概述面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有
3、中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为
4、按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），
5、它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL）来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，
6、这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为
7、您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。 最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。1.2 SOA的发展历史及认证机构2007年将有三个重量级的标准问世，它们目前都属于规范级别。它们就是SCA、SDO、WS-Policy。SCA和SDO构成了SOA组件开发的核心，而WS-Policy则成为SOA组件间安全通讯的标准，其作用类似于安全套接层在浏览器与服务器通讯中的重用。事实上，W
8、S-Policy的基本原理与SSL是一致的。 今后标准开发将具有一个共同的特点，就是标准与SOA架构的协调性。也就是说，无论是已有的标准还是正在开发的标准，都必须符合SOA架构的要求，同时要考虑单个标准与其它SOA标准之间的协调一致。 2007年将会有许多SOA的规范升级为标准。SCA和SDO计划于2007年由OASIS审核通过，而WS-Policy也将于2007年8月正式成为W3C标准。 基于市场的强劲需求，各标准化组织将继续加大在制定SOA相关标准上的投入力度，标准的制定和发布周期将大大缩短。比如对WS-Policy，W3C制定了精密的时间表。目前WS-Policy的发布时间表是这样安排的
9、，2007年3月发布候选推荐版本(Candidate Recommendation drafts)，2007年7月发布提议推荐版本(Proposed Recommendation drafts)，2007年8月发布W3C推荐版本(W3C Recommendations)。W3C历来以严谨和审慎著称，发布一个标准平均需要3至5年的时间。但就WS-Policy而言，从2006年4月 IBM和微软公司将WS-Policy规范提交给W3C算起，按照目前的时间表，整个标准发布周期仅为16个月。1.3 面向服务的体系结构做用对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通
10、过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平
11、改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内
12、部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有
13、新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。
14、这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。1. 4构成 SOA 的技术SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分布式事务处理和分布式
15、软件状态管理来进一步地改善它。SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见的 SOA 模型。因而，从本质上讲，Web 是实现 SOA 的具体方式之一。尽管我们觉得 Web 服务是实现 SOA 的最好方式，但是 SOA 并不局限于 Web 服务。其他使用 WSDL 直接实现服务接口并且通过
16、XML 消息进行通信的协议也可以包括在 SOA 之中。正如在别处指出的，CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在 SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线（Enterprise Service Bus，ESB），它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必
17、需的，但它却是在 SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级 ESB 组成的分布式系统，这些 ESB 一起工作，以保持 SOA 系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。从开发人员的角度来说，他们使用的工具必须知道 SOA 的能力，并允许开发人员有效地使用 SOA 对象。这将设计 SOA 模型、开发服务和服务对象以及测试 SOA 应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发（Service-Oriented Appli
18、cation Design/Development，SOAD）做好准备。1. 5 SOA 与其他技术的关系SOA 可以与许多其他技术结合在一起使用，然而，组件的封装和聚合在其中扮演着重要的角色。如前所述，SOA 可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程，甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可以看作是单个实体，但是在其自身中，它可以具有任何级别的复杂性（如果必要的话）。出于性能方面的考虑，大多数 SOA 服务并没有下降到单一对象的粒度，并且更适合于大中型组件。除了可能离不开 XML 和 WSDL 之外，SOA 并不是特定于语言的。可
19、以用任何编程语言来实现服务，只要这种编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语言和支持 WSDL 的平台来实现 SOA 中的成员服务。基于通用对象请求代理体系结构（Common Object Broker Request Architecture，CORBA）的应用程序有许多组件必须连接到 SOA 中。虽然 CORBA 中的接口描述语言（Interface Description Language，IDL）在概念上类似于 WSDL，但它不是严格的，因而首先需要将其映射到 WSDL。
20、另外，需要使用更高级的 SOA 协议（比如用于流程和策略管理的协议），而不是 CORBA 中的类似的概念。请记住，这是 CORBA 组件（表示为服务）需要与 SOA 服务交互的情况；在 CORBA 模型中，所有的独立子集仍然可以像以前一样工作。由对象管理组（Object Management Group）提出并在许多 IBM Rational 产品中得以实现的模型驱动体系结构在一个更抽象的层次上与 SOA 的概念具有很强的相关性。MDA 基于这样的概念，任何软件流程都可以定义为模型甚至是元模型（即模型的模型），然后可以将这些模型和元模型转换成应用程序的实际组件。因此，MDA 创建了一个模型，这
21、个模型先编译成软件应用程序，而软件应用程序接着又编译成可执行程序，这样就可以在平台上运行了。MDA 并不区分服务和对象这两个概念，但是它确实允许模型由其他子集模型本身组成，这类似于 BPEL（SOA 的一个核心组件）中的流程聚合的概念。SOA 和 Web 服务是独立于编程语言的，但 Java 是主要的开发语言之一。可以使用定义良好的 Java 接口以及各种协议丰富的 Java 实现为正在构建这个模型的开发人员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象进行交互的角色。SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算
22、的概念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级协议以及 SOA 系统的总稳定性。另外，网格计算可以以两个级别与 SOA 系统一起使用。网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为 SOA 应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了一些或所有单独的服务。因此，SOA 应用程序可以是网格服务的消费者。在另一方面，网格本身也可以构建在 SOA 之上。在这种情况下，每个操作系统服务都是构成整个 SOA 应用程序的成员，而 SOA 应用程序就是网格本身。因此，单独的网格组件既可以使用 Web 服务进行通信，又可以以 SOA 的方
23、式进行交互。总而言之，网格系统可以是 SOA 本身，也可以提供服务来在其上构建应用程序级 SOA 模型。1.6 构建 SOA 系统利用 SOA 的好处不仅是一个软件开发流程，而且还是一个业务开发流程。采用 SOA 有四个层次，您的实现可以跨越从创建特定的软件服务到将您的业务模型全面转换到按需系统的过程。要获得进一步的信息，您应该阅读这一部分的末尾列出的文章“The Four levels of SOA Adoption”。第一个层次是最简单的，因为它只需创建单独的服务。在这一部分列出的“SOA 新手入门”中对此进行了详细解释，并且提供了更多的资源。在第二个层次中，您不仅可以创建服务，而且可以开
24、始将业务功能集成到 SOA 中。这涉及多个层次的集成，其中包括应用程序集成、信息集成、流程集成和整个系统集成。Migrating to a Service-Oriented Architecture 是一篇重要的文章，介绍了这个层次中的问题。第三个层次涉及将您的企业 IT 基础设施转换到 SOA 模型，而采用 SOA 的第四个层次集中于转换您的业务模型，以使之成为按需就绪的模型。从 IT 专业人员的角度来看（与业务层相比），要创建 SOA 应用程序，您通常将经历四个阶段：构建、部署、使用和管理。在构建阶段中，您可以定义业务模型或流程、软件模型和 SOA 模型。之后，您就可以创建一组服务，这组服
25、务可以与已发布的通用接口一起重用。在部署阶段，您提取创建的服务，并把它们放在一个可执行、可管理的环境之中。在使用阶段，您根据前面所讲的 SOA 和软件模型来装配应用程序，并且测试其软件质量以及非功能性需求，比如性能、可伸缩性等等。应用程序现在已经准备完毕并且可用于用户。最后的管理阶段是一个长期的过程，在这个阶段中，您可以监控并管理安全性和使用，以及在许多与您可能已经为 SOA 制订好的服务级协定或策略相对应的方面比较其性能。这些是 SOA 的生命周期的概念阶段。为了使对应于这些阶段的实际工作角色具体化，有许多角色需要加入到 SOA 应用程序的创建之中。这些角色可能从事相同的工作，也可能跨多个团
26、队成员甚至多个团队。在 Rational Unified Process（RUP）中所划分的角色非常好地表达了角色概念。RUP 角色包括项目经理、分析员、架构师、建模人员、开发人员、测试人员以及部署和操作人员。SOA 几乎完全照搬了这种角色划分方法，惟一不同之处在于，SOA 建模人员角色的工作是提取概念性软件模型，并且根据 IT 基础设施的 SOA 模型和资源来对其进行测试。开发人员角色还可以包括二级角色像装配人员（在使用阶段），装配人员的角色是提取单独的服务，并且根据定义好的模型构建实际的 SOA 应用程序。不管是显式的还是隐式的，这些角色都存在于支持 SOA 的企业之中。二、对IBM We
27、bSphere的研究2.1 WebSphere介绍WebSphere是一套完整的电子商务平台，在此平台上WebSphere提供了一系列基于统一的基础平台、完全基于开放标准的相关产品组件,其特征是：1) 基于标准； 2) 以服务器为中心； 3) 可伸缩； 4) 能利用已有的核心系统； 5) 可快速部署和易用； 6) 易管理。WebSphere是IBM的一套软件产品，包括WebSphere应用服务器，WebSphere Studio和 WebSphere Performance Pack。还有其他一些产品加入进来做为补充和扩展WebSphere Studio,一个Web站点开发和设计工具包，包括项
28、目管理，Java Servlet代码生成器，HTML写作工具，各种Script的编制工具，以及JAVA代码(Beans和Servlets)的开发工具。WebSphere应用服务器提供三个等级的版本，它们是： 标准版(Standard Edition)，是整个应用服务器家族的基础，提供从电子商务网站的建构、发布 到管理能力。标准版提供了开放、标准的平台和工具，以加速向电子商务的迁移。新加入的DB2UniversalDatabase5.2 支持，使开发者能够设计更强大有效的应用。WebSphere应用服务器标准版V1.1已经面世。包 括Servlet运行时引擎(RuntimeEngine)，高性能
29、的数据库连接程序(提供预联接，会话和状态管理的 应用服务，以及支持XML(eXtensibleMark-upLanguage)文档结构. 高级版(Advanced Edition),在标准版本的基础上，又增加了对安全性和交易处理能力的强化支持。连接已有的 数据库系统和基于主机的交易系统。并提供了复杂的工具以简化分布式组件应用的开发. 企业版(Enterprise Edition)，提供了一个高可靠性的解决方案，能够将电子商务应用移植进关键性的企业环 境，起到平衡现有IT系统的作用。它组合了IBM享誉世界的交易环境TXSeries，和ComponentBroker，IBM的一个支持 完全的分布式
30、对象访问和商务处理连接能力的产品。所有现在运行在TXSeries或ComponentBroker上的应用将在 Webshpere企业版中得到完全支持。 IBMWebSphere Performance Pack，包括eNetwork Dispatcher,Web Traffice Express 代理服务器和AFS分布式文件系统。让ISP(Internet Service Provider)和公司IT(Information Technology)专家降低 Web服务器拥塞，提高信息可获取性，改进服务器性能。其技术优势： 1) 安全、可伸缩、具有弹性的应用程序基础架构，这些基础架构是实现面向服
31、务架构 (SOA) 所需要的。 2) 100%地支持业界的开放性标准包括Java/J2EE, XML, LDAP, CORBA，WML等等 。 3) 借助于一套简单的工具和界面，快速容易地构建和部署可重用的应用程序服务。 4) 在可靠、可伸缩、高度可用的环境中运行服务，以确保不因为应用程序宕机时间而失去业务机会。 5) 借助于具有弹性、基于标准的安全基础架构（此基础架构会移除易受攻击的威胁，同时最大限度地提高开发人员生产力），保证应用程序和数据的安全，提供了端到端（end-to-end）的安全解决方案 。 6)借助于基于标准的消息传递和最新的 Web 服务标准，重用软件资产并扩展其使用范围。
32、7)借助于面向管理和监视的功能强大、易用的工具，轻松管理应用程序。 8)跨最广泛的业界平台快速安全地进行扩展。 9)支持完整的 J2EE 1.4 编程模型和扩展，包括 Servlet、JSP、EJB 和 Web 服务。 其产品优势：面向服务架构的构建块：当今的 WebSphere Application Server 跨所有配置交付了面向服务架构。通过使用基于标准的消息传递和最新的 Web 服务标准重用现有 IT 资产，这些产品允许企业提高投资回报和降低总体拥有成本。这就会降低成本、加速创造价值的进程和提高业务灵活性。 安全的最佳资源利用率：WebSphere Application Serv
33、er 为企业提供安全的动态平台。借助于 WebSphere Application 的伸缩能力和安全特性，企业能够使用更少的资源完成更多的工作。 随需应变的基础设施：WebSphere Application Server 提供当今企业所需的健壮、灵活的环境。借助于面向任务关键型应用程序的几乎连续的正常运行时间，企业能够事实上避免失去业务机会。 快速开发和部署：借助于增强的开发和部署能力，WebSphere Application Server 支持快速的创造价值进程。借助于支持易用性和高度开箱即用性能的特性，企业能够加速创造价值的进程，并充分利用现有技术技能。 2.2 WebSphere安装
34、除了上面基本的软硬件条件之外，安装WebSphere应用服务器之前还要确认环境的几个配置问题： 1 一般地，WebSphere应用服务器需要您作为 root 用户（Unix/Linux系统）或 Administrator 组（Windows系统）的一部分进行安装。 2 磁盘空间的分配 在考虑硬盘空间分配的时候要周全一些，尤其是在一些不能动态分配磁盘空间的系统（比如Solaris）上。如果是在生产环境上安装WebSphere应用服务器，一般要从以下几个方面来计算要预留的空间. WebSphere应用服务器自身占用空间。这个空间一般在400M左右，不同的系统平台略有异。如果WebSphere的部署
35、管理器（Deployment Manager）也安装在同一台服务器上，则还要加上300M左右的空间. 如果WEB服务器也安装在同一台服务器上，则要算上它的空间。WebSphere应用服务器中带IBM HTTP服务器一般占用50M左右的空间。 用户发布到WebSphere应用服务器上所有应用程序的占用空间。这个大小与实际应用相关，而且不同应用可以差别很大. 系统日志的占用空间。这里日志主要是指WebSphere应用服务器的日志。如果有WEB服务器则还要考虑WEB服务器的日志空间。日志空间的估算要结合系统对日志的配置情况。如果日志配置没有设置好，多大的空间都有可能耗尽。在实际项目中如果有客户没有关
36、闭WEB服务器的访问日志，因而导致几天之内WEB服务器就生成一个超过1G的日志文件。这么大的日志文件，不但耗费空间，而且影响性能。WebSphere应用服务器可以设置日志件的大小和保存的文件数量，从而可以估算出其需要空间。3端口有没有冲突？ WebSphere应用服务器缺省占用的端口包括：管理控制台端口9090，管理控制台安全端口9043，HTTP传输端口9080，HTTPS传输端口9443，SOAP通信端口8880（在网络部署版这个端口是8879）等。如果系统中已有应用占用了这些端口，那么应用服务器启动的时候就会报告端口冲突的错误。一般我们可以用netstat命令来查看系统端口的使用情况。
37、4服务器的主机名 根据实际经验，我们推荐用户在安装WebSphere应用服务器之前配置主机名。可以通过hostname命令来查看当前系统的主机名。如果没有配置，则到hosts文件中添加相应的条目。 5用户名和用户组的建立 WebSphere应用服务器中内置了一个基于WebSphere MQ的JMS服务器。在UNIX/LINUX平台上安装的时候，如果选择了完全安装或在定制安装的时候选择了安装嵌入式消息传递，那么就要在安装开始前先创建两个用户组mqm和mqbrkrs和一个用户mqm。而且需要将用户mqm和root添加到mqm组，还要将root添加到mqbrkrs组。2.3 WebSphere数据1
38、. 为什么要使用数据源？ 建立一个数据库连接是一种比较耗时的操作，连接池可改进任何需要连接的应用程序（特别是基于 Web 的应用程序，Web 用户的连接和断开更为频繁）的响应时间。 连接池的实现，在客户端调用 close（）方法的时候实际上并不关闭连接，而是把连接返回到一个可重用连接的连接池中给其它客户端使用。这样就避免了任何重复打开和关闭数据库连接造成的开销，并且允许大量的客户端分享相对较少的数据库连接，从而提高数据库操作的性能。 为了使用应用服务器提供的连接池功能，我们需要先定义相应的数据源。数据源在WebSphere应用服务器中作为资源存在，因此可以统一通过JNDI来查询它们。 使用数据
39、源的代码片断示例 ： try javax.naming.InitialContext ctx = new javax.naming.InitialContext();javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup(jdbc/DSName);java.sql.Connection con = ds.getConnection(); catch(javax.naming.NamingException e1) System.err.println(Naming-Exception: + e1.getMessage(); catc
40、h (java.sql.SQLException e2) System.err.println(Naming-Exception: + e2.getMessage(); 2.WebSphere应用服务器中数据源所处的位置 很多人在刚开始配置WebSphere应用服务器数据源时对J2C认证别名很不习惯，觉得JDBC的东西怎么会与J2C扯上关系。我们知道基于J2EE的WEB应用在与后台EIS（企业信息系统）集成的过程中，根据EIS的不同主要有三种连接方式，分别是JDBC，JCA/J2C和JMS。从理论上讲，JDBC驱动程序是可能归纳成一种特殊的JCA连接器，只不过这个连接器后面恰好连接着关系型数据
41、库。3.在WebSphere应用服务器中配置数据源 首先要确认所用的数据库是支持JDBC2.0的，并确保我们的操作系统环境设置为支持 JDBC 2.0。这是使用 WebSphere应用服务器创建的数据源所必需的。这一点在使用UDB DB2 7.2的时候尤其要注意。 要确定使用哪个数据源：数据源V4.0还是 V5.0 数据源。 数据源V4.0是使用 WebSphere 旧连接管理器体系结构的 WebSphere 4.x 中的数据源，所有的 EJB1.x 模块都必须使用此数据源。 WebSphere应用服务器5.x提供对 V4.0 的 JDBC 连接管理器模型的支持，使得 J2EE 1.2 应用程
42、序能够不经改变地运行。WAS 5.x 也支持J2EE 1.3的应用， J2EE 1.3 应用程序内的 EJB 2.0 模块，WEB 2.3模块需要使用 V5.0的JDBC 连接管理器。 创建 JDBC 提供程序。JDBC提供程序指的是JDBC驱动程序的类型及其相应的驱动程序实现JAVA包。 创建数据源。数据源是在提供特定 JDBC 驱动程序实现类的 JDBC 提供程序下创建的。 绑定资源引用。J2EE 1.3标准推荐使用数据源的引用而不是直接使用数据源的名称。 测试连接。WebSphere应用服务器5.0.x及5.1提供了数据源配置页面上提供了测试数据源连接的测试按钮。2.4 WebSpher
43、e应用服务器 IBM WebSphere应用服务器（简称WAS）是一个Web 应用服务器，它提供了增强的Servlet API和Servlet管理工具，并集成了JSP技术和数据库连接技术WebSphere Application Server（WAS）基本特征：WebSphere应用服务器使您能够为Servlet 的开发实现 “一次写成，各处使用”的目的。该产品包括一个基于 Java 的 Servlet 引擎，独立于 Web 服务器和它所基于的操作系统。WebSphere应用服务器提供了服务器插件的选项，与大多数流行的应用程序设计接口(API)兼容。所支持的 Web 服务器有: 1、IBM H
44、TTP 服务器 2、Apache Server 3、Domino 4、Lotus Domino Go Webserver 5、Netscape Enterprise Server 6、Netscape FastTrack Server 7、Microsoft Internet Information Server除了 Servlet 引擎及插件外，WebSphere应用服务器还提供： 1. JavaSoft Java Servlet API 实现，以及这些 API 的扩展和附加。 2. 示例和文档，示例 Servlet 和 Web 站点应用程序演示了简单和高级技术。联机和可打印文档供您 快速入
45、门，并帮助掌握服务器高级功能的使用演示基本类及其扩展的示例应用程序。 3. WebSphere应用服务器的管理器，使用图形界面，易于: (1) 为装入本地和远程的 Servlet 设置选项 (2) 设置初始化参数 (3) 管理 Servlet (4) 指定 Servlet 别名 (5) 创建 Servlet 链和过滤 (6) 启用轻量级目录访问协议（LDAP）目录支持 (7) 记录 Servlet 消息 (8) 启用 JVM 调试 (9) 监控 WebSphere应用服务器 使用的资源 (10) 监控已装入 Servlet、活动 Servlet 会话和 JDBC 连接 (11) 控错误、事件、
46、异常情况和日志输出 (12) 创建转储和数据快照 (13) 动态地启用和禁用跟踪 4. 缓存和再使用与 JDBC-从属数据库连接的连接管理功能。当一个 Servlet 需要数据库连接时，它 可从可用连接的缓冲池获得，从而消除了为每个请求打开一个新连接的所需花费的系统开销。 5. 附加的 Java 类，遵循 JavaBeans 规范，允许程序员访问 JDBC-从属数据库。当隐藏使用关系数据库的复杂度时，这些数据访问 Bean 可提供增强功能。它们可用于可视集成开发环境中。 6. JSP的动态页面内容支持。JSP 技术使您能够通过服务器端脚本生成动态 Web 页面。其结果是将 呈示逻辑（例如，定义 Web 站点结构和外观的 HTML 代码）从业务逻辑(例如，访问数据库以获得要显示在 Web 站点上的信息的 Java 编码信息）中分隔出来。灵活性方面，JSP 文件可包括任何直接插入的 Java 的组合： 标记、NCSA标记和JavaBean 2.5 WAS管理配置1、启动 WebSphere应用服务器的管理器 要启动 WebSphere应用服务器的管理器 ，必须先将WebSphere服务器启动，然后在Web 浏览器中输入 URL：http:/localhost:9090/admin 进入