??xml version="1.0" encoding="utf-8" standalone="yes"?> 很多人对SOA的理解就是分层、模块化、面向对象。。。这U理解对不对后面再说。先看一些问题:(x) 我今天看了一个开发团队的开发工E包l构Q部分类的命名及(qing)l织产生了如下印象:(x) q也是我们U的SOApȝQ!Q!q最基本的模型设计、模块设计、分层设计都没做好,难怪年q重构、年q完成不可能完成的Q务!Q!我确信这U重构、这U不可能完成的Q务还?x)年q持l下去!Q! I竟什么是W合SOA风格的系l?先看看SOA宗师IBM的一文章:(x) http://www.ibm.com/developerworks/cn/architecture/ar-soastyle/ 我来ȝ一下?/p> SOA能达C么目的:(x) 1.实现业务与IT的一致性; 2. 创徏更灵zȝ反应更敏L(fng)IT基础设施Q?/p> 3. 化集成实玎ͼ SOA要怎么做? 别再说你的应用程序或烟囱遵@SOA的架构风|
]]>
如何解决上文提到的鉴定标准中的问题呢Q我认ؓ(f){案是MDD?/p>
用一个实际的例子来表qC下思\Q?/p>
在CRMpȝ有个订单处理模块Q其提供了订单管理、订单流E执行、工单管理等功能Q营业员通过界面提交一个订单请求,如果订单h通过业务规则的校验,则会(x)创徏一个订单对象,订单对象的创Z(x)触发订单程的创建,订单程{的过E中Q会(x)在各个节点创建工单,也会(x)调用其它子系l开通服务,比如调用物流发货。订单流E完成后Q订单对象的状态也完成。实际的pȝ比这个要复杂Q这里仅仅ؓ(f)了阐q思\Q做适当的简化?/p>
从上面的例子Q我们可以识别出几个模型:订单、工单、订单流E,订单、工单、订单流E都是stateful的、其state的变更会(x)D其它对象的状态变更或者服务的执行?/p>
在展现层Q展现各个模型是有章法的Q比如创单的界面L一L(fng)Q处理工单的界面也L一L(fng)Q展现订单的界面也L一L(fng)。因此,我们可针Ҏ(gu)定的对象的某U需要展现的状态,提供合适的展示构gQWEB TAGQ来展示它?/p>
在持久层Q因为对象L持久化到一张表当中的,因此Q可用一些ORM的框架来持久化对象,而不是开发h员针Ҏ(gu)个场景去写SQLQ复杂的兌查询可以使用cHQL?/p>
各对象之间的兌操作通过事g驱动?/p>
举一个订单创建的例子Q?/p>
1、开发做的工作:(x)
1Q用元数据定义订单的数据结构,包含持久化元数据、基本属性元数据、字典元数据Q?/p>
2Q定义订单状态机Q以?qing)状态变q的规则Q?/p>
3Q徏模订单处理流E;
4Q定义订单请求处理规则流Qƈ发布Z个受理订单请求的服务Q?/p>
5Q开发订单创建界面,使用订单WEB构g来展C单对象;
6Q定义事Ӟ以及(qing)事g的监听服务;
2、系l执行流E:(x)
1Q营业员打开订单创徏界面Q系l获取订单对象的元数据,生成订单创徏面Q?/p>
2Q营业员点击订单创徏界面的提交按钮,调用受理订单h的服务;规则执行,如果规则校验错误Q则q回错误Q如果成功,则创单,q回成功Q?/p>
3Q因创徏订单Q导致订单的状态变为创建状态,触发订单创徏事gQ?/p>
4Q订单创建的监听服务程服务接收CӞ触发订单处理程的创建;
5Q流E执行的q程中编排第三方pȝ服务Q流E执行结束后Q触发订单流E结束事Ӟ程l束事g的监听服务订单管理接收到事gQ触发状态机变迁Q订单状态变为完成?/p>
上述开发做的工作全部可通过配置完成。后l如果增删字D,修改元数据即可,要增删改业务规则Q调整业务规则即可,要调整实体状态,修改实体状态机卛_?/p>
业务q_要致力于对状态机、业务流E、SEP、元数据、领域化的WEB构g的实玎ͼq将其有机整合?/p>
写的比较乱,q几天再整理一下。。?/p>
如同变化多端的八卦卦象是由乾、兑、离{?个基本卦象组成,万事万物是由数种原子构成QŞ态各异的高楼大厦是由砖头和砂砌成,应用也有构成其的“元”,x件?/p>
业务应用是分层的Q典型的分层是展现层、流E层、服务层、数据持久层Q每一层次的关注点都不同,构g也不相同Q比如一个业务逻辑层的构g输出的数据,?x)通过展现层的构g来展现在界面上。且各层之间的诏通黏合(如MVC中的Controller层就是黏合逻辑Q,通常要耗费比较多的开发精力,一个好的业务^収ͼ除了在各层次分别提供可复用的构gQ需要能够减各层黏合的工作量?/p>
面向特定领域的业务^台的易用度与光用面是鱼和熊掌的关p,针对特定领域Q要易用,则^台能力就要越面向特定领域Q则不通用Q导致适用面越H。因此,一个好的^収ͼ要注意分层,比如分成通用的构件和领域化的构g。业务用户可按需使用。同Ӟq需要在各层ơ开攑֮制能力,供业务用户在各层提供领域构g?/p>
现在的品交付都是解x案的交付,解决Ҏ(gu)由多个系l或子系l构成,一个部门,一个项目组通常只是提供解决Ҏ(gu)中的一个部Ӟ负责端到端的业务功能中的一个环境,因此Q需要支持构件的l装Q以形成更大_度的构Ӟ支撑软g复用与集成?/p>
开发一个子pȝ_度的构仉常是一件很复杂的事情,如CRMQ需求琐、变化频J、不同客戯求不相同,如果~Z一个好的支撑^収ͼ人力成本?x)很高,TTM也会(x)很长Q因此,一个好的业务^収ͼ也需要能够支撑快速的构g开发、定制?/p>
解决构g的组装和集成Q已l有比较成熟的技术了Q如ESB、SCA{,IBM、Oracle{大厂商都有提供集成化的开发环境和执行环境。但如何支撑构g的开发这块,各大厂商也有支撑Q比如在展现层,Oracle有ADFQ在程层,IBM和Oracle都提供了BPMQ在service层,IBM和Oracle提供了规则引擎,VMWare的SpringQ在持久层,Oracle提供了ToplinkQ还有就JBOSS大名鼎鼎的Hibernate。所有前面提到的q些都是业务无关的技术部Ӟ且各层之间的靠业务开发h员自己来黏合Q还是不够领域化。因此,一个业务^収ͼ仅仅去重复制造IBM、Oracle造过的轮子,是完全没有竞争力的(q里不算成本Q。面向特定领域,评判一个业务^台是否优U的标准是Q?/p>
1、是否提供了丰富的领域构Ӟ
2、是否能够节省业务开发h员黏合各层的工作量?
3、提供了什么样的机制来应对需求变化?比如有的客户要求多加个字Dc(din)加个校验,有的客户要求个字段、少个校验等{?/p>
待箋。。?/p>
接下来的推导分ؓ(f)两个阶段Q第一阶段先推导支撑技术,W二阶段再推g什么样的开发方式将q些支撑技术串hQ达到快速开发的目的?/span>
下表中列Z对上面的核心l成要素Q数?/span>+服务Q的一些支撑技术:(x)
要素 |
支撑技?/span> |
考虑 |
数据实体 |
JavaQ?/span>sdoQ?/span>c++{等 |
|
原子服务 |
JavaQ?/span>c++Q?/span>cQ脚本等{?/span> |
没什么可说的Q码肯定是要~的 |
聚合服务 |
SCA |
?/span>sca来将原子服务装配成聚合服务。如果想要用什么数据{换啊Q接口映啊Q安全控制啊之类的特性的话也可以引进ESBQ作?/span>SCA的一U?/span>container?/span> |
操作程 |
实现一?/span>SCA中的containerQ接受操作流E的描述文g的作为执行文?/span> |
|
View process |
?/span>web应用下,采用一U?/span>webflow的实玎ͼswing下就自己写把?/span> |
|
Business process |
WFAcLE,EOS or OBEcM的工作流引擎Q可直接?/span>EOS或?/span>OBE提供?/span>API作ؓ(f)一个原子组?/span> |
|
Orchestration Process |
EAIcLE,?/span>ODEQ一?/span>bpel引擎Q也作ؓ(f)SCA的一?/span>containerQ?/span>BPEL作ؓ(f)一U组件实现方?/span> |
下面在列一些辅助支撑技术,q些技术是Z让企业应用这些大厦能够构建的更快Q毕竟盖房子Q有了水泥和砖是不够的,q要有扁担,箕{等?/span>
技?/span> |
作用 |
元数据技?/span> |
利用元数据描q数据实体,以及(qing)Ҏ(gu)据实体、实体属性的U束、权限等信息Q可以基?/span>RBAC的权限系l设计思\Q将用户l织机构与权限关联v来,实现自动生成面Ӟ对特定用L(fng)权限控制Q等{其它的东东?/span> |
表单生成技?/span> |
Ҏ(gu)元数据生成表单,支持可视化的定制表单布局{,支持生成jsp{,如果需要多U展玎ͼ可以生成多种特定的展现实玎ͼ?/span>swing界面{?/span> |
囑Ş化徏模技?/span> |
可视化的建模view processQ?/span>Orchestration processQ?/span>business processQ?/span>operation process{?/span> |
囑Ş化组件装配技?/span> |
可视化的组件装配成大粒度组件等 |
代码生成技?/span> |
Ҏ(gu)元数据生成数据实体?/span>DAO代码{?/span> |