׃本站不允怸传zip、rar文gQ所以把压羃好的文g做成doc的内|对象了Q打开doc解压卛_
下蝲地址Q?A >http://sunfruit.blogchina.com/inc/JSF.doc
]]>
注：原脓来自J?/P>
Ioc模式
分离xQ?Separation of Concerns : SOCQ是Ioc模式和AOP产生最原始动力Q通过功能分解可得到关注点Q这些关注可以是 lgComponents, 斚wAspects或服务Services?/P>
从GoF设计模式中，我们已经习惯一U思维~程方式QInterface Driven Design 接口驱动Q接口驱动有很多好处Q可以提供不同灵zȝ子类实现Q增加代码稳定和健壮性等{，但是接口一定是需要实现的Q也是如下语句q早要执行：
AInterface a = new AInterfaceImp();
AInterfaceImp是接口AInterface的一个子c，Ioc模式可以延缓接口的实玎ͼҎ需要实玎ͼ有个比喻Q接口如同空的模型套Q在必要Ӟ需要向模型套注石膏，q样才能成ؓ一个模型实体，因此Q我们将Zؓ控制接口的实现成?注射"?/P>
Ioc英文?Inversion of ControlQ即反{模式Q这里有著名的好莱坞理论Q你呆着别动Q到时我会找你?/P>
其实Ioc模式也是解决调用者和被调用者之间的一U关p，上述AInterface实现语句表明当前是在调用被调用者AInterfaceImpQ由于被调用者名U写入了调用者的代码中，q生了一个接口实现的原罪Q彼此联p，调用者和被调用者有紧密联系Q在UML中是用依?Dependency 表示?/P>
但是q种依赖在分d注的思维下是不可忍耐的Q必dԌ实现调用者和被调用者解耦，新的Ioc模式 Dependency Injection 模式由此产生了， Dependency Injection模式是依赖注的意思，也就是将依赖先剥，然后在适当时候再注射q入?/P>
Ioc模式QDependency Injection模式Q有三种Q?/P>
W一U类?从JNDI或ServiceManager{获得被调用者，q里cMServiceLocator模式?1. EJB/J2EE
2. AvalonQApache的一个复杂用不多的目Q?
W二U类?使用JavaBeans的setterҎ 1. Spring Framework,
2. WebWork/XWork
W三U类?在构造方法中实现依赖 1. PicoContainer,
2. HiveMind
有过EJB开发经验的人都知道Q每个EJB的调用都需要通过JNDIL到工厂性质的Home接口Q在我的教程EJB是什么章节中Q我也是从依赖和工厂模式角度来阐qEJB的用?/P>
在通常传统情况下，Z实现调用者和被调用者解耦，分离Q一般是通过工厂模式实现的，下面通过比较工厂模式和Ioc模式不同Q加q解Ioc模式?/P>
工厂模式和Ioc
假设有两个类B ?CQB作ؓ调用者，C是被调用者，在B代码中存在对C的调用：
public class B{
private C comp;
......
}
实现comp实例有两U途径Q单态工厂模式和Ioc?/P>
工厂模式实现如下Q?/P>
public class B{
private C comp;
private final static MyFactory myFactory = MyFactory.getInstance();
public B(){
this.comp = myFactory.createInstanceOfC();
}
public void someMethod(){
this.comp.sayHello();
}
......
}
特点Q?/P>
每次q行ӞMyFactory可根据配|文件XML中定义的C子类实现Q通过createInstanceOfC()生成C的具体实例?
使用Ioc依赖性注? Dependency Injection )实现Picocontainer如下QBcd同通常POJOc，如下Q?/P>
public class B{
private C comp;
public B(C comp){
this.comp = comp;
}
public void someMethod(){
this.comp.sayHello();
}
......
}
假设C接口/cL有一个具体实现CImpcR当客户端调用BӞ使用下列代码Q?/P>
public class client{
public static void main( String[] args ) {
DefaultPicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(CImp.class);
container.registerComponentImplementation(B.class);
B b = (B) container.getComponentInstance(B.class);
b.someMethod();
}
}
因此Q当客户端调用BӞ分别使用工厂模式和Ioc有不同的特点和区别：
主要区别体现在Bcȝ代码Q如果用IocQ在BcM码中不需要嵌入Q何工厂模式等的代码，因ؓq些工厂模式其实q是与C有些间接的联p，q样Q用Iocd解耦了B和C之间的联pR?/P>
使用Ioc带来的代hQ需要在客户端或其它某处q行B和C之间联系的组装?/P>
所以，Iocq没有消除B和C之间q样的联p，只是转移了这U联pR?BR> q种联系转移实际也是一U分d注，它的影响巨大Q它提供了AOP实现的可能?/P>
Ioc和AOP
AOP我们已经知道是一U面向切面的~程方式Q由于Ioc解放自由了Bc，而且可以向Bcd现注Ccd体实玎ͼ如果把BcL像成q行时的横向动作Q无疑注入Ccdcd是AOP中的一UAdviceQ如下图Q?/P>
通过下列代码说明如何使用Picocontainer实现AOPQ该例程主要实现是记录logger功能Q通过Picocontainer可以使用单一行，使所有的应用cȝ记录功能ȀzR?/P>
首先~制一个记录接口：
public interface Logging {
public void enableLogging(Log log);
}
有一个LogSwitcherc，主要用来Ȁzd体应用中的记录功能：
import org.apache.commons.logging.Log;
public class LogSwitcher
{
protected Log m_log;
public void enableLogging(Log log) {
m_log = log;
m_log.info("Logging Enabled");
}
}
一般的普通应用JavaBeans都可以承这个类Q假设PicoUserManager是一个用L理类Q代码如下：
public class PicoUserManager extends LogSwitcher
{
..... //用户理功能
}
public class PicoXXXX1Manager extends LogSwitcher
{
..... //业务功能
}
public class PicoXXXX2Manager extends LogSwitcher
{
..... //业务功能
}
注意LogSwitcher中Log实例是由外界赋予的，也就是说卛_被外界注进入，下面看看使用Picocontainer是如何注Log的具体实例的?/P>
DefaultPicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(PicoUserManager.class);
container.registerComponentImplementation(PicoXXXX1Manager.class);
container.registerComponentImplementation(PicoXXXX2Manager.class);
.....
Logging logging = (Logging) container.getComponentMulticaster();
logging.enableLogging(new SimpleLog("pico"));//Ȁzlog
׃代码可见Q通过使用单一行logging.enableLogging()Ҏ使所有的应用cȝ记录功能ȀzR这是不是类似AOP的advice实现Q?/P>
MQ用Ioc模式Q可以不将来具体实玎ͼ完全在一个抽象层ơ进行描q和技术架构，因此QIoc模式可以为容器、框架之cȝ软g实现提供了具体的实现手段Q属于架构技术中一U重要的模式应用?/P>
Web service已经不再是新婚的娘子。众多企业都已经创徏各种实验性Web Services 目Q事实证明，q项新兴的分布式计算技术确实能够降低集成和开发的成本。另外，一些关键的Web Services标准UL制定Q强安全Qrobust securityQ和理斚w的品也陆箋问世。对于志向远大的企业来说Q他们已l在考虑下一步了?/P>
对大多数公司来说Q下一步要考虑的不再是点对点的应用Q而是Web services在企业间以及业务伙伴间更为宽q的应用。这U技术的变迁需要更松散耦合、面向基于标准的服务的架构。这样一个架构要求对IT在组l中的角色有新的观点和认识，而不仅仅是一U实现方法。通过对业务的敏捷反应Q企业可以得到实实在在的回报Q而要辑ֈq一点，面向服务架构设计师的角色非常关键。除此之外，潜在的回报更是不可胜敎ͼ分布计算技术能够保证对业务需求够灵zȝ反应Q而这U业务上的敏h是各公司梦寐以求而目前还遥不可及的?/P>
分布式计将|络上分布的软g资源看作是各U服务。面向服务架构是一U不错的解决Ҏ。但q种架构不是什么新思想QCORBA和DCOM很cMQ但是，q些q去的面向服务架构都受到一些难题的困扰Q首先，它们是紧密耦合的，q就意味着如分布计连接的两端都必遵循同样API的约束。打比方_如果一个COM对象的代码有了更改，那么讉K该对象的代码也必M出相应更攏V其二，q些面向服务架构受到厂商的约束。Microsoft控制DCOM自不必说QCORBA也只是一个伪装的标准化努力，事实上，实现一个CORBA架构Q经帔R是在某个厂商对规范的实现上进行工作?/P>
Web services是在改进DCOM和CORBA~点上的努力。今天应用Web services的面向服务架构与q去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准Q如XML和SOAPQ提供了在各不同厂商解决Ҏ之间的交互性。而松散耦合分布计中的参与者隔d来，交互两边某一方的改动q不会媄响到另一斏V这两者的l合意味着公司可以实现某些Web services而不用对使用q些Web services的客L的知识有M了解。我们将q种Z标准的、松散耦合的面向服务的架构UCؓSOA?/P>
SOA的强大和灉|性将l企业带来巨大的好处。如果某l织其IT架构抽象出来Q将其功能以_粒度的服务形式表示出来Q每U服务都清晰地表C其业务价|那么Q这些服务的֮Q可能在公司内部Q也可能是公司的某个业务伙伴Q就可以得到q些服务Q而不必考虑其后台实现的具体技术。更q一步，如果֮能够发现q绑定可用的服务Q那么在q些服务背后的ITpȝ能够提供更大的灵zL?BR>但是Q要得到U强大和灉|性，需要有一U实现架构的新方法，q是一艰巨的d。企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOAQ还要理解SOA的实c在架构实践和最后得到的架构l果之间的区别非常微妙，也非常关键。本文将讨论SOA的实践，卻I面向架构的设计师在构建SOA时必要做的事情?/P>
SOA的原?/B>
SOA是一U企业架构，因此Q它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏h。业务敏h是指企业对变更快速和有效地进行响应、ƈ且利用变更来得到竞争优势的能力。对架构设计师来_创徏一个业务敏L架构意味着创徏q样一个IT架构Q它可以满当前q未知的业务需求?/P>
要满U业务敏h，SOA的实践必遵循以下原则：
* 业务驱动服务Q服务驱动技?/P>
从本质上_在抽象层ơ上Q服务位于业务和技术中间。面向服务的架构设计师一斚w必须理解在业务需求和可以提供的服务之间的动态关p，另一斚wQ同栯理解服务与提供这些服务的底层技术之间的关系?/P>
* 业务敏捷是基本的业务需?/P>
SOA考虑的是下一个抽象层ơ：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从gpȝ而上的整个架构都必须满业务敏捷的需求，因ؓQ在SOA中Q何的瓉都会影响到整个IT环境的灵zL?/P>
* 一个成功的SOAd变化之中
SOA工作的场景，更象是一个活的生物体Q而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会l束。对于习惯于盖房子的设计师来_要{向设计一个活的生物体要求崭新的思维方式。如下文所写的QSOA的基q是一些类似的架构准则?/P>
SOA基础
在IT行业有两个越来越普遍的发展方向，一个是架构斚w的，一个是Ҏ学方面的Q面向服务的架构设计师可以从中有所收获。第一个就是MDAQ模型驱动架构）Q由提出CORBA的OMG模型提出。MDA认ؓ架构设计师首先要对待创徏的系l有一个Ş式化的UMLQ也是由OMG提出Q的模型。MDA首先l出一个^台无关的模型来表C系l的功能需求和use casesQ根据系l搭建的q_Q架构设计师可以p个^台无关的模型得到q_相关的模型，q些q_相关模型_详细Q以至于可以用来直接生成需要的代码?/P>
MDA的核心就在于在设计阶D늳l就已经完全描述Q这P在创建系l的时候，几乎没有错误解释的可能Q模型也可以直接生成代码。但MDA有一些局限性：首先QMDA假设在创建模型之前，业务需求已l全部描qͼ而这一点，在当前典型的动态业务环境中几乎是不可能的。第二，MDA没有一个反馈机制。如果开发h员对模型有需要改动的地方Qƈ没有提供l他们这么一个途径?/P>
SOA的另一个基是敏h法（AMQ，其中非常有名的方法是极限~程QXPQ。象XPq样的AM提供了在需求未知或者多变的环境中创Y件系l的q程。XP要求在开发团队中要有一个用户代表，他帮助书写测试来指导开发h员的日常工作。开发团队中的所有成员都参与到设计之中，q且设计要尽量小q且非Ş式化。AM的目标是仅仅创徏用户惌的，而不是在一些Ş式化模型上耗费工作量。AM的核心思想在于其敏捷性－处理需求变更的敏捷性。AM的主要弱Ҏ其规模上的限Ӟ例如QXP在一个小团队和中型项目中效果不错Q但是当目规模增大Ӟ如果没有一个一致的清晰的计划，目成员很难把握目中的Ҏ面面?/P>
从表面看来，MDA和AMg是相对立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型Q而AM恰恰要避开它们。但是，我们q是军_冒险把这些不同方法中的一些元素提取出来，攑օC个一致的架构实践中?/P>
在SOA中有三个抽象层次Q按照SOA的第一条准则：业务驱动服务、服务驱动技术。AM业务模型直接和实践q接hQ表现在q_相关的模型之中。MDAq没有把业务模型和^台无x型分开来，而是把^台无x型做v炏VSOA必须q接q些模型Q或者说抽象层次Q得到单一的架构方法。我们将从五个视囄架构实现Ҏ来实现这个连接?/P>
SOA的五视图实现Ҏ
企业架构设计师发C们的职业非常有竞争力q且值得骄傲Q因Z们要从很多方面来通盘考虑ITpȝ。KruchtenQRUP的开发负责hQ将q些斚w提取出来Q在应用到SOAӞ我们UCؓ五视囑֮现方法（five-view approachQ?/P>
四个Ҏ表示对一个架构的不同审视ҎQ分别代表不同的涉众QstakeholderQ。弟五个视图Quse-case视图늛了其它视图，在架构中扮演的是一个特D的角色。部|视囑ְ软g映射到底层^台和相关g上，是系l部|h员对架构的视图；实现视图描述了Y件代码的l织Q是从开发h员角度出发的视图Q业务分析h员则利用q程视图q行工作Q它描述的是软gpȝ的运行时Ҏ。最后，逻辑视图表示的是用户的功能需求。在SOA中，面向服务的架构必能够以use-case视图中的用例用戯接到服务Q将服务q接到底层的技术?/P>
Z表示面向对象的架构是如何工作在这些视图之上，让我们将他们|于SOA元模型的上下文之中。SOA中两个领域存在重叠：׃务模型和服务模型表示的业务领域和由服务模型及q_相关模型表示的技术领域（两个领域׃n服务模型Q。业务用户通过逻辑视图和过E视囑֤理粗_度的业务服务，Ҏ变化的业务需求，按照需要将它们安排在过E之中。另一斚wQ技术专家的工作是创建ƈl护服务和地层技术之间的抽象层。表C些服务的中间模型Qv到的是u心的作用Q业务以它ؓ中心q行?/P>
SOA元模型从MDA中承^台无x型和q_相关模型Q但是添加了AM和用户交互以及敏L反馈q两部分Q后者通过椭圆之间的双向箭头来表现。类似地Q元模型通过引入׃心的服务模型提供的中间层抽象解决了AM在~性方面的问题。这P服务模型中的M需求的变化Q都会反映到用户每天的业务处理中。同P׃底层技术是模型驱动的，技术专家也可以Ҏq些变化的需求迅速而有效地作出应变?/P>
SOA实践和过去解决企业架构传l方式的不同之处在于其Ҏh的支持。如前所_SOA的第三条原则在于它d变化之中。这U恒在的变化性环境是SOA实践的基矟뀂如图所C，涉众QstakeholdersQ译者注QRUP中也有这个词Q表CY件开发中涉及到的各种角色如：用户、设计h员、开发h员乃x试h员等{。）在一个必需的基上媄响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的q种情况下，设计阶段和运行阶D之间的界限变得模糊hQ很难清晰地分离q两个阶Dc?/P>
剩下的部?/B>
我们已经为面向服务的架构提供了一个高层次的框Ӟ其中MDA和AM的元素帮助工L使用者来创徏和维护SOA。但是，SOA中还~少一些内容－那就是Y件开发商和专业的服务l织必需提供的。理x况下Q开发商必需提供面向服务的业务流E、工作流以及服务的协调工具和服务Q另外，能够以一U敏L、^台无关的方式充分反映业务服务的徏模工具也是必ȝQ技术专家必配备可以从模型中自动生成代码，q在代码变化时更新模型的工具Q最后，开发商必须提供支持SOA的YӞ帮助面向服务的架构设计师以一U可信ƈ且可伸羃的方式创Z于服务和底层技术之间的抽象层次。幸q的是，q方面的产品卛_上市?/P>
另外Q最重要的就是诏I本文的自顶而下的SOA实现Ҏ了。今天关于Web services的大部分思考都是自底而上的：“这是如何创建Web services的方法，现在Q我们来使用它们集成吧”，对Web services技术的q种Ҏ是伟大的W一步，因ؓ它可以惊人地降低集成的开销Q这是现在的技术管理h员最乐意见到的了。但当经进一步发展，IT走出低谷Q企业会LIT的帮助来提高l织战略意义上的核心价倹{用面向服务的架构QIT可以提供l企业实C务敏h的q样一个框架?/P>