五一长假，感谢庄老师的支持,我可以专心去准备SOA的比赛了。一个人在宿舍看东西也挺闷的，找个人聊聊才好。还好下午有些收获，且听一一道来。
在SOA中，使用旧有的OOAD，EA，BPM这些建模方法已经不足以囊括SOA所涉及的所有部分，而集以上建模方法其中优点从其中改进而来的SOAD(Service-Oriented Analysis and Design)就成了SOA建模的首选了。
如何确认并定义服务呢？
有顶至下的，商业层次的建模技术（如CBM等）可以作为SOA建模活动的开始。但是SOA的实施并不是从无到有的过程，创建一个SOA的解决方案是通过拆分现有的遗留系统成服务，操作，商业流程和商业规则并整合他们。
直接和间接的商业分析
BPM和通过对股东的谈话和CBM的直接商业分析是确定候选服务的合适的方法。
过往的经验表明需要间接的技术来补足这种方法。当挖掘候选服务时，必须与产品经理和其他商业经理谈话。比如，什么是计划中的支付模型？正在建立中的系统和所有已有的非SOA的案例都会作为建议分析。在建中的商业表示的术语是另一个操作候选分析的主要来源。
领域拆分
领域拆分，子系统分析，目的模型创建和相关技术是最先的商业架构方法或服务概念框架的方案。
服务粒度
选择合适层次的仇隙那个是服务建模的关键。应该将模型拆解到保证其完整性，一致性的越粗粒度越好。由于SOA不等同于Web service和SOAP不同的协议绑定可以用于在不同的抽象层次来访问服务。另一个选择是利用Façade 模式来将数个相关的服务绑定成粗粒度的服务定义。
命名约定
企业范围的命名规范（比如XML命名空间，Java包名，网络域）需要被确定。比如可以用服务的以一个名词和他的操作这个动词来命名。这个建议是来自OOAD的名字空间。
以下是结合了OOAD,BPM和EA的SOAD重要的概念：
Service categorization and aggregation 服务分类与聚合
服务有不同的用处和目的，SOAD中可以通过executable models（如BPEL）来简化其服务的组合。
Policies and aspects 策略与方面
在建模过程中服务是具有语法，语义和Qos特性的。正式的接口合约将不单单包括WSDL(Web Services Description Language)，还将包括Ws-Policy等等。同时还须定义些非技术的领域专家也可以理解的语言来描述系统的结构。
Process: meet-in-the-middle 流程:上下双管齐下
在处理真实世界的系统（包括遗留系统）用上下双管齐下的方法将会比单纯的自顶向下或者由下向上的方法更有优势。由下至上的方法会导致不良的商业服务抽象，使其设计更多是听从于现有系统，而不是去实现现有系统或者未来需要的需求。而有顶向下将会脱离现有的系统而产生不适合的需求。
Semantic brokering 语义代理
调用语法和语义是在接口定义中十分重要的。
Service harvesting and knowledge brokering 收集服务和知识代理
所有服务都是被定义用于重用的。所有服务的是被设计成超过1位用户所使用的。
这些将会是我们在以后设计所需注意的原则。
程启健
2006-05-07