1 背景

      伴随着国内外通信运营业竞争的日益激烈，移动通信运营商必需向用户提供更多、更方便的服务，而作为移动增值业务的主要提供者——移动智能网正在扮演着越来越重要的角色。随着移动智能网业务的不断发展，各种业务用户数量的不断增加，智能网系统与其他移动运营系统，如移动梦网、短信中心、特别是BOSS（Business & Operation Support System，业务运营支撑系统）之间多种方式、多种业务的交互的需求已日益增多；并随着用户数量的饱和和用户的素质不断提高，各运营商必须提供个性化、更方便快捷的服务方式。在此前提下，对移动智能网业务管理方式提出了更高的要求。

2. 已有系统模式

2.1 SMP＋SMAP方式

                                                                                     图1 业务管理方式一

      如图1所示，移动智能网基本功能由SMP和SMAP实现，一般把二者合称为业务管理系统（SMS）。其中，SMP提供SMAP接入移动智能网的接口，SMAP向最终用户提供接入SMP的界面和接口，达到管理整个移动智能网的目的。

2.2 SC接口方式

      SC（Service Center）接口又称为BOSS系统与移动智能网之间的接口，为了满足智能网系统与BOSS系统之间的交互需求中国移动对BOSS系统与智能网SMP系统制定了统一接口规范。

                                                                                     图2 业务管理方式二

      如图2所示，通过SC接口BOSS系统可以访问智能网的数据，对用户数据和业务数据进行管理，同时也可以使智能网系统访问BOSS上的数据，达到数据互访的目的。

2.3 WWW接入方式

      随着Internet和电子商务的不断发展，为了提高移动业务的竞争力，移动智能网系统通过Internet向智能网业务用户提供自主的管理用户数据的功能。

                                                                                       图3 业务管理方式三

      如图3所示，在智能网外围架构Web/Wap服务器来和外部系统、个人用户进行交互。

2.4 三种管理方式的比较及新架构模式的引入

      上述现存的三种业务管理主要存在以下缺陷：

1.SMP＋SMAP方式

      一个胖客户端，表示逻辑和业务逻辑在一块，维护和升级复杂。

      通过内部命令接入SMP，由SMP进行数据的操作，增加了SMP的负担。

      很大部分的业务逻辑与SC接口部分重复，业务逻辑和资源没有得到充分利用，且SMAP和SC接口各自维护自己的业务逻辑，增加了维护费用。

2.SC接口方式

      现有系统主要运行在UNIX系统下，主要由C/C++编写，系统的可移植性差。

      业务管理逻辑模块颗粒度过大，不适合扩展和组装。且与支撑模块耦合度过大，不利于新逻辑的添加和系统的升级。

支撑模块主要是C/S结构，随着新业务的不断增加，系统复杂性不断增加，维护复杂。

      多个系统（www接入系统、BOSS系统等）依赖SC接口的处理能力，随着业务量的增大，SC接口可能成为整个系统的瓶颈。

3.WWW接入方式

      业务逻辑与表示逻辑耦合紧密，不利于系统的维护和扩展。

      引入专门的接入代理实体来实现与SC接口的通信、过负荷控制、安全控制，增加了系统的维护费用。

      受限于SCP、SMP系统的处理能力和负载情况，增加了系统设计的难度。

      现存的业务管理方式对智能网其他实体依赖过大，并且相当于对同一套智能网系统提供了三种管理方法，不利于维护；随着业务量的增多可能会对SCP、SMP有很大的影响，进而受到SCP、SMP系统性能的限制；同时需要显式地维护各个功能实体间的通信协议，增加了整个系统的复杂性而降低了可维护性。

      因此解决上述缺陷，需要有一种相对综合的架构解决方案。

      J2EE（Java 2 Platform Enterprise Edition） 架构具有与之相应的优势。我们要将所有的功能部分逐一部署到J2EE 架构中,并检验新的系统能否满足功能和性能要求。最为重要的是, 我们要检验在传统模式下的问题是否得到了解决，进而体现出采用J2EE 架构的优势。

3基于J2EE的业务管理系统

3.1 J2EE 技术简介

      J2EE是一种技术规范，它给开发人员提供了一种工作平台，该平台提供了多层的分布式应用模型、组件重用策略、一致化的安全模型及灵活的事务控制，并将Java的企业级API捆绑在一起，成为用Java语言进行服务器端的企业级应用部署的开发环境。

      J2EE的提出基于以下基本思想：基于标准协议、共享公共服务、软件组件化。

      标准协议：J2EE的通信机制建立在标准协议的基础上，这些协议有因特网协议（HTTP、TCP/IP、SSL）和远程对象协议（RMI/RMI-IIOP、JavaIDL）

      共享公共服务或统一的API：JAXP、JMS、JDBC、JAAS、JTA、JavaMail API、JCA、RMI over IIOP、JNDI

      组件模型：Applet、JSP、Servlet、EJB

      从J2EE的基本思想可以看出，J2EE独立平台的解决方案不与任何特定厂商的产品、协议和API绑定。相反，所有的J2EE兼容产品必须提供企业级应用所必须的一些基础性服务（如组件的生命周期管理等），实现相同的API，这就可以使应用开发者的注意力集中在封装商业逻辑和商业规则上，一切与基础结构服务相关的问题以及低层分配问题都由应用程序容器或者服务器来处理。结果是J2EE应用程序开发者可以集中考虑应用程序的逻辑和相关服务，而把所有的基础结构相关的服务交由运行环境实现。

      本文的目的不是介绍J2EE，下面我们主要讨论J2EE架构下的业务管理系统的设计和实现。

