c#

 

 

SQL:

 

 

在XAML中定义了一个控件，如下：

<Grid x:Name="FormContainerElement" ... />

自定义控件代码*.cs如下：

[TemplatePart(Name = "FormContainerElement", Type = typeof(Grid))]

public class MyControl : Control

{

     public MyControl()

     {

          DefaultStyleType = typeof(MyControl);

     }

 

     private Grid formContainerElement;

 

     private Grid FormContainerElement

     {

          get

          {

               return formContainerElement;

          }

          set

          {

               formContainerElement = value;

          }

     }

 

     public override void OnApplyTemplate()

     {

          FormContainerElement = GetTemplateChild("FormContainerElement") as Grid;

          base.OnApplyTemplate();

     }

}

 

红色标注的方法将XAML中的控件负责和*.cs中的控件绑定，一定不能缺少，否则...

 

Silverlight的呈现和逻辑分离有点似曾相识，JSF好像...

对于new()约束，大家可能有一个误解，以为使用了new约束之后，在创建对象时与非泛型的版本是一致的：

public class Tester<T>
where T:new()
{
public Tester()
{
t = new T();//等同于非泛型版本的new? 例如 object o = new object();?
}

private T t;

}

    事实上，使用new关键字的作用只是让编译器在泛型实例化之处，检查所绑定的泛型参数是否具有无参构造函数：

Tester<SomeType> t = new Tester<SomeType>();
//此处编译器会检查SomeType是否具有无参构造函数。若没有则会有compile error。

    而Tester<T>类的构造函数中的new代码，实际上等同于下面的代码：

public class Tester<T>
where T:new()
{
public Tester()
{
　t = System.Activator.CreateInstance<T>();
}

private T t;

}

    也就是说，仍然是用反射机制来获取泛型对象的实例的。

今天想看看Silverlight中ComboBox控件的实现原理，用Reflector将System.Windows.dll中的资源保存了下来，在看ComboBox的Template时发现一个问题，如下图所示：

 

画红线的那句看起来比较奇怪，VisualStateManager好像只是和显示状态有关，在MSDN中没有看到与Setter标签配合使用的情况呀，查阅了Silverlight 《Beta 2 之后的重大更改》还是没有发现关于vsm:Setter的说明...

个人猜想这个应该还是Beta版和正式的差别之一吧，难怪前两天我反编译出来的代码老是报错，可能就是内含了这样的语句，但是仍有点不解的是，System.Windows里面的控件也包含了这句，为什么它们就不报错呢？也许...也许是与internal有关吧，MS总是喜欢搞这种飞机，B4！

     摘要: 第一步：开启Expression Blend2 SP1第二步：新建一个项目。第三步：拖一个Button控件至美工板（这个名字真奇怪）上。第四步：使用美工板顶部的痕迹导航栏（这个名字更奇怪）来创建按钮模板的副本。第五步：定义Style名称和位置。第六步：把App.xaml中原Button样式不需要的部分屏蔽掉。[代码]第七步：在App.xaml的适当位置添加一个Grid,命名为NormalState... 阅读全文

从第一次读到罗斯尼·安（J.H. Rosny Aine）的《求火（Quest for Fire）》开始，我就一直着迷于这种“探求”风格的作品。在我看来，一个探求类故事的精髓，就是一组形形色色的人，他们开始一段漫长而艰险的历程，试图寻找难以发现的目标，最终却找到了别的东西，而这个意外的收获通常比原来要找的东西更有价值、更重要。无论是《绿野仙踪》还是《指环王》，我总无法抗拒被这类故事深深感染。

