Java电信行业应用探讨-01-提纲篇

电信行业的核心应用应该可以称为high-end级应用，原来BOSS这个领域被C/C++语言和C/S结构占领，现在也逐渐赶上潮流，新上的系统不少基于B/S和java/C#，但是用上open source产品的实在不多。

我的想法是按照open source的现有产品，加以适当扩充和组合，搞出一套适合大型电信系统的应用级framework，应该是一件比较有意义的事情。

我自己搞过几个百万级的电信系统，现在混入了甲方阵营，在电信和移动的业务需求上也算有点积累，提供出来都是实打实的case，搞出来的东东肯定不会build on sand，呵呵。

我的思路按照经典的“确定需求”-->“总体设计”-->“详细设计”-->“demo系统”来确定最后的产品， 每一个step都会有大量的问题需要探讨，因此我草拟了一个提纲，大家不妨先就提纲来探讨一下


Step A:界定系统边界,按照和系统做交互的对象分类，应该有如下几个对象的需求可供讨论：

1.系统创建者：项目管理部/构架部/开发经理/资深开发员/开发员
2.系统使用者：最终个人用户/最终集团用户/外部SP/代理商/系统操作员/系统管理员
3.系统维护者：报障受理人员/报障处理人员/系统监控人员/网络维护人员
4.内部业务执行类系统：交换机/智能网/短信网关/radius等等
5.内部维护类系统：网管、监控
6.内部支持类系统：客户服务系统、统一投诉中心、OA办公系统、KC知识库系统、WF工作流系统
7.外部业务执行类系统：SP服务系统、SP网站、统一增值系统、外省同类系统(漫游支持)
8.外部支持类系统：银行、超市等
9.系统需求总结

Step B:根据step A的成果，可以确定系统大致需求，这样就可以讨论总体设计方向问题，可能有如下关键实现模式需要探讨：

1.数据设计模式：PK/FK问题、如何处理超大表、如何保留历史记录、如何保留操作记录、如何解决周期生效
2.log处理方式：记录那些数据、存储方式、检索方式
3.enum存储方式：DB、xml、java代码
4.配置存储方式：DB、xml、jmx
5.其他：excption处理方式/国际化处理方式
6.逻辑层：DAO/MGR/SVR分层、cache代理、接口代理
7.接口：spring remote/soap/corba/db
8.展现层：
9.权限处理：sso/webfilter/MethodInvocation/Object filter
10.可管理：JMX/SNMP
11.容错：集群/动态切换/动态修改配置

Step C:若干关键实现思路确定后，可以根据step B的结果，根据系统应用方向选择几套open source的产品组合和优化方案，分别再讨论如何做整合。

Step D:按照step c的成功出一两个demo系统，这个时候重点就是实现和集成。

什么时候下一篇?

恩，很不错的设想
不过这个也太庞大了，等等看楼主能拿出什么方案

貌似很庞大的样子，对于能否实现俺表示98%的怀疑。不是on sand,但可能是 in air
应该可以划分为若干关联很少的部分，没必要仔细讨论每一块。
另外，这种瀑布式的开发方式，是不是可以改进下。

不过，仍然预祝你能够成功！

呵呵，偶的出发点不是搞一套全能的东东出来，而是想和大家探讨一下那些情况下有那些处理方式，最后各种处理方式的组合，就由开发者自己顶。就象大家可以选择hibernat+spring+stuts，也可以选择toplink+spring+jsf，都由各个项目具体情况而定。

电信级的情况比较复杂，所以case也是最多的，提供给大家探讨的素材也是最多的。

楼主继续啊，呵呵，人怎么不见了。
我也问个问题，Step A工作量是最大的，要讨论的话，是不是先站在一些前人的基础上？比如是不是先把NGOSS拉出来说话？
不过话说回来，如果一个全新开发的BOSS项目200人年，A起码70人年，B30人年。
咱们在论坛里好像很难讨论清楚吧

呵呵，第2篇就来了。

我的目标不是开发个boss出来，最多就是整合个框架出来，搭上一个demo，然后可以在各个项目里面用用。

open source变化太快，你刚把sping 1.1和hibernate2整合好，spring 1.2和hibernate3就出来了:(   所以结果不是最重要的。

最主要的想是通过这次讨论，我们也可以对整个open source开发过程和体系架构有个清楚的认识，对未来各种意外情况有一定的应对方案。

什么叫“电信级”，做电信的就很牛×吗？
我觉得做大项目先有一个平台比较好，然后再基于这个平台去开发，效率会高很多。

NGOSS 太超前了 先说说CTG-MBOSS吧

期待中