管理可用资源
公共语言运行库 (CLR) 使用垃圾回收器来管理对象生存期和内存使用。这意味着无法再访问的对象将被垃圾回收器自动回收，并且自动回收内存。由于多种原因无法再访问对象。例如，可 能没有对该对象的任何引用，或者对该对象的所有引用可能来自其他可作为当前回收周期的一部分进行回收的对象。尽管自动垃圾回收使您的代码不必负责管理对象 删除，但这意味着您的代码不再对对象的确切删除时间具有显式控制。请考虑下列原则，以确保您能够有效地管理可用资源：
1)确保在被调用方对象提供 Dispose 方法时该方法得到调用。如果您的代码调用了支持Dispose 方法的对象，则您应该确保在使用完该对象之后立即调用此方法。调用 Dispose 方法可以确保抢先释放非托管资源，而不是等到发生垃圾回收。除了提供 Dispose 方法以外，某些对象还提供其他管理资源的方法，例如，Close 方法。在这些情况下，您应该参考文档资料以了解如何使用其他方法。例如，对于 SqlConnection 对象而言，调用 Close 或 Dispose 都足可以抢先将数据库连接释放回连接池中。一种可以确保您在对象使用完毕之后立即调用 Dispose 的方法是使用 Visual C# .NET 中的 using 语句或 Visual Basic .NET 中的Try/Finally 块。 下面的代码片段演示了 Dispose 的用法。
C# 中的 using 语句示例：
using( StreamReader myFile = new StreamReader("C:\\ReadMe.Txt")){
string contents = myFile.ReadToEnd();
//... use the contents of the file
} // dispose is called and the StreamReader’s resources released
Visual Basic .NET 中的 Try/Finally 块示例：
Dim myFile As StreamReader
myFile = New StreamReader("C:\\ReadMe.Txt")
Try
String contents = myFile.ReadToEnd()
’... use the contents of the file
Finally
myFile.Close()
End Try 注：在 C# 和 C++ 中，Finalize 方法是作为析构函数实现的。在 Visual Basic .NET 中，Finalize 方法是作为 Object 基类上的 Finalize 子例程的重写实现的。
2)如果您在客户端调用过程中占据非托管资源，则请提供 Finalize 和 Dispose 方法。如果您在公共或受保护的方法调用中创建访问非托管资源的对象，则应用程序需要控制非托管资源的生存期。在图 8.1 中，第一种情况是对非托管资源的调用，在此将打开、获取和关闭资源。在此情况下，您的对象无须提供 Finalize 和 Dispose 方法。在第二种情况下，在方法调用过程中占据非托管资源;因此，您的对象应该提供 Finalize 和 Dispose 方法，以便客户端在使用完该对象后可以立即显式释放资源。
垃圾回收通常有利于提高总体性能，因为它将速度的重要性置于内存利用率之上。只有当内存资源不足时，才需要删除对象;否则，将使用所有可用的应用程序资源以 使您的应用程序受益。但是，如果您的对象保持对非托管资源(例如，窗口句柄、文件、GDI 对象和网络连接)的引用，则程序员通过在这些资源不再使用时显式释放它们可以获得更好的性能。如果您要在客户端方法调用过程中占据非托管资源，则对象应该 允许调用方使用IDisposable 接口(它提供 Dispose 方法)显式管理资源。通过实现 IDisposable，对象将通知它可被要求明确进行清理，而不是等待垃圾回收。实现 IDisposable 的对象的调用方在使用完该对象后将简单地调用 Dispose 方法，以便它可以根据需要释放资源。注如果您的可处置对象派生自另一个也实现了 IDisposable 接口的对象，则您应该调用基类的 Dispose 方法以使其可以清理它的资源。您还应该调用实现了 IDisposable 接口的对象所拥有的所有对象上的 Dispose。Finalize 方法也使您的对象可以在删除时显式释放其引用的任何资源。由于垃圾回收器所具有的非确定性，在某些情况下，Finalize 方法可能长时间不会被调用。实际上，如果您的应用程序在垃圾回收器删除对象之前终止，则该方法可能永远不会被调用。然而，需要使用Finalize 方法作为一种后备策略，以防调用方没有显式调用 Dispose 方法(Dispose 和 Finalize 方法共享相同的资源清理代码)。通过这种方式，可能在某个时刻释放资源，即使这发生在最佳时刻之后。注要确保 Dispose 和 Finalize 中的清理代码不会被调用两次，您应该调用GC.SuppressFinalize 以通知垃圾回收器不要调用 Finalize 方法。垃圾回收器实现了 Collect 方法，该方法强制垃圾回收器删除所有对象挂起删除。不应该从应用程序内调用该方法，因为回收周期在高优先级线程上运行。回收周期可能冻结所有 UI 线程，从而使得用户界面停止响应。
规范
您可以使用许多工具和技术来帮助您对应用程序进行规范，并且生成度量应用程序性能所需的信息。这些工具和技术包括：
1)Event Tracing for Windows (ETW)。 该 ETW 子系统提供了一种系统开销较低(与性能日志和警报相比)的手段，用以监控具有负载的系统的性能。这主要用于必须频繁记录事件、错误、警告或审核的服务器应 用程序。
2)Enterprise Instrumentation Framework (EIF)。EIF 是一种可扩展且可配置的框架，您可以使用它来对智能客户端应用程序进行规划。它提供了一种可扩展的事件架构和统一的 API - 它使用 Windows 中内置的现有事件、日志记录和跟踪机制，包括 Windows Management Instrumentation (WMI)、Windows Event Log 和 Windows Event Tracing。它大大简化了发布应用程序事件所需的编码。如果您计划使用 EIF，则需要通过使用 EIF .msi 在客户计算机上安装 EIF。如果您要在智能客户端应用程序中使用 EIF，则需要在决定应用程序的部署方式时考虑这一要求。
3)Windows Management Instrumentation (WMI)。WMI 组件是 Windows 操作系统的一部分，并且提供了用于访问企业中的管理信息和控件的编程接口。系统管理员常用它来自动完成管理任务(通过使用调用WMI 组件的脚本)。
4)调试和跟踪类。.NET Framework 在 System.Diagnosis 下提供了 Debug 和 Trace 类来对代码进行规范。Debug 类主要用于打印调试信息以及检查是否有断言。Trace 类使您可以对发布版本进行规范，以便在运行时监控应用程序的完好状况。在 Visual Studio .NET 中，默认情况下启用跟踪。在使用命令行版本时，您必须为编译器添加 /d:Trace 标志，或者在 Visual C# .NET 源代码中添加 #define TRACE，以便启用跟踪。对于 Visual Basic .NET 源代码，您必须为命令行编译器添加 /d:TRACE=True。
规划SOA参考架构
2009年上半年计算机技术与软件专业技术资格(水平)考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见：
SOA 参考架构 (Reference Architecture) 是一个框架，使各个项目都有一个遵从的依据，借以促进一致性、最佳实践典范，和标准化。参考架构并不受限于目前的 IT 现况，而应该针对一个经过深思熟虑的愿景目标，可以说是 IT 指导未来所有的新开发工作，借以实现该目标的参考依据。一般来说，2-3 年的规划，是一个比较合适的涵盖范围，既能提供足够的时间来达成面向服务的转型，而又不至于过于长远而虚幻。因此，参考架构提供了一个沟通目标愿景的方 法，协助部门和角色各异的 IT 人员，逐渐朝向该目标会合。
高效的 SOA 需要采用新的方法来对待 IT 基础设施，并且根据个别企业的需求来量身定做，并将服务基础架构、共享的技术服务、安全服务，以及信息/数据、和遗留系统访问服务等，全部定义在内。
为了满足 SOA 的要求，所有公司都需要 SOA 参考架构和路线图，来指导部署一套能随时间演进、而逐渐丰富的工业级服务基础设施，同时指导对面向服务应用的开发和管理。
此外，企业也需要对参与 SOA 架构的各个个别系统的设计，进行监管，并在适当的地方，建立通用服务，透过协作来发挥更高的效率。对于这些举措，连接端点的标准化(通过建立定义清晰的契约和接口)，是达成 IT 系统一致性的先决条件。
SOA 参考架构指导所有实施 SOA 的各个项目，能共同朝向企业级服务，和 SOA 基础架构标准方向的集中发展，尽早使企业从中获益。换句话说，参考架构规划的重点，在于开发一个特定于某个企业需要、切实可行的路线图，以填补当前和愿景 目标之间的鸿沟;评估用于开发、部署和管理、监控的现有系统和技术，定义目标状态愿景，目标参考架构模型。
SOA 参考架构可说是指导 SOA 成功的蓝图，其作用包括：
促进 IT 与业务的紧密配合： 参考架构的制定，以业务驱动力和 IT 目标为出发点，分析 SOA 解决方案能对这些驱动力带来多大的正面影响，进而为从目前 IT 现况演化到愿景架构，定出实现架构、相关规范及路线图。参考架构因此提供了从业务和 IT 目标，到实现架构间的可跟踪性，是业务与 IT 之间进行沟通的重要媒介，是企业实现业务灵活性、可管理性和变更规划的基础。
协助企业向重用、团队协作和资源共享的文化迁移：参考架构确立了 SOA 架构标准和技术部署的最佳实践，为日后各个 SOA 的实施项目，订立架构遵从性的度量标准和指标。
参考架构并非一成不变。在一个新的 SOA 策略与规划迭代中，SOA 的参考架构和规范标准，可能需要针对新的业务、IT 情况，和已实施的 SOA 项目中得到的反馈，进行调整，因此，SOA 参考架构不仅是 IT 模板，也是也描述 SOA 原则和标准的活文档。
我们可以将参考架构的内容，粗分为两大部分：
对服务建立一套共同的词汇和做法，包括：
服务的正式定义 – 例如服务必须由契约 (contract)、接口 (interface)，和实现 (implementation) 所组成
服务的分类(核心业务功能服务，数据服务，展现服务等)，以及各类服务的设计原则和建议
接口标准 (JMS, RMI, HTTP 等)，建议的接口样式(例如：尽量采用粗粒度、异步的服务调用模式)，可靠性要求等
需要遵从的 WS-* 标准
安全策略
服务版本控制策略
服务和数据模型采用规范
服务生命周期定义
与服务基础设施，例如企业服务总线 (ESB)、业务流程管理 (BPM)、注册库 (Registry)、资产库 (Repository) 等相关的规范，包括：
必须支持什么样的部署配置
必须具备什么样的能力
各个部件的责任
部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务;换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系
各个部件应支持那些科技和标准(例如：SCA, SDO…)
有哪些安全顾虑需要考虑，如何管理权限
要采用哪些产品
由于在规划服务基础设施参考架构时，需要涵盖几类 SOA 参与者和干系人 (stakeholders) 各自不同的顾虑，包括架构师、程序员、和负责部署、运营、监控的 IT 人员，我们可以采用一个针对服务基础设施参考架构调整过的 4+1 视图(如下)，来协助我们分离顾虑，来将不同层面的规范和目标架构一一制定，通过逻辑、实现、部署，和进程等四个视图，配合最佳实践典范和模式，来对参考 架构的各个层面，进行描述和规范，如附图。
参考架构的规划过程(如下图)，应先起于业务驱动力 (business drivers) 分析，可有助确保目标架构能够支持业务的发展策略和方向，展现 SOA 建设对业务的价值，彰显 SOA 投资的正当性，并获得相关业务部门的经费赞助。以金融行业为例，业务驱动力包括像是：
提升效率
借贷流程优化
呼叫中心优化
增长销售额，并显著超越同业
快速灵活地推出创新的金融商品
扩展客户关系，统合客户数据
交叉销售
依据关系定价的策略
降低成本
这一类的价值驱动。分析业务的价值驱动后，接着考虑各种 IT 目标，以及它们如何支持这些业务驱动力;例如：
从关注各业务线烟囱/竖井式的应用系统，转向专注于跨系统/业务线的流程/服务
IT 资产重用
提高跨部门协作的业务流程的透明度
并且应订立评价标准，作为日后考核实现各价值驱动力的指标。接着下来，我们可以根据业务和 IT 驱动力，进一步制定恰当的 SOA 策略，考虑采用 SOA，将对那些业务线，在那些驱动力方面，产生最大的价值，据以订立实施 SOA 项目的优先级别。
√√ 代表 SOA 项目能产生很大的正向影响，依此类推。
针对各价值驱动力，我们可以参考附图中的矩阵分析方式，从价值链或业务线中的各个主要的职能(纵向)，和各个识别出来的业务和 IT 驱动力(横向)，对 SOA 所可能产生的正面影响力，一一进行评估，进而挑选出面向服务解决方案最能嘉惠的业务能力，作为首期实施 SOA 项目的切入点。图中的范例只是一个三万尺高空的起点，在真实的情况下，往往会针对范例中某个或某几个得分较高的业务线，往下展开细化，对该业务线中的各个 主要业务能力，进一步进行 SOA 价值驱动力分析;换句话说，价值链分析中的各个职能域，应该自粗到细，逐步钻取、drill down 到适当的深度，才能更精准地确定 SOA 能对哪些要迫切改善的业务能力，带来最大价值。
依据业务和 IT 驱动力，选定了 SOA 策略后。接着应根据企业目前的现况，和未来 2-3 年的目标，进行差距分析，并根据最佳实践典范 (best practices)，制定 SOA 发展的蓝图、路线图和指导规范，完成参考架构的规划。接着便可开始根据路线图中制定的项目，以渐进的方式，通过一致的服务工程方法，一个接一个项目去执 行，并在此过程中，逐渐将蓝图中的服务基础设施搭建起来。
考虑用户的观点
当您为智能客户端应用程序确定合适的性能目标时，您应该仔细考虑用户的观点。对于智能客户端应用程序而言，性能与可用性和用户感受有关。例如，只要用户能够继续工作并且获得有关操作进度的足够反馈，用户就可以接受漫长的操作。在 确定要求时，将应用程序的功能分解为多个使用情景或使用案例通常是有用的。您应该识别对于实现特定性能目标而言关键且必需的使用案例和情景。应该将许多使 用案例所共有且经常执行的任务设计得具有较高性能。同样，如果任务要求用户全神贯注并且不允许用户从其切换以执行其他任务，则需要提供优化的且有效的用户 体验。如果任务不太经常使用且不会阻止用户执行其他任务，则可能无须进行大量调整。对于您识别的每个性能敏感型任务，您都应该精确地定义用户的操作以及应用程序的响应方式。您还应该确定每个任务使用的网络和客户端资源或组件。该信息将影响性能目标，并且将驱动对性能进行度量的测试。可 用性研究提供了非常有价值的信息源，并且可能大大影响性能目标的定义。正式的可用性研究在确定用户如何执行他们的工作、哪些使用情景是共有的以及哪些不是 共有的、用户经常执行哪些任务以及从性能观点看来应用程序的哪些特征是重要的等方面可能非常有用。如果您要生成新的应用程序，您应该考虑提供应用程序的原 型或模型，以便可以执行基本的可用性测试。
相关推荐