Oracle-Based Application Performance and Scalability by Design
The scalable performance of an Oracle-based enterprise application just doesnrsquo;t come as an accidental windfall. A more carefully designed Oracle-based product with performance and scalability taken into account from the beginning is more likely to perform and scale after it is built and delivered to customers. Furthermore, the later a performance or scalability issue is discovered in the development cycle of a product, the more costly it is to fix. Think of such a scenario: A large-scale enterprise application consisted of multiple subsystems; whereas all edge subsystems were multi-threaded, the subsystem acting more like a hub for the entire system was single threaded. Was this a scalable design? Probably not. A complicated software system is similar to an ecosystem that all parts need to support each other in order to coexist. An equilibrium condition is formed when no single part could easily become a single point of failure or bottleneck. Such an equilibrium condition is necessary so that the whole system can sustain stably.
Now the question is how one can design the performance and scalability into an Oracle-based application by following a proven software engineering methodology. At the highest level, one needs to reach a proper balance among the three axes for a software project: cost, schedule, and quality. How much weight one should put on each axis depends on many factors, such as how innovative the idea about the product is, how fast the competitors will be able to catch up, the size of the potential market, and the expected turnaround in terms of cost recovery and profit margin, and so on. Although most of these aspects, especially cost and schedule, belong to the managerial category, the quality of the actual product is more of a technical issue—both from the process and development perspectives. While we let a great management team make calls on cost and schedule, letrsquo;s see what it takes for a capable technical team to make a high quality product—with both performance and scalability taken into account through the entire development life cycle of a product.
Taking aside the gory technical details, letrsquo;s first explore the traditional, waterfall, spiraling software development methodologies versus more recent rapid development methodologies. It appears that the traditional methodologies are more suitable for developing platform-type products such as operating systems, middleware systems, and database systems, and so on, that are foundations on which applications are built, whereas the more recent rapid development methodologies are more suitable for developing application-oriented products. It also appears that what development methodology to use has something to do with the maturity of the product under development. Itrsquo;s less pressing to release version N 1 from version N, say, with N gt; 5, with a more mature product than to release version 0or 1 with a new product. Letrsquo;s next explore the advantages and disadvantages of the various rapid development methodologies, which are most pertinent to developing Oracle-based applications. This would serve as a precursor to the remainder of this chapter, which will cover how to design performance and scalability into an Oracle-based application.
The following subjects are discussed in the remainder of this chapter:
- Rapid Development Methodologies
- Planning
- Requirements Gathering
- Conceptual Design via Data Modeling
- Logical Design via Normalization
- Physical Design
- Implementation
- Release to Market (RTM)
- Continuous Improvements
Note that this chapter and the next chapter will be heavy on programming—both in SQL and in Java. With Java, wersquo;ll rely mostly on one of the most popular open source Java development platforms—Spring Source. We will also step upon some of the latest hot technologies such as RESTful Web services. Spring has a very large base of software developers, RESTful Web services is the moving trend, and Oracle is the best database technology, so we are all set to have fun (also consider this an opportunity for acquiring a valuable set of skills in developing Java and Oracle-based applications). Letrsquo;s start with Rapid Development Methodologies next.
- RAPID DEVELOPMENT METHODOLOGIES
To set the expectations properly, I have to mention that this section is not a detailed introduction to every major, modern rapid software development methodology. The overview of each rapid development methodology will be concise, yet sufficiently clear for you to realize which development methodology is followed for your product under development. Knowing what development methodology is followed with your project might help position yourself better in working with your team and making great contributions to your project.
Here is a brief introduction to each of the major rapid development methodologies (you might have heard a lot about the first three but less about the last three):
- Agile Development. This is an iteration-based, or drop-based development methodology, measured chronologically in roughly every two weeks. Because of its agility nature, it depends more on less formal communications such as oral or face-to-face communications than formal documentations. With this methodology, formal documentations are worked on during the final stage of the product release. The advantage is that itrsquo;s agile so that it could be more effective and efficient; but it could be a two-edge sword that it may turn out to be less effective and efficient if the team size is too large or the team members are less self-disciplined.
-
Extreme Programming (XP). The main goal of XP is to reduce the cost of change. This methodology encourages starting with the simplest
全文共24509字，剩余内容已隐藏，支付完成后下载完整资料
基于Oracle的程序性能和可扩展性设计
对于基于Oracle的企业级应用程序，其可扩展性能的设计并不容易。一个经过精心设计的基于Oracle的产品，应该从一开始就考虑到性能和可扩展性，该产品在构建并交付给客户后，会更容易执行和扩展。此外，在一个产品在开发周期中，如果发现性能或可扩展性问题的时间越晚，修复成本就会越高。设想这样一个场景：某个大规模企业级应用程序由多个子系统组成;其中所有边缘子系统是多线程的，那些更像是整个系统集线器的子系统则是单线程的。这是一个可扩展的设计吗？答案是否定的。复杂的软件系统类似于一个生态系统，各个部分都需要互相支持以便共存。当单个部件不会变成单点故障或系统瓶颈时，就形成了平衡条件。这样的平衡条件是必要的，这会使得整个系统的稳定性得以维持。
现在的问题是，如何通过遵循可靠的软件工程方法，来设计基于Oracle的应用程序的性能和可扩展性。在最高级别的设计中，软件项目的三个标准轴：成本，进度和质量，需要在设计中达到适当的平衡。每个轴上应该有多大的重量取决于许多因素，例如产品的概念如何创新，竞争对手能够赶上的速度，潜在市场的规模，以及预期的周转时间，回收成本和利润率等。虽然这些方面，特别是成本和进度，大多数属于管理类，但无论从产品生产过程还是发展的角度，实际产品的质量更多是技术问题。尽管我们让一个伟大的管理团队去控制成本和进度，我们同时也需要看看：一个有能力的技术团队，是如何使一个高品质的产品，在其整个开发生命周期中，考虑好性能和可扩展性。
首先，让我们先抛开技术细节，来探讨传统的，瀑布式、螺旋式的软件开发方法论与最近快速发展的方法论。 很明显，传统的开发方法更适用于开发平台型产品，例如操作系统，中间件系统和数据库系统等，这些都是构建应用程序的基础，而最新的快速开发方法更为合适用于开发面向应用的产品。看起来似乎是：开发方法的选择与正在开发的产品的成熟度有关。 从版本N到N 1版本，并且Ngt; 5的产品，和那些发布版本0或1的新产品等更成熟的产品来讲，时间不太紧迫。 接下来，让我们探讨各种快速开发方法的优点和缺点，这些与基于Oracle的应用程序的开发相关性很强。以上是本章其余部分的前言，其余部分将介绍如何在基于Oracle的应用程序中设计性能和可扩展性。
本章的剩余部分将讨论以下主题：
bull;快速开发方法
bull;开发计划
bull;需求收集
bull;数据建模的概念设计
bull;规范化的逻辑设计
bull;物理设计
bull;实施
bull;发布到市场（RTM）
bull;后续改进
请注意，本章和下一章将涉及编程知识，会包含SQL和Java。 对于Java，我们将主要依赖其最流行的开源Java开发平台之一——Spring Source。 我们还将介绍一些最新的热点技术，如RESTful Web服务。 Spring有一个非常大的软件开发者基础，RESTful Web服务则是移动趋势，而Oracle是最好的数据库技术，所以我们乐在其中（也可以认为这是一个可以获得有价值的Java开发技能和基于Oracle的应用程序的机会）。 让我们从快速开发方法开始。
14.1 快速开发方法
为了设置适当的期望值，我必须提到这一节不是对每个主要的，现代的快速软件开发方法进行详细介绍。每种快速开发方法的概述将进行简述，但会足够清楚，以便了解您的产品在开发中遵循哪种开发方法。 了解您的项目所遵循的开发方法可能有助于更好地与您的团队合作，这会为您的项目做出巨大贡献。
这里是每个主要的快速发展方法的简要介绍（你可能听说过很多关于前三个，但较少关于最后三个）：
bull;敏捷开发（Agile Development）。 这是一个基于迭代或基于drop的开发方法，按照时间先后顺序的测量大致以每两个星期的频率进行。 由于其敏捷性，它更多地依赖于较不正式的沟通，例如口头或面对面沟通，而不是正式文件。 有了这种方法，在产品发布的最后阶段，正式的文档便可以完成。 敏捷开发的优点就是敏捷，所以它可以更有效和更高效; 但是敏捷同时也是一把双刃剑，如果团队规模太大或者团队成员的自律能力较差，那么这种开发可能会变得不那么有效和高效。
bull;极限编程（Extreme Programming）。 极限编程的主要目标是减少变化带来的花销。 这种方法致力于从最简单的解决方案开始，并逐步增加更多的功能。 它的核心是通过设计和编码，满足眼前的需求，而不是未来或未来的需求。 将设计和编码用于不确定的未来需求，意味着将资源用于可能不需要的东西的风险。 优点是它满足了眼下的需求，但从长远来看它可能会损失很多。
bull;迭代式瀑布（Scrum）。 这是一个基于角色的方法，主要有三个角色：
o“Scrum Master”，作为项目经理角色。
o“Product Owner”，作为业务角色。
o“Team”，作为负责需求分析，设计，实施和测试的所有成员。
Scrum方法通常用2至4周测量sprint中的项目进度。 每个sprint的目标是创建一个可发货的产品增量，但如果项目的规模足够大，则不太可能实现这样一个过于乐观的目标。 这种方法的另一个特点是整个产品积压被分成多个sprint积压，使其更易于管理和更好的优先级。 这种方法可能是今天最广泛使用的方法。
bull;精益开发（Lean Development）。 这种方法强调交付速度更快，功能更少 - 80％的今天比100％的明天更好的思维。 这是典型的多代发行产品。 这种方法采用首先捕捉市场份额的策略，但如果由于缺少功能，产品的吸引力较低，可能会产生反作用。
bull;联合开发（Joint Development）。 这种方法使客户出现在产品开发的整个生命周期。 通常，将驻留的客户联络人放置在供应商站点，这使得开发的内容是客户所需要的。 这种方法适用于定制产品，无论是全新的还是传统的替代品，如电缆或移动电话公司的计费软件产品。
bull;原型开发（Prototyping Development）。 这种方法更适合概念验证类型的项目。 它通常涉及较长的开发周期，较大的前期成本和更长的投资回报期。 它有助于降低采用新技术解决极具挑战性的任务的风险。 替换20到30年前的旧技术构建的大型应用程序就采用这一方法。
如图所示，没有一种单一的开发方法适合所有类型的项目。 然而，这并不意味着使用何种方法不是一个关键问题。 也许多种方法的混合，并结合每种方法的相关优点将最有效，但这超出了本文的范围。
在本章的剩余部分，让我们来看看开发高性能和可扩展性的基于Oracle的企业应用程序的所有必要的阶段和措施，而不必在意具体采用哪种开发方法。让我们从下一节开始介绍。
14.2 规划
提前计划好是规划的关键。 计划的内容将在接下来的几个小节中描述，从形成愿景，定义目标，进行ROI分析，开展可行性研究，最后形成项目团队。 这些都是非技术问题，但在一定程度上，它们可能比技术问题更为关键，因为一个计划良好的项目可以贡献高达项目成功率的80％。 让我们接下来展开每个主题。
14.2.1 Vision
一个伟大的愿景或许是一个伟大的产品家族唯一的也是最重要的元素。 在这方面著名的例子包括比尔·盖茨对PC的愿景和史蒂夫·乔布斯对苹果5的愿景（即iPod，iMac，iPhone，iPad，..），他们两人都控制了各自产品领域的整个世界。 这些愿景背后是杰出的个人和其超常的执行能力。 另一个同样令人印象深刻的例子是谷歌，谷歌并不ASDFGJLXVM/第一个开始基于网络的搜索业务，但完成了最后一个在其领土不可动摇的位置。 所有这些例子证明了一件事：一个伟大的愿景和杰出的执行能力可以取得前所未有的成功。
然而，对于大多数软件项目，范围和规模都小得多。 但是，一个非常有能力的高层管理团队并且拥有正确的愿景是产品成功的关键。 产品背后若没有正确愿景，该项目最终将成为一个失败而且代价高昂的活动。 不幸的是，关于如何提出一个伟大的愿景的教科书并不存在，在我看来，这方面天赋尤胜于教导和学习。 所以让我们假设正确的愿景已经存在，那我们如何使愿望得以成真呢。
14.2.2 Objectives
目标的定义是关于你在项目背后的驱动愿景中实现的目标。 这应包括：
bull;目标客户或用户群
bull;潜在市场的规模
bull;作为您公司更大产品组合中的核心组件之一
bull;所有必要的功能特性
bull;所有主要的非功能需求（例如，支持Nusers或某个事务卷等）。
bull;其他相关退出标准
注意，定义目标是一种与实际技术实现脱钩的活动。 它更多地受到设想的潜在商业前景的驱动。 因此，下一个自然的步骤是进行ROI分析，如下所述：
14.2.3 ROI Analysis
很显然，开发一个软件产品，在各个方面都是耗费的工作，从覆盖人力，到测试设备，到获得其他必要的软件产品等。 因此，对所有软件项目来说，仔细分析成本和预期收益是不可或缺的。 如果一个项目中途停止供资，那将是灾难性的，或者会永远恢复投资并开始看到利润。
正如本文所提的软件性能和可扩展性工程方法一样，ROI分析也应该采用基于数据和事实的方法，而不是基于意见的方法。 最后，这一切都取决于预计的ROI是否足够准确。 然而，如何进行ROI分析是一个非技术问题，我们可以将它推迟到专业人士去处理。 然而，我们需要知道的是，ROI分析做出了各种假设，因此需要进行支持的可行性研究，如下所述。
14.2.4 Feasibility Study
项目可行性研究的非技术方面，包括给定时间框架，预算，工作人员和材料的初步估计。 在技术方面，一个关键任务是确定要克服的潜在技术障碍，以便实现某些非功能需求，例如，该产品将能够支持10,000个并发用户或4000万客户 帐户。更繁琐的问题可能包括运行产品的硬件平台和操作系统平台，构建产品的中间件和数据库平台，要解决的开发平台（例如，Java或.NET与其他编程平台），等等 。
在这里存在另一个经典的困境。 为了证明一件事是可行的，你需要先构建它; 但游戏规则却是先验证他而不是先构建它。 我的意见是，灵丹妙药是不存在的，但对于现代硬件和先进能力的充足的知识，真实的的经验与所有相关的，建筑块，支持的软件技术，以及专业水平掌握的一些分析方法，如排队理论，都可以比纯粹的盲目猜测更好。 本文中的一些定量案例研究和许多其他产品特定的基准报告可能在这方面非常有帮助。
最后，一个伟大的愿景需要杰出的执行力，以使其成功; 并且一个伟大愿景的杰出执行力的核心部分是一个非常有能力的项目团队。 接下来，这个主题会被简单提及
14.2.5 项目团队组成
项目团队的效率，生产力决定了项目的成功与否。 无论是成立新团队还是调整现有团队，都应考虑以下因素：进一步推迟，团队文化，专业覆盖，适当的团队规模
14.3 需求收集
正式的需求收集过程将包括采访，调查，观察，文件审查等活动。 由于这个网上银行示例只是一个示例应用程序，我们只做最低限度需要在这里，以帮助你了解最终将什么实现到这个示例应用程序中。这个示例网上银行应用程序的功能需求非常简单，如下所述：
bull;它将允许用户登录并检查余额和帐户活动。
bull;它将允许用户在不同帐户之间转移资金（例如，在支票和储蓄之间等）。
bull;它将允许用户提交在线账单支付。
一些非功能性要求可以包括，如果它是真实产品：
bull;支持多达N个并发用户，其中N可以大到数百万
bull;在夜间窗口（例如上午2:00至上午5:00）内为所有帐户生成月度报表。
但是由于这是一个示例应用程序，这样的非功能需求将不会被拉伸，部分是因为缺乏测试所需的正确硬件。 接下来，我们将介绍这个示例应用程序的几个用例。
14.3.2 用户视图
用户视图可以被认为是对所定义的用例的更详细阐述。 它可以在网页，屏幕，表单或报告中表示在产品投入使用之后用户将看到什么。 例如，用户视图可能在用户登录此在线银行示例应用程序后显示网页。 其他用户视图可以包括登录/注销页面，账单支付页面，转移页面等等。 由于这是一个简单的示例应用程序，列出一系列网页中的实际用户视图将占用太多空间，因此在此省略。
用户视图的集合也可以被认为是用户界面模型。 通过检查用户界面模型，我们可以提取业务流程和业务实体，这将在下面讨论。
14.3.3业务流程，实体和业务规则
在更广泛的意义上，业务流程是当一起执行时作为服务向客户展示的一系列活动或任务。 在典型的组织中，存在三种类型的业务过程：（1）构成核心业务的操作过程体现为多个创收流，⑵管理业务在有效模型下运行的管理过程，以及⑶ 支持核心业务流程和管理流程作为必要的开销。 然而，由于我们在这里处理一个简单的示例网上银行应用程序，我们不会关心与所有这些类型的业务流程相关的复杂性。
具体到我们的示例网上银行示例，业务流程可以从上一节中讨论的用户视图派生。 可以使用描述所涉及的一系列活动的流程图来最佳地描绘和可视化业务过程。 图14.1示出了表示在线账单支付提交过程的流程图。
有两个依赖概念，没有这些概念，业务流程不能存在：实体和业务规则。 实体是业务流程可以
全文共6073字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[145933]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