我认为把我关于SOA的看法的演变过程比喻为“探求”是相当贴切的，而且“探求”也解释了我对治理的愿景与业界流行看法不同的原因。在2004年秋，我在一家主要的EAI/SOA平台厂商工作。那时SOA很热，于是依据市场需求，我们的产品被定位为SOA。不用说，我们的竞争对手们也都声称自己的产品是 SOA。然而，随着我们完成越来越多的企业级实现，我们发现，很明显市场讯息不完全对。如果你采用我们的产品、采取我们的方法、按照我们的指导方针与最佳实践（即便采用我们的专业服务）去实施的话，最终得到的将不是SOA，至少不是原本预料的SOA。没错，它能完成一定的功能并满足最初的特定目标，但至于履行已展望多年的SOA最初承诺，它就不行了。SOA承诺将提供多用途的、粗粒度的、松耦合的、可动态发现的、易于组合的、易于重用的服务，正是这种承诺使得SOA的概念如此受到业务与IT部门的青睐，从而令SOA成为CIO们的战略计划、RFI/RFP及产品特性列表中不可或缺的一项。我不是在批评我们的产品——当时别的厂商能给自己的产品贴上SOA的标签，我们当然也能。问题出在SOA定义自身。当这个概念流行起来时，大家都在竞相“实现”它。于是，厂商和IT机构们开始按照它们自己所能支持的方案，悄悄地改动SOA的定义。结果，人人都实现了SOA，但几乎没人能从中受益。

基于这一背景，我们团队提出了一个经验性的问题：如何才能构建一个大家都认为符合SOA特征的平台呢？我们写了一份长达40页的白皮书来回答这一问题，并阐述了我们对SOA的看法，我们认为企业级SOA服务应当具备以下核心特征与支撑设施：

1. 服务的自包含性与模块性：包括模块可分解性（modular decomposability）、模块可组合性（modular composability）、模块可理解性（modular understandability）、模块化连续性（modular continuity）以及模块保护性（modular protection）；
2. 服务、消费者、基础设施、工具及遗留应用间的互操作性；
3. 消费者与提供者间的松耦合性；
4. 支持编配（Orchestration）及服务的可组合性；
5. 服务的可发现性，以及消费者与提供者间的动态绑定；
6. 服务、消费者及基础设施组件的位置透明性；
7. 无处存在的安全性：通过解决认证、授权、完整性、保密性、可问责性、身份识别及策略等问题中的一些或全部，在设计上确保SOA环境（包括服务、消费者、代理、合成应用、基础设施等）中的信任；
8. 支持可续航性（Sustainability）和自恢复性（Self Healing），包括监测、预测和缓解不期而至的意外行为和状况的能力，以及按需获取与释放资源的能力；
9. 服务版本化：通过允许同时存在不同版本的服务实现和消费者，支持SOA环境的演化；
10. 服务租用：显式定义并维护服务消费者与提供者之间的关系，并消除可能存在不利的相互假设（mutual assumptions）；
11. 网络可寻址的服务接口：具有灵活的调用机制，支持多种传输、协议及同步选项，以营造一个有活力的、多用途的SOA环境；
12. 粗粒度的服务接口：可以利用它们轻松地支持许多种服务消费环境；
13. 服务使用计量（实时的和历史的）；
14. 服务及其实现的监控、管理与控制；
15. 支持相关性与根源分析的异常与警报处理；
16. 有效的服务虚拟化，确保服务接口与服务实现的彻底分离；
17. 公开的、可核实的和可实施的服务质量（QOS），包括性能、可靠性、可用率、制度性、可访问性、完整性及安全性等等；

以上列出的这些，为我们评估SOA产品及实现的成熟度与完整性提供了一个很好的尺度。当我们用它来评价我们的旗舰产品时，得分仅为40±5%（具体得分取决于你想给予自己的代码多少宽容）。于是，不用说，我们开始为争取“剩下那60%”而努力。直到2005年秋1.0版发布之前，我们都是如此称呼我们所做的工作的。

