kadvin

对SOA的理解

kadvin — Thu, 15 Nov 2007 11:19:00 +0800

作者: kadvin 链接：http://kadvin.javaeye.com/blog/140814 发表时间: 2007年11月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

昨天与两个同事聊到SOA，由于大家都有在电信领域开发的背景，讨论中形成了对SOA较为准确和生动的理解，特写此文以记之。
现在SOA的话语权主要集中在IBM，BEA这样的大公司手里，在我看来，他们最擅于将简单问题复杂化，用时下流行的话说，叫做"忽悠"，愣是可以把一个简单的SOA，划分若干个看似NB的组成要素，再冠以SOAP, WSDL, UDDI, ESB等很神秘的词汇。

在电信网络中，同一种设备，一般由不同的厂家生成，同一个网络中，往往有多种设备，多个厂家提供，但运营商又需要对这些设备集中，统一的管理，这样的现状和需求，催生了一个重要的管理架构，这个架构名字很简单，叫做MA结构。

MA的原理也很简单，M就是Manager， A就是Agent，每个设备，除了需要实现自己的业务功能（如路由器的业务功能就是路由功能）以外，还要让自己能够融入到网络中，让上级的网管(Manager)能够管理，所以往往这样的设备，还需要附带一个Agent，这个Agent将本身的被管功能暴露给上级的网管。

展开一下，MA结构是可级联的，有些实体（软件或者设备），它作为下层实体的Manager，同时又是上层实体的被管实体，其自身又需要附带Agent，这些关系，有时候也用南向，北向接口指代，南向就是本实体和下层被管实体之间的接口，北向就是本实体和上层管理者之间的接口，MA就是站在这两种接口两侧的对象。

回过头来看现在的SOA，在我们看来，其本质就是软件产品的Agent，让软件像硬件那样具有互通性。

由于设备的标准化较高，定制化程度较低，所以，设备软件的模块化，集成化较高，相应的这些方法论也早于一般应用软件和业务系统。

从SOA宣称的各种功能和好处来讲，本质上要求上SOA的软件系统像设备一样开发，系统内部功能自行开发，系统要以标准、统一的接口与外部集成，WSDL的服务定义，与SNMP的MIB定义何其相似。在设备的开发中，SNMP等协议早已相对完善，其中所涵盖的内容，包括命名，建模，服务的定义和发现，通讯协议栈，和SOA的内容也差不多，只是用于不同的层面。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

对网管软件开发的一点感悟

kadvin — Thu, 15 Nov 2007 10:38:00 +0800

作者: kadvin 链接：http://kadvin.javaeye.com/blog/140790 发表时间: 2007年11月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

本文主要面向具有一定网管开发经验的读者。

本人在毕业后不长的工作时间里，大多数时间从事的都是电信网管软件的开发，期间经历了大小不同的公司，也有幸从头到尾做过一些大型的网管软件的开发，甚至还不自量力的要去做一些网管开发平台。

我个人的背景，主要是在EMS（网元管理层）网管的开发，对NMS层有一些接触，对设备的开发也有些接触，但都属于隔靴骚痒，看着别人爽，文中提到的方法和思路，虽然多为通用的，但具体的一些方法对于其他类型的软件未必适合。

传统的TMN里，EMS网管只是其中一小块，借用TMN的方法论，就EMS网管本身，用接口划分的方式，网管有如下三个大的接口：

G接口：为网管提供给操作运维人员的人机界面(MMI)，一般有基于BS技术的Web形态，基于CS技术的Java Swing, Delphi，基于命令行的CLI也是一种人机界面，这个G字可能需要再广义一点。

F接口：为网管内部接口，主要在网管的服务器和各类客户端之间的接口，网管一般采用集中部署的模式，网管服务器对设备一般充当了Manager的角色，它的客户端有多种形态，包括各种G接口的实现，甚至可以将网管与上级网管之间的北向接口也作为一种客户端，F接口就是这些客户端和服务器之间的接口。

Q接口：为网管和被管设备之间的接口，它是一种机机接口

G接口代表了网管的管理需求(Managing Requirements)，Q接口代表了网管的被管需求(Managed Requirements)，而F接口代表了网管的开发需求(Development Requirements)。

在我从事的很多网管项目的开发，由于团队中开发的角色较多，对网管的认识不足，产生了一些误区，概括的来讲，就是：
1、从F接口入手：因为在开发人员占主导，或者具有较深开发背景的占主导的团队中，大家往往最能想清楚的就是开发的这么点破事，所以，最容易先抓住F接口不放，设计各种模型，服务；

2、忽视Q接口：忽视Q接口的理由很多，有设备方面的问题，诸如设备没有定稿，设备不在自己掌握范围之内，设备接口不规范，总是能找到一大堆理由，但忽视了Q接口这一点很致命，一个网管，如果在开发过程的始终都没有搞清楚自己管的东西，如何成为一个"正确"的网管，如果连正确都做不到，这个产品或者项目就免谈成功了.

