本
SOA
步骤虽然可以说是一般性的
SOA
方案设计步骤,但特别作为
IBM SOA
大赛的参加者的参考文档。
注意开发过程是一个循环过程,而不是瀑布过程,
即下面的步骤会是循环进行的。
1.
设计思想
指出本项目的性质,和总的项目目标。
为完成目标采用的总体战略和设计思想,
比如基於架构的设计模式。包括设计方案的特点和创新点。
像本方案要应用
WEB Service
和
SOA
和
基於架构设计模式,
在现在研究需求细节前就可以确定。设计方案的特点和创新点可以回来再写。
对
SOA
和
Web Service
等大家皆知的技术不需要在方案里做一般介绍。
要强调的是
SOA
的什么优点在方案里面体现出来了。
任何方案设计不能不从需求开始,满足用户需求是最基本的,但设计方案不能由需求驱动。即所谓的基於需求的设计模式,根据需求细节来做方案。
要从需求分析中思考出战略。
用理论的话来说,就是注意不要落于基於需求设计模式,
用基於架构设计模式。
首先我们用基於架构设计模式,才谈得上
SOA
。
2
.需求分析。
2
.
1
抽象和概括用户需求。
注意是需求分析而不是简单的需求描述。
用户的需求描述可能是不完全的和不专业的。
要抽象和总结用户需求,用专业的语言重新描述。
让
用户的需求只是你将完成的方案的一些用户特例。比如说其中的一些需求可以抽象为是不同部门的员工能够实时的分享信息。我们要针对这个需求来作设计,这样以后具体需求有改变的话,比如要求分享的具体信息有变化,
但这个抽象需求是不会改变的,我们的架构也不用改变。这样的设计模式就叫基於架构的设计模式。
2
.
2
具体化用户需求
有时用户需求又可以是很抽象化的。比如
SOA
大赛的可视化的信息聚合需求。
这时就需要具体化用户需求
,
把可视化的信息聚合这样一个抽象的需求,
具体为聚合什么信息,
如何可视化,在什么模式下可视化,
这又可以与上节的需求结合起来。比如说统一在在
browser
界面下可视化,
等等。
3
.
组件和
组件界面分析。
对需求是整合现成系统的项目,特别要进行组件
component
分析,即已经有那些组件,为了整合又需要那些新组件
,
组件之间如何协作。
这里服务的概念要记住在脑里了。就是从功能上现有的组件能够提供那些服务,通过什么样的界面来提供的,而这些功能转化为统一规范的
Web
服务来提供有什么困难,需要怎么样的界面改造?组件之间的协作需要增加什么组件?这些都要在这节都要进行分析。
本题目已经有两个系统,
CRM
和
ERP
系统,
从题目我们不知道其内部结构,
因此我们把他们当做两个组件。
它们接口
interface
的细节也没有给出,但它们一定有接口。
我们可以认为它们的功能是通过传统的
CCI, client commuinication interface
而不是
web serivce
来提供的,
因此我们要加上
web serivce
的接口。
老师的课件里用了一个
EBA
的对
CCI
加上
web serivce
的接口的例图,在方案里做到这个地步就好。
题目要求我们对这两个组件进行整合,
将两个组件合成一个系统,
这就要增加组件,
要增加什么组件,
可以考虑我们自己设计一个企业信息化系统,包括
CRM
和
ERP
两个组件,需求里没有提到
CRM
和
ERP
的其他具体功能我们可以要有能兼容的准备就好,就是可以扩展的,而不用具体说明。其他的组件我们都要考虑兼容进去。
因为其他的组件我们是自己设计的,在这里虽然有很大的发挥空间,
但要围绕
CRM
和
ERP
这两个组件和组件整合的概念来进行,不要喧宾夺主。
工作流,
工作流是很重要的一个环节。如果在一般情况下。
我们应该是在需求分析之后就确定基本的工作流。
现在应该在什么地方确定可以考虑一下。但工作流应该是贯穿整个设计的一个核心思想。最后判别设计的一个标准,就是看
工作流是否优化。
4
.
抽象出服务
象抽象出对象一样,
抽象出服务是一项没有定律可循的工作。
这是需要对
Web Service
和
SOA
的深刻理解。跟对象一样,
在同一问题空间里对象的数目应该不多也不少。
服务作为新的技术,虽然没有明确定义,也应该遵循类似原则,让基本服务在运行时应该可以动态的组成新的服务。
抽象出服务同时要对对服务分类。
5
.
建立
SOA
架构
抽象好服务后,
建立
SOA
架构就是水到渠成。
建立层次架构的时候也要注意不同层次服务的相互调用规则。一般来说,
在采用类似
development View
的功能层次架构的层次的时候,上层的服务调用下层的服务。
下层的服务并不直接调用上层的服务
6
.
建立
SOA
技术支持架构
考虑来用什么技术架构来实现
SOA
架构。比如是否
IBM
的企业总线,
应该在这一节才确定。