正当我们要开始努力时，我们发现上述特征列表里漏了几项。不过，“SOA的19项核心特征”听起来不如“17项核心特征”好听，于是我们称之为“17+项核心特征”——我们正是这样偶然得到基于方面的SOA（Aspect-Based SOA）基础设施这个想法的。此想法是基于这样一个前提，即我们无法列举出SOA服务——作为适当的企业计算平台——所应具备的全部特征，是有其根本原因。这个原因就是：这些特征是基于实际的业务、制度等需求的，而这些需求是因行业、地理、时间及各个客户的具体情况而变的。市场所需要的，是一个可以实现和支持任意项服务特征的平台，而且要允许用户根据当前的业务需要（或甚至自由地）对这些服务特征进行增加、修改和删除。

这个相当荒唐的想法居然得到了我们第一个客户的首肯。这个来自部队的客户，即使按照军方标准衡量也算相当偏执的了，他们拿出了一份很长的关于安全性需求的列表，其中大部分我们都能做到（要么直接支持，要么可以推给他们自己的安全基础设施）。但是有一项需求让我相当吃惊：该客户想防止一个写得很差的服务意外地把机密信息泄露给合法的、通过正确认证且经过适当授权的、但还尚未得到充分批准的用户。我的原始反应是：雇用优秀的开发人员，开展严格的质量保证（QA）活动，那么就没问题了！然后我意识到，在这个客户看来，解决意外泄露，跟受到别的行业重视的其他服务特征同样重要。于是，我在一小时之内设计好了一个审查方面（Censorship Aspect），它检查所有发给客户的服务响应，判断消息或各个片断的分类级别，将之与客户概要（在来访认证的过程中创建起来）中的许可级别进行对比，然后进行必要的纠正活动：或者隐藏部分信息，或者完全拦截。

其间，随着1.0版的发布，市场部需要一个名称来称呼它（由于某些莫名其妙的原因，他们不再热衷于围绕“剩下那60%”而努力了）。他们先是想到了 SOAi和SOAf（分别代表基础设施与基础），之后又有人提出了治理（Governance）（也许是因为当时这个词正逐渐时髦起来）。当时我还不熟悉这个词，所以在Google里搜索了一下，但怎么也无法理解它跟我们所开发的技术有什么关系。那时我的主要忧虑是：明确的定义没几个，含糊的定义却一大堆。

大部分厂商只是按照自己的能力范围来定义SOA治理。Systinet公司当时推行这样的观点，即SOA治理是一个用于WSDL的记录系统，它们提供了支持分类层次、发布工作流及订阅/通知机制的制品（artifacts）。AmberPoint将SOA治理看成一种自动发现依赖关系及“流氓服务”的机制，以及一种轻量级安全、监控和端到端错误分析的机制。设备厂商们（appliance vendors）将治理看成Web服务安全以及他们所拥有的媒介功能。所谓的专家们不断地提出朦胧而模糊的定义，比如下面这个令Pythia引以为豪的OASIS SOA参考模型里的定义：

SOA治理：通过结构化的关系、适合本机构的步骤与策略、以及分布式能力（可能处于不同控制域之下）的运用，来确保结果符合可测量的前提与预期的技术与原则。

经过一番思索之后，我觉得我们对SOA的理解就像是盲人摸象，都不够全面，于是我开始试图探求一个全面的定义。在本文剩余部分，我将给出SOA的定义，然后将SOA治理的愿景描述为该SOA的标志特征，另外我们也会通过一个例子来举例说明。

既然整个SOA问题域都充斥着模糊的术语，那么我们就先提出一些关键定义吧。首先，我们要看要治理的是什么。答案是显而易见的：当然是服务！然而，这一术语已被用于描述太多不同事物了，其中许多都跟SOA关系不大，所以我觉得有必要澄清这个概念——我通常的做法是给它增添一些限定。

一个企业服务就是一个自包含的组件，它提供业务功能，并具有一组可扩展的非功能性的、基于策略的特性（比如安全性、行业/客户定义的服务策略、管理、监控，生命周期管理等），它通过一个良好定义的、标准的、公开的接口来响应请求。