3.2 典型的J2EE架构

      典型的J2EE架构是一个四层的架构模型，如图4所示：

                                                                             图4 J2EE架构下的系统体系结构

      这四层架构模型是：企业信息系统（EIS，Enterprise Information System）层，存储企业数据；业务逻辑层，实现系统的业务逻辑；表示层，实现Web界面部署、Web界面逻辑；客户端层，提供基于浏览器的瘦客户端或应用程序客户端，是用户交互界面。

3.3 J2EE架构方案

      从理论上讲J2EE已完成了系统框架的大部分功能,对于新系统的可扩展性来说,它应该能够给予一个基本的保证。图5给出了J2EE架构下的系统解决方案。

                                                                          图5 J2EE架构下的业务管理平台

      对照现存系统的划分，对新系统做如下分析（打√的为我们需要实现或需要移植的部分）：

• √原来的业务逻辑部分用EJB编程模型直接实现，以组件的形式部署到应用服务器上。

• √业务代理相当于原来的SC接口中的支撑模块，以支持应用服务同外部实体（BOSS系统、SCP、SMP、IP等）之间的通信，该部分主要完成协议的分析、转换，同时对应用服务器上的业务逻辑进行调用。考虑到外部实体主要通过socket与业务管理系统进行通信，所以业务代理主要由传统的Java技术实现，通过socket连接和相应的通信协议完成与外部实体间的交互。

• □底层通信链路维护和管理、事务管理、安全性等由应用服务器和业务代理配合完成。

• √原来的业务逻辑部分用EJB编程模型直接实现，以组件的形式部署到应用服务器上(部分业务逻辑与SC接口部分重复，可以只开发一次)。

• √把原来的SMAP用户界面部分单独抽取出来，以Java Application的形式实现，并通过EJB远程接口暴露的商业方法来调用应用服务器上的业务逻辑。

• □底层通信链路维护和管理、事务管理、安全性等由应用服务器完成。

• √把原来的表示逻辑可以直接移植到新系统中。

• √原来的处理逻辑大大简化，只需要按照J2EE的编程模型，类似以本地方法调用的方式调用EJB远程接口暴露的商业方法。

• □底层通信链路维护和管理、事务管理、安全性等由应用服务器和Web服务器完成。

3.4 J2EE架构下的组网方案

      组网方案图如图6所示：

                                                                                           图6 组网方案图

      该方案只是一个举例方案，实际中可以把应用服务器和Web服务器放到一个物理节点，同时也可以考虑把业务代理放到该节点上这样可以减少服务器的数量。新的业务管理系统可以根据管理的业务用户的规模的不同，其可能的组网方式可能很多，系统伸缩性较大。

      作为一种业务管理系统的统一的解决方案，新的解决方案把业务管理系统从智能网其他实体中独立出来，不依赖任何其他的智能网实体，而是作为一个单独的实体存在，并对外提供统一的接口和服务。

4 结束语

      新系统主要的技术优势有如下几点：

• 1.服务器架构：

        应用服务器提供了大部分的基础性服务（如：事务管理、EJB组件的生命期管理、并发处理、资源访问、安全等），减少了维护的复杂度，这使我们可以专注于业务逻辑的开发，而不必维护复杂的通信模块和支撑模块，开发新业务的周期大大缩短。

• 2.分布式体系架构：

        客户端的调用逻辑大大简化，一个业务命令的调用就象调用一个本地方法一样，而不必理会通信层的维护等（如socket的建立、连接的维护等），加快了对新业务的反应速度。

        通过EJB编程模型，可以使我们快速提供新的业务。一个新业务的提供只需要完成相应业务逻辑和客户端调用逻辑的编写即可。同时把现有业务移植到新系统中也是比较容易的。

        采用EJB可以使开发商业应用系统变得相对容易，应用系统可以在一个支持EJB的环境中开发，开发完之后部署在其他的环境中，随着需求的改变，应用系统可以不加修改地迁移到其他功能更强、更复杂的服务器上。

        统一的业务逻辑管理，减少了维护费用，同时业务逻辑和表示逻辑的分离有利于各自的扩展和升级。

• 3.语言部分：

        由于Java与XML是天生的一对，有利于系统以后的扩展。 由于Java的平台独立性，可以快速地在不同硬件平台、操作系统、应用服务器和数据库之间移植。

      任何一个技术都不可能是完美的, 同样地, J2EE架构下的系统也有其缺点：

      1.受限于Java 语言本身的局限性,新系统的运行性能较差(但随着Java虚拟机的速度不断提升，这或许不是一个主要的问题)。

      2.J2EE 作为一个通用的系统体系结构, 与专用系统相比,其层次多、接口多、性能较差。

      可以看到, 与现有系统相比, J2EE 架构下的新系统基本解决了传统架构的缺陷, 但同时也带来了性能方面的可能的隐患。总体上说,J2EE 架构具有众多优势,满足了智能网业务管理系统对可扩展性、开放性、性能、实时性等多方面的需求，是目前最理想的解决方案。

【参考文献】