保证松散耦合 EDA拓展SOA应用.docxVIP

PAGE 1 PAGE 1 保证松散耦合 EDA拓展SOA应用  企业倾向与频繁地转变架构。以服务为中心和全球化的发展会不断强化这种趋势。这个世界正在渐渐变成一个以业务架构为中心的网络，在这个网络上存在着独立的、自治的服务供应者和服务使用者。部分的业务流程也会被外包给外面的公司。  部门将会转变成服务供应者。这些服务供应者不再仅仅服务于组织内部，他们会寻求外面的市场来供应自己的服务。随需应变的业务正在成为潮流，而那时服务供应者将会对来自于环境中的刺激——事件做出反应。  要想在布满竞争的市场中胜出，高度的自治是必需的，它需要能够自由地选择合适的IT支撑系统。独立性的不断增长需要应用组件间松散地耦合，从而保证业务流程能够听从于不断转变的组织架构。  为了达到这种机敏性，支撑应用必需能够快速适应组织的转变，例如职责和角色的转变，外包或者内包，部门或者整个公司的分解，融合或者重组等等。  业务流程一定不能被IT系统限制，要紧紧地跟上着这些组织的变化。例如，部分流程要外包出去，相应地部分IT系统就可能被砍掉，剩下的IT系统就必需能够与外包公司通信。为了适应新的形势，IT系统的转变一定不能耗费太多的时间和金钱。  SOA，虚假的承诺  这些都需要应用组件之间松散地耦合，以便轻松地转变组织架构而不用去转变IT系统。但是SOA的本质是同步地命令掌握模式，这是一种应用组件间紧耦合的方式，它是无法满意这种伸缩性的。  SOA在技术领域内可能是松耦合的，它采用了标准的webservice。但是在功能领域，SOA做不到松耦合，因为它是与外部服务调用和数据冗余消退相互联系的。外包后，业务和数据的可用性将消逝，这可能会造成巨大的损失，而这些全都是因为SOA引起的。SOA的承诺是松耦合，但是在功能层次上，这可能是一个虚假的承诺。  IT弹性与组织弹性  毫无疑问，SOA的采用将会带来益处，它会缩减IT指出，并且加快部署。  但是同时SOA被定位于命令掌握模式的，在功能分解上，它采用粗粒度。为了在从前提到的组织转变环境中达到松耦合和自治，EDA在这个粒度层级上将会更加合适。EDA将会保证组织本身弹性，EDA将会帮助企业在不影响应用架构的基础上进行组织改组。在不转变应用的状况下转变组织的架构这是EDA的承诺。当然我们这里争论的机敏性是在一个完全不同的层次上的。  粒度  但是为什么SOA采用这样一个级别的粒度?有四个方面的原因。首先，大多数人都依据webservice来理解SOA。其次，当前的webservice不适合细粒度。第三、webservice起源于恳求应答模式，所以它与命令掌握方案紧密相连。第四、事件驱动模型还很少有人知道，而人们都喜欢在自己熟识的领域里来寻求解决方案。不幸地是，命令掌握模式不适合这种细粒度。建立在同步webservice上的SOA，对于中等层级粒度上的功能分解可能是个好办法，但是你也必需在设计前进行具体地调研。所以查找SOA适用的合适的粒度不是一个小问题。  何时采用SOA，何时采用EDA  同SOA相比，EDA供应了松散地耦合。EDA不是同步地命令掌握模式，恰恰相反，它是一个异步地发布订阅模式。发布者可能完全不知道订阅者是谁，组件被松散地组合在一起，它们之间仅仅地共享消息语义。  假如你期望实现业务流程的高聚合，全部的流程都处于统一的掌握之下，SOA会比较适合。SOA的命令掌握模式适用于如下状况：  ◆在功能分解的层级之间实现垂直的交互  ◆功能性的恳求答复流程，例如人机对话，用户会等待机器的响应。  ◆需要便利提交和回复的交易流程  假如你期望实现业务流程之间的独立性的化，EDA会适合你。这种架构风格特别适合联邦制和自治的流程环境。EDA适应如下一些应用：  ◆流程链上每个环节之间水平的交流。  ◆工作流;  ◆那些跨越组织边界的流程，需要内外的交互，如B2B。  找到那些你能保证会停留在同一组织体内部的业务流程，你将会发觉解耦的要点，它就是业务功能的边界。  在全部的粒度水平上实现松耦合是最抱负的，这样伸缩性和机敏性就能便利地实现。所以我们应当遵循如下规则：除了需要命令掌握模式以外，任何状况下都采用松耦合。不管是SOA还是EDA，在功能维度上这些都是适用的。当然，这些规则总是会受到性能方面的挑战，例如快速地应答。