另一种描述企业服务的方式是：一个名称为CEO或业务总管所熟悉、而且其具体功能受到后者关注的服务。按照这一定义， invoiceCustomer、dischargePatient和launchICBM等都是企业服务，而invokeBAPI、 saveLogRecord和generateToken等则不是。参照该定义，SOA本身可被描述为：

一种提供并促使企业IT朝着企业服务环境的方向演化的架构风格。

最后，SOA治理就成为：

通过流程、实践与工具相结合，推动企业服务的生命周期，并提供方法来创建、传达、贯彻和管理目前对公司很重要的、关于非功能性服务特征的公司策略。

按照以上定义，SOA治理就是通过实现跨SOA参与者控制域边界的合理重用、把企业服务（Enterprise Services）从数字制品转变为现实业务制品的活动。为便于理解，我们举一个例子。

设想有一家名为热狗有限公司的跨国公司，它们有面包研究部和香肠开发部两个业务部门。这两个业务部门都有独立的管理团队、盈亏责任、IT部门及预算，只是在同一公司实体下运作。

某个时候，面包研究部的领导层决定实现一个新的应用来执行他们的核心业务功能。他们为实现这一任务花费了一百万美元。为了整个公司的利益，他们另外花了五万美元，以可重用服务的形式将新开发的功能包装并发布出来。

次年，香肠开发部的管理团队觉得他们需要构建一个新的应用来执行他们的核心业务，而面包研发部六个月前开发、包装、部署并发布的功能刚好可以满足他们的需要。[跟书本里的SOA业务案例颇为相似，是吧？]香肠开发部的IT部门现在有两个选择，要么重用面包研发部的服务，要么自己重新花一百万美元开发一套。我敢保证，如果下层技术采用的是CORBA或无治理的（按照前面的定义）SOA，那么对香肠开发部来说，唯一合理的做法是花钱实现处于自己控制域下的功能。这样做的理由是：原来的服务是由面包研究部实现并发布的，所以尽管那些服务在功能上100%符合需求，但对于以下这些决定“那些服务能否为香肠开发部业务环境所用”至关重要的因素，香肠开发部无法得知：

• 预期的可用率、可靠性、平均故障间隔时间（MTBF）及修复时间怎样？
• 现有的安全性和可问责性是什么样的？
• 那些服务实现已经通过审核并经证实符合相关条例（如美国的SOX，欧洲关于隐私的规定以及健康方面的HIPAA等）了吗？
• 支持什么样的性能水平？能够接受什么样的负载水平？
• 那些服务是永久性的吗？会不会随日期、星期或季节等有所变化？
• 对服务使用是如何进行计量和记账的？

即便香肠开发部的管理团队从面包研究部的同事那里得到了所有这些信息，仍存在一个至关重要的问题：我们怎么知道这些信息会不会在下周（也许是下个月或下一年）发生改变呢？

当我们的思考过程结束，并最终形成以上对SOA治理的看法时，有几件事变得明了了（至少对我们是这样）：

1. 与爱因斯坦相对论扩展牛顿经典力学、并形成后者所不适用的范围相似，这个对SOA治理的统一观点并非否定前面提到的、以及我在《SOA governance – the perspectives》这篇文章里详细描述过的那些零碎的定义与方法，相反，它而是构筑在后者基础之上的。
2. 若正确实现的话，这种SOA治理观点将为你带来一个能够符合前面提到的全部“17+项企业SOA核心特征”的方案。
3. 这样一种方案，能够把有缺陷的SOA平台与实现改造为真正的面向服务的架构（SOA），从而实现SOA的最初设想，并兑现所有承诺的优点。

最后，这一治理平台的构建其实比我们想象的要简单。而且，正如“探求”风格的特点，我们在这一过程中发现了许多预料外的、有价值的东西，比如委托治理（Delegated Governance）、分析时治理（Analysis-time Governance）、改建项目友好的治理（Brownfield-friendly Governance）和统一治理信息模型（unified Governance Information Model）等，这些为我们后续的文章提供了不错的主题。

查看英文原文：Quest for True SOA。