3、随意指定G接口：G接口的随意化，也是有多种原因
首先就是需求管理的不严格，不规范，国内现在很多软件公司，呆在家里三言两拍就可以为用户想好需求，随后设计界面和交互流程（就是G接口）；
其次也有现在项目团队组成过于复杂的原因，从用户到产品经理、系统工程师，设计人员、开发人员，各种测试人员，实施人员，一个原始的需求，经过若干个部门和流程上的环节，传导到真正开发这里的时候，已经是面目全非，时间也滞后了很多。

实际上，以上的三个接口有其各自的特点：
G接口：形态多样化，需求变化较快，虽然网管的界面需求变化赶不上业务系统的变化，但由于这个接口是面向具体的人，其需求的变化是最难以琢磨的，但各种界面元素、流程其中的可复用度又是非常之高。
F接口：实现技术多样(WebServcie, Java RMI, Corba...可以列举一大堆)，实现方式多样(各种设计模式都可以在这里一展身手)，弹性十足，高水平的网管和低水平的网管，其F接口的设计和实现很容易有云泥高下之分。
Q接口：相比较为稳定，无论从接口信息本身，还是从接口的实现技术(Snmp,TL1,Q3,Corba,各大厂商的私有协议...)，往往都比较稳定。

而我以上所提到的错误的网管开发思路，其主要错误就在于一开始抓住的是一个具有多种实现方案，不该被固化的F接口，而忽略了一个可以被“固化”的Q接口，随后而来对G接口的开发的错误也自然而然，甚至有一些更错误的方式是先定义G接口上各种界面，而后为每个界面定义一套F接口上的服务和模型，在我看来，这更像是一种过程式的开发思路。

写了这么多，好的方法在哪里？我个人认为，好的步骤是：
1、深挖Q接口，整理出其中的信息模型和接口、主要业务流程
2、详列G接口，将所有的界面都预先通过Screen Design(界面设计)，Interactive Process Design(交互流程设计)的方式列举出来，找出其中共用的界面组件、交互流程。
3、归纳F接口，F接口本质上是为G接口服务的，当G接口被详细列举之后，其中共用或者类似的组件，流程，所调用的F接口往往都是类似的，这些接口就是可归纳的，而不需要每个模块，每个对象都重新定义一套模型和服务。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

软件产品的四维立体分解法

kadvin — Fri, 02 Nov 2007 15:43:52 +0800

作者: kadvin 链接：http://kadvin.javaeye.com/blog/137591 发表时间: 2007年11月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

1、引言

最近为公司做一些架构方面的整理工作，记得以前给新人写过一篇PPT，关于软件的认识方法，其中对软件的划分方法值得借鉴，于是整理出本文。

2、一维软件划分

回想我刚开始做软件开发的时候，对软件的认识，停留简单的表面，收到客户的需求，分解成为几个模块，划分几个人手，吭哧吭哧上马干活，这个时候的对软件的认识，犹如小孩子对几何的认识，仅知道几个点连成一个线而已，姑且将这种认识层次，或者说采用这样的观点划分的软件，称之为：

3、二维软件划分

刚开始的时候，做了一些桌面型的应用Delphi(C++Builder)+Interbase，VB+Access，这种单纯而直接的应用开发岁月没持续多久，还没等我用上传说中最牛叉的Power Builder，CS，BS，三层，N层架构就接踵而至，作为可怜的开发人员，学完这个学那个，真实的需求根本没有，完全是技术驱动的学习。
在多层架构下，软件产品和开发角色的划分，也跟着进行了细分，大家往往将服务器、客户端开发人员分开，大的项目，甚至有单独DBA，此时的软件划分，已经不再是一维的，而是二维的：

4、三维软件划分

二维的软件划分，可以用于大多数项目的开发，对于小公司特别有效，但对于一些大的项目或者产品的开发，总显得那么捉襟见肘。
这是因为在大的团队，随着产品开发的时间累计，不断有避免重复（现在流行的叫做DRY），加强建设产品公用部分，节省人力的需求，这时候，往往会成立单独的平台组，系统组，将团队的核心知识固化在一些可复用的软件模块中，将这些软件模块包装成为平台，框架，构件等。
在这个时候，对软件的认识和划分，需要摆脱二维软件单纯的平面思想，进行三维立体的划分：

三维软件的划分方法，相比于二维，主要增加了一个逻辑轴，该轴的一般体现了软件的平台，框架，构件等思想；我个人一般将该维的层次划分为

外部Library
技术平台与框架
业务平台与框架
业务实现

相信不同的公司，不同的人对这块的划分都有不同的认识，但是，引入了第三维，软件变成一个立体的，可触摸的东西。

5、四维软件划分

三维的软件划分，是一个单纯的技术路线的划分，考虑到软件开发的实际情况，总觉得缺少点什么，对了！时间，就是时间。
时间在软件的开发中，毫无疑问是非常重要的，静态的看一个软件是不现实的，我们站在时间轴上去看软件，软件才是一个有生命力的，活生生的。
开发一个软件产品的时候，即便我们能够按照三维的思路将目标产品进行分解，或者对现有产品划分，但如果没有考虑到版本因素，这样的产品开发无疑是不具有可行性。
好的架构师，需要对产品的版本特征规划胸有成竹，对于产品的开发具有很好的节奏感，这就构成了软件的第四维。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