从泰信的网管说起
sky
最可怕的缺少一个基本的对象模型，定义一个新的被管对象，居然还要自己去数据库里面设计原始表。这完全不是一个开发包的概念。
这个肯定不是WEBNMS的水平，也不是VERTEL的M*WARE的水平（话说这个M*WARE的前身我就和它打过长时间的交道，我认为
VERTEL的最终完蛋肯定也和VETEL收购TTG有一定的关系）。而且M*WARE的界面是BS构建的。但是要说WEBNMS是这个水平，那
WEBNMS早就完蛋了。
所以我的判断是这个是泰兴自己做的，但是设计这个的人肯定不是有很丰厚的EMS经验的人，他应该有很丰富的EMS的实施经验，但是不是EMS的结构
设计经验。从实施经验来做EMS，那就只能做成UNIT1,UNIT2,UNIT3...这样下去。结构都是从J2EE里面抄来的，尔不是基于EMS本
身来设计的。
不过认清EMS也是很麻烦的一件事情，说起来简单，做起来不容易。
再次YY一下，如果CORBA真正做到了NE上面，而且稳定效率能得到保证，那么也许EMS也就立刻变成一件超级简单的事情了。
techabc
sky
做好。
CORBA做到了下面，就超脱了协议的束缚。从管理的语义上讲表达就太丰富了。只要想想NMS是怎么管EMS的就知道了。NMS提出IDL接口，
EMS去实现。你去管理一个设备，就象管理一个本地对象一样，不用管NE再哪里，也不用管网络传输的细节，只需要调用这个对象自身定义的方法就OK。
CORBA完蛋的主要原因还是因为只有技术规范尔没有一个强势到能统一的CORBA产品。OMG自己不能做一个这样的东西出来，这样分散到各个厂
商里面做出来的东西都不够强势，想要实现无缝互通又是很困难的。一个CORBA产品，FOR JAVA一个版本，FOR C++一个版本
(WINDOWS里面VC,BC都是不同）。所以自然就玩玩了。J2EE能这么流行重要的原因就是基本库由SUN控制，虽然问题多，但是有统一标准，所
以好推广。
On Aug 4, 10:11 am, techabc <tech...@gmail.com> wrote:
> 1. 中小厂商的EMS，目前恐怕是基于自己搭建的平台多一些吧，设备复杂性不是很大；2. 最后一句"
> 如果CORBA真正做到了NE上面，而且稳定效率能得到保证，那么也许EMS也就立刻变成一件超级简单的事情了"，怎么个简单法儿呢？
>
> 2009/8/3 sky <shuhail...@gmail.com>
>
>
>
> > 全部是是JAVA做的，对于网管这样的产品，后台全部用JAVA效率总归是不高的，运行起来就会比较慢。
> > 最可怕的缺少一个基本的对象模型，定义一个新的被管对象，居然还要自己去数据库里面设计原始表。这完全不是一个开发包的概念。
> > 这个肯定不是WEBNMS的水平，也不是VERTEL的M*WARE的水平（话说这个M*WARE的前身我就和它打过长时间的交道，我认为
> > VERTEL的最终完蛋肯定也和VETEL收购TTG有一定的关系）。而且M*WARE的界面是BS构建的。但是要说WEBNMS是这个水平，那
> > WEBNMS早就完蛋了。
> > 所以我的判断是这个是泰兴自己做的，但是设计这个的人肯定不是有很丰厚的EMS经验的人，他应该有很丰富的EMS的实施经验，但是不是EMS的结构
> > 设计经验。从实施经验来做EMS，那就只能做成UNIT1,UNIT2,UNIT3...这样下去。结构都是从J2EE里面抄来的，尔不是基于EMS本
> > 身来设计的。
> > 不过认清EMS也是很麻烦的一件事情，说起来简单，做起来不容易。
>
> > 再次YY一下，如果CORBA真正做到了NE上面，而且稳定效率能得到保证，那么也许EMS也就立刻变成一件超级简单的事情了。- Hide quoted text -
>
> - Show quoted text -
sky
如果你的定位是一个EMS开发包，那么就是一个开发平台了，平台帮你完成很多抽象。你只需要在平台上专注于具体设备管理的业务逻辑的开发。
On Aug 4, 10:11 am, techabc <tech...@gmail.com> wrote:
> 1. 中小厂商的EMS，目前恐怕是基于自己搭建的平台多一些吧，设备复杂性不是很大；2. 最后一句"
> 如果CORBA真正做到了NE上面，而且稳定效率能得到保证，那么也许EMS也就立刻变成一件超级简单的事情了"，怎么个简单法儿呢？
>
> 2009/8/3 sky <shuhail...@gmail.com>
>
>
>
> > 全部是是JAVA做的，对于网管这样的产品，后台全部用JAVA效率总归是不高的，运行起来就会比较慢。
> > 最可怕的缺少一个基本的对象模型，定义一个新的被管对象，居然还要自己去数据库里面设计原始表。这完全不是一个开发包的概念。
> > 这个肯定不是WEBNMS的水平，也不是VERTEL的M*WARE的水平（话说这个M*WARE的前身我就和它打过长时间的交道，我认为
> > VERTEL的最终完蛋肯定也和VETEL收购TTG有一定的关系）。而且M*WARE的界面是BS构建的。但是要说WEBNMS是这个水平，那
> > WEBNMS早就完蛋了。
> > 所以我的判断是这个是泰兴自己做的，但是设计这个的人肯定不是有很丰厚的EMS经验的人，他应该有很丰富的EMS的实施经验，但是不是EMS的结构
> > 设计经验。从实施经验来做EMS，那就只能做成UNIT1,UNIT2,UNIT3...这样下去。结构都是从J2EE里面抄来的，尔不是基于EMS本
> > 身来设计的。
> > 不过认清EMS也是很麻烦的一件事情，说起来简单，做起来不容易。
>
techabc
Hailong Shu
techabc
Hailong Shu
钱不够
Hailong Shu
techabc
sky
至于JAVA做客户端我倒认为是一个好的选择，毕竟网管的主流运行操作系统是UNIX，客户端主要是要有强的表现力。无论是APPLICATION模式
还是BS模式的界面在开发成本和代码维护方面都有着很好的表现。
C++的特点就是运行效率高，但是开发效率对于开发人员要求比较高。而且稳定性和内存管理方面始终是需要小心谨慎的。我的机器平时都是不关的，长期跑
EMS的后台程序，顺便测试稳定性。
以前跑VC6的是很就发现它的STL的STRING居然是用的COPY ON WRITE技术，搞的系统跑个十几天就莫名其妙死一次。最后换了SGI的
STL才算搞定。这只是一个小例子。但是一旦一个平台做稳定后，只是做具体业务逻辑的开发就有了一个很好的基础，而且效率方面非常高。最后做以太网30
秒的性能，很大的数据采集量，多个任务开起来是JAVA无论如何做不到的。毕竟EMS在错误处理方面是实时要求，运行效率是总要考虑的一个问题。
On 8月5日, 下午3时25分, techabc <tech...@gmail.com> wrote:
> 不管是什么原因，各设备厂商开发EMS时不采用开发包而是自己另起炉灶，应该说是个浪费，而且为运营商综合网管的建设造成了整合困难。网管本来是为了节省运维成-本，但不能不说，目前情况却事与愿违。
> 关于语言，对于客户端，个人感到有些奇怪的是，java也称得上主流，而且，第三方专业组件提供商也是基于java的解决方案，如TWaver、jtgo等，其-他语言如C++等却罕见。
>
> 2009/8/5 Hailong Shu <shuhail...@gmail.com>
>
>
>
> > 网管的稳定性要求很高，C++的后台要做稳定不容易。就我知道的，华为中兴烽火的网管都是C++做的后台，这也是一个历史积累的过程。
> > 就我自己接触的JAVA的还是慢了，大概再过个几年速度就不是问题了。
>
> > 开发包是有的，很贵。国内用的少,大的厂商都是自己做的。或者WEBNMS，或者NAKINA都是做EMS的开发包。这类开发包一般是给中小型的设备提供商用。
> > 我接触的的第一个EMS开发包超级贵，多少钱就不说了，反正是天文数字，当是在2000年的网络潮的背景下钱不是钱。
>
> > 大家有兴趣，可以慢慢聊聊这个话题。
>
> > 2009/8/5 钱不够 <sjd...@gmail.com>
>
> > 我想厂商用java的目的是开发周期快，维护成本低。 我了解好多大厂商的ems也在由c++向java，由多线程到多进程的转变。开发包还是第一次听说。
>
> >> 2009/8/4 Hailong Shu <shuhail...@gmail.com>
>
> >>> 从进程上看就可以看出很多模块的划分。消息分发是驱动，到了独立的模块还是有很多事情的。
> >>> 一般来说，多进程是因为代码不稳定。
>
> >>> 烽火的网管就是很多进程一起工作，专门有一个进程就是不停的检查哪个进程死了，一死立刻重启。C++做后台就是有这样的问题，一般来说，网管一年的DOWN机时-机是有严格规定的，要把程序做稳定就很不容易。这也是为啥很多人用JAVA做的原因，但是就目前的情况，我觉得JAVA的后台还是太慢了，效率还是不太能接受。-好处也很明显，UNIX的问题一把解决，数据库也不用想了，就JDBC了，虽然效率很低。
>
> >>> 2009/8/4 techabc <tech...@gmail.com>
>
> >>>> 据http://blog.csdn.net/stephenxu111分析的华为的T2000系统采用的就是这样的平台iMap，其中心结构是消息分发中心mdp。华为的quidview好像不是基于此平台的。
>
> >>>> 2009/8/4 Hailong Shu <shuhail...@gmail.com>
>
> >>>> 呵呵，所以说CORBA一节我说明是YY，这个部分大约10年前还是很被关注的。但是总体来说，种种原因最后的选择还是SNMP。
> >>>>> 很多厂商做东西的时候，标准SNMP是一套，自己的私有协议又是一套。
>
> >>>>> 泰信的定位是提供EMS开发包的厂商，从它这里说起的意思就是我觉得他的这个包不是一个开发包，而是拿到客户的MIB后自己做出来的一个东西。 国内的情况是几家独大，各自做各自的EMS，对开发包这类东西接触的少。我做EMS一开始就是接触的一个开发平台，然后在平台上做东西。所以后来自己从头做EM-S的时候也是按照开发平台设计，然后在平台上在做开发的思路做的。中兴华为烽火应该都是这样的平台开发，接入网管，传输网管都是不同的组开发，但是共是共一个平-台。平台起码是屏蔽了OR映射，网络传输，管理命令解析，任务调度，还有内存管理之类。
>
> >>>>> 2009/8/4 techabc <tech...@gmail.com>
>
> >>>>>> 说起来还是snmp协议的孱弱所致。
> >>>>>> 我了解到的一些情况是，就接入网来讲，设备厂商的EMS确实多出于市场需要，因为运营商出于成本及对客户响应速度的需求，需要对在网设备进行监控，而snmp本-身就是私有mib，且mib内容也是天马行空，NE与EMS分工也都是厂商自己说了算。EMS与设备关系密切，没有统一的规范，自然很难做到管理不同厂家的设备-。虽然有对于NMS的北向接口，如TMF814等，但在现实对接中，也还是需要各自进行二次开发和调测。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
techabc
sky
但是对于接入网业务就不合适了。
待会单开一贴慢慢从简单的开始讲起，呵呵。