偶然的机会，发现微软也出品Ioc框架了，属于Microsoft patterns & practices系统的，名字叫Unity(Unity下载地址),考虑可能在手头的项目中会用到，因此下载下来把主要功能做了个测试，感觉马马虎虎，比起Spring好像是挫了点，但是没有办法，很多人有微软洁癖，除了微软的框架其他的用着都觉着不放心，好了，闲话少说，Go!

  对了，再废话一句，我不知道Unity的QuickStarts里面怎么净是编程方式下使用Ioc，如果是这样使用Ioc，那么看起来微软是不打算提倡“非侵入式”这个概念了，唉，搞不懂的Microsoft... 又说废话了，本文将介绍如何配置文件方式使用Unity，因为E文太差，Unity的文档只读了一知半解，如果在例子中有错误，请指正。

一.下载Unity，安装...

二.在项目中添加Microsoft.Practices.Unity.dll和Microsoft.Practices.Unity.Configuration.dll的引用。

三.Windows和Console项目请添加App.config文件，Web项目嘛就使用web.config好了，本例将采用Console项目（据说高手都喜欢使用Console，咱不是高手，装一下，嘿嘿~）。

四.使App.config看起来像下面这个样子：

 

 

这里需要解释点，否则就真的有点糊弄人了。

typeAlias节点是给不太容易识记的类型名起一个别名（似乎有点废话），让一个拥有很我字符的类型名“变”短点。

container节点定义管理依赖关系和生命周期的容器（Ioc容器概念），需要在配置中提供一个名称。

type节点从其mapTo属性就可以看出其用途了，它提供依赖关系和生命周期的具体定义。

插播题外话（关于老生常谈）：我们考虑这样一个应用场景：经常在设计评审会义上听R&D说：“我在做设计的时候，本来是想到...，结果考虑到项目时间紧张，我就只能先把XX公司的需求做了，没有考虑通用性的问题...”或者：“我本来以为我们的产品运行（安装）环境（流程）不会发生大的变化，没想到...”，往往这时候Boss就会生那些后果不是很严重的气，但是最终往往也只能把希望寄托于下一版本或下一个项目，但是往往下次再把这个过程重复一遍...

题外话续一（关于架构）：CSDN上的一篇文章曾给我留下极其深刻的印象：某位CEO说他们的系统运行了四十多年，而支持这个系统寿命的正是合理的系统架构。这句话让我深思了好久，一种什么架构能使一系统具有如此强大的生命力呢？以前看到的基本上都是系统因运行环境或负载变化而被淘汰，很少听说有系统寿命超过十年的，而这个公司的系统居然可以运行四十年以上！！！深思后得出点浅显的结论，这个公司的系统从一开始就运用了合理的架构，遵循了适时的正确的设计理论，因此，过程很轻易的演化为对象，对象很轻易的又演化为组件，组件又很轻易的演化为服务（也许它就是走了这样一个路线吧）。因此，我暗下决心，不再在我的设计过程加入那些自以为是的假设：不可能跨平台移植、不可能扩展功能、不可能负载增加、不可能...

题外话续二（关于Ioc）：有人可能会问，需求发生了变化后我可以重新写代码呀？我有丰富的控（组）件、我有强大的IDE，我针对客户新的需求修改现在的系统用不了多长时间...没错，肯定没错，绝对没错，本文不适合你。也有人可能问，Ioc看起来和Factory没什么区别呀，为什么还要花时间去学习它呢，Factory的确很棒，以前我也曾以掌握Factory模式沾沾自喜，但后来总发现Factory缺点什么，为什么当实例类型变化时还要去打开项目修改源代码呢？又有人说了，你不会使用配置文件么？配置文件？听起来不错，可是...可是如果我要任意的实现Singleton或是指定Instance初始值或是...又怎么办呢？Ioc框架组有人已经偷着笑了，小样，早让你们用我们的产品了吧...

题外话结束。

五.新建一个项目，在里面加入如下几个文件：

ISayHello2.cs

 

 

SayHello2Think8848.cs

 

 

SayHello2ACloud.cs

 

 

ISingletonDemo.cs

 

 

SingletonDemoImpl.cs

 

 

六.修改Console的Program.cs文件，使Main方法看起来像下面的样子：

 

 

七.F5一下。

结果：

 

 

本文仅示例了Unity最基本的最常用的功能，其他功能待续。

Unity中文资料比较少，今天找到一篇讲配置文件的，有兴趣可以点这里阅读。

1：SOA并非纯粹的技术性方法

　　如果得以成功执行，服务导向架构(SOA)并非只是一个技术性架构，理解这一点是非常重要。SOA范例旨在于对商业流程进行建模，这些商业流程并不能总是得到技术组件的直接支持。最终，服务可能由技术组件执行，但是商业流程本身要比支持它们的这些服务重要得多。

　　作为一种技术，SOA是一个工具，虽然这种技术本身没有提供直接的价值，但是与EJB或者.NET组件相比，SOA是一种更为廉价的代码行服务开发方式。另外，SOA应被当作是其它利益的实现者，比如改进更广泛的再利用，提高对商业流程的响应性以及与使商业流程保持更好协调性。

　　2：SOA不一定意味着网络服务

　　很多技术人员对SOA存在这样一种误解，认为SOA意味着必需使用网络服务。虽然网络服务可作为SOA策略的一部分，但它并不是必需的部分。服务的定义可以基于除HTTP以外的其它标准。和具体的实现技术相比，关注商业流程和服务的需求更为重要。通常，服务的环境将有助于决定其执行方式。

　　例如，对于包含了关键商业事务的服务而言，使用网络服务是不利的，因为我们无法通过SOAP/HTTP协议来保证交易。而且，很多服务可能需要异步操作，在这种情况下，基于队列和通道的消息系统可能是进行提供服务的最佳方式。当然，有效负载和界面依然可以使用XML来定义。

　　3：可以使用现有架构建立SOA

　　很多组织对于SOA可以使用现行架构来建立感到非常惊讶，例如，.NET和J2EE平台都可为网络服务开发、XML解析与生成，以及与MSMQ和JMS这类消息系统进行通信提供支持。

　　SOA堆栈常常缺乏流程管理层或自动化层面。不过，许多公司现在已经在企业应用集成 (EAI)工具上进行了投资，很多EAI工具能够提供流程自动化和管理层功能，它们可以从现有的应用程序或在.NET和J2EE平台上建立的应用程序中对服务进行访问。

　　4：SOA是一种(从组件、对象等)进化而来的方法

　　服务导向架构并不是一种全新的解决方案; 相反，SOA是技术与架构的自然进化。系统架构一直在不断进步，与商业保持高度一致。系统设计师与商家很早就认识到将技术与商业流程相协调的重要性，包括充分应用并合理化技术资源，以及为商业提供更好的支持。

　　SOA也在一定程度上源于早已有之的企业架构理论。企业架构对技术进行评估，但是更重要的是，它关注整个企业和全部的商业流程并提供了做出技术决策的背景信息。SOA工具则融合了互联网技术，如HTTP和XML，以及综合技术，如消息总线、转译技术和连接技术。

　　5：流程自动化是SOA的关键优势

　　许多组织和技术专家错误地关注服务架构内的服务实现与交付，不幸的是，他们没有抓住重点，SOA的真正价值体现在它是一个商业自动化工具。最终，软件和系统将会提高商业或组织的效率，这可以根据组织执行的活动或者流程来定义。因此SOA不应将焦点放在服务上，而应放在流程以及流程的改进上。

　　当然，我们也需要服务为流程提供支持。但是对于提高效率和改进流程的目标而言，它们是次要的，服务本身的价值有限。

　　6：SOA架构可能高度复杂

　　从某一角度看，SOA架构可以相当简单。例如，开发一个商业流程并确定所需的服务，这种要求就合理而直接。但是，要在数据和服务之间进行平衡，并实现有意义的目标则要复杂得多。

　　例如，假设有这样一种情况：用户使用订单服务在系统中下订单。这是相当简单的操作。但是如果您希望将订单上的数据和来自其它服务的数据关联起来呢?如果所有的服务共享同一个数据源，这时您可以跳过服务层，并生成报告。但是，如果一些数据属于本地服务，一些数据属于原有的主机系统，并且另外一些数据属于商业应用程序(比如SAP)，将这些数据集成在一起将会特别复杂。

　　7：SOA需要深入了解商业数据

　　因为SOA关注于商业流程，因此理解这些与流程密切相关的数据至关重要。例如，一个订单流程会包含很多重要的数据项，比如订单、客户、运输信息、发票、付款和收据; 更重要的是必须以一种标准的方式来记录这些数据，从而使流程中的每项服务都能以同样的方式理解这些数据。

　　对于现在拥有信息架构的组织而言，这并不是一个大问题。但如果大型组织没有信息架构或者信息架构支持有限，这一问题会导致实施过程中的长时间中断。因为大型企业通常拥有的数据多种多样，所以一般建议他们采用进化的方式来定义信息架构，即与“大爆炸”方式相反的方法。这意味着不必花费四年的时间来定义数据模型，而只需要在开发服务过程中花费少量时间来定义与那些服务相关的数据。这样，在执行每项服务或者流程时，就可以发展相关的信息架构来包含必需的数据项。

　　8：服务可简单可复合

　　定义服务可能是一个艰巨的任务。在某些情况下，我们很清楚需要哪些服务; 很多时候，服务相当简单。例如一个查找客户的服务，可能需要使用一些标准来查找用户并为服务的使用者提供标准化的客户记录。

　　然而，服务也可以复合形式存在。这意味着“超级服务”可以提供一个标准的界面，就像我们刚才查找客户的服务所提供的那样。在前面的例子中，暗指所有的客户信息都存储在同一个资料库中，所以很容易进行查找。但如果一些客户资料存放在大型主机中，一部分存放在SAP中，一部分存放在其它应用程序中，而另外一部分存放在Oracle数据库中呢?让我们假定在每一种系统上已经建立了查找服务的界面。换句话说，我们拥有在大型主机、SAP、其他的应用程序和Oracle数据库上查找客户的服务。我们新的查找客户的服务可以使用所有这些现有的服务来查找客户。现在，因为我们的服务要调用其它服务，它变成一个复合式的服务。当一个自动化流程模型自己成为一项服务时，也会建立复合式服务。

　　9：SOA的自动化可能有很多层面

　　自动化可以发生在不同的层面，这是服务架构经常被忽视的一个特点。很多SOA架构的错误在于只看到某一个层面的自动化，然而，在一个SOA解决方案中，自动化至少可以应用到两个关键领域。

　　第一个也是最明显领域的是商业流程层，在设计流程的时候，其中的步骤已经进行了连接并形成自动化。因为这些流程通常是基于日常商业活动，往往与人类的交互活动有关。在人类交互流程中实现自动化是一个重要的自动化层面。

　　另外一个重要的自动化层面是没有人参与的系统交互层，过去几年来，集成工具已经应用到这一领域。通过对系统间任务进行自动化，往往可以提高流程的总体效率。

　　在这些层面上使用不同的工具也是很重要，应该对人类交互、程序或系统间的交互区别考虑，从而采取不同的策略。

　　10：服务应当遵循相同的界面标准(包括协议和数据)

　　使用标准化的方法进行通讯对于服务而言非常重要。在SOA世界中，通讯由两个组件构成。一个是服务进行通信的网络协议，就好比是人们每天使用的通讯媒介一样，例如，如果您想和老板通讯，最好搞清楚老板喜欢接电话还是电子邮件。

　　第二个组件是通讯的数据或者语言，一旦您同意将HTTP或者JMS作为通讯机制，就等于确定了您交流的语言，例如，您的老板说法语而您说英语，可能就会造成通讯困难。在服务领域，通常使用XML作为语言，但这并没有提供足够的信息。必需对服务需要的数据进行清晰定义并达成一致，这样服务提供商与服务用户就能进行有效的通讯。

　　11：可以将服务外包

　　服务的另外一个优点就是它们不必作为整体组件购买，不必在内部进行管理，也不必从头进行开发。相反，可以将服务外包。这意味着在您需要一项服务向政府部门提交法规遵从文件时，您不必自己建立这项服务。各类公司为几乎每个产业部门提供各种服务。利用服务外包，您可以将主要精力放在与最重要的SOA策略——流程——上面。

　　外包方式的一个不足之处在于，如果您的竞争对手使用了同样的服务，您可能会丧失一些竞争优势。

　　另外一个需要考虑的问题是性能，这依赖于很多因素，主要包括网络连接性、可用性和反应时间。采用外部网络的服务可能会使您商业流程的性能降级。

　　12 服务可以在现有的系统和软件基础上建立

　　许多组织误认为SOA方式没有考虑到原有系统，如大型主机应用程序。实际上，SOA的一个最强大的价值就在于它允许组织重新利用大型主机和其它原有资产，这一点尤其重要，因为核心商业逻辑和核心商业数据通常保存在私有的原有系统中。通过服务来访问核心商业逻辑和数据，可以立即在自动化流程模型中重新利用这些资产。

　　当然，大型主机并不是唯一的原有数据源。微型计算机系统，如AS/400、VAX和HP3000等等，都可以以各种方式提供服务。很多工具都可以帮助与这些所有权系统进行通讯，并将它们的信息作为标准化的服务来传递。

　　13：性能是SOA系统的关键

　　尽管SOA为一个组织提供了很多利益，包括协调技术与商业，增强灵活性等; 它与性能有着密切的关系。因为在典型的SOA环境中，应用程序往往被高度细分，而程序之间的数据关联也很缓慢，在决策支持和报告系统中特别需要考虑这一点，以往这些系统只依赖少量数据源。

　　性能最大化的关键在于了解应用程序和系统性能在何处对于商业最重要。构建一个高性能的系统来支持一个并不需要它的商业流程是无益的。一旦确定关键流程，您只需要在有必要的地方改进并提升性能就行了。

　　14：SOA以四个组件为基础

　　一个成功的SOA交付计划有四个组件。第一个组件是定义商业流程，需要哪些服务来支持它们，以及哪些数据与它们相关。这是关于SOA的商业分析。

　　第二个组件是SOA的架构和模式，这是一组描述如何定义与实现服务的规则，指定通用的交付与使用模式，并制订开发服务需要遵循的原则与标准。

　　第三个组件是SOA的基础结构，这包括网络、服务器、存储设备、消息工具、整合工具以及流程自动化工具等等，它们支持服务与商业流程的开发与交付。

　　第四个组件是SOA的开发计划。该计划确定了服务开发与流程实现的先后次序，并且指导形成新服务与新流程项目。

　　15：建立SOA可能相当麻烦

　　尽管SOA是一个进化性技术，尽管在SOA领域已经具备相当丰富的知识储备，但由于各种原因，建立SOA仍然相当麻烦。最主要的原因在于SOA和其它变革一样：它需要大量的沟通与社会化，使组织为变革做好准备。

　　在克服了变革的困难之后，还可能有其它技术性问题。这些问题包括建立适当的服务交付和使用模式、培训技术开发团队、以及为支持SOA开发模式对组织进行的可能的结构变化。尽管SOA的技术组件可以在隔离的环境下进行测试和验证，SOA依然是一个全企业参与的方法，因而需要付出更多的努力来规划服务架构的控制与管理。

     摘要: http://msdn.microsoft.com/en-us/library/cc816062.aspx#MainExampleInject Some Life into Your Applications—Getting to Know the Unity Application Block patterns & practices Developer CenterAlex Home... 阅读全文