﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-一江春水向东流-文章分类-电信服务技术</title><link>http://www.blogjava.net/huyi2006/category/29247.html</link><description>专注于网络应用开发，电信增值服务，数据挖掘，通信工程
                                         --武汉---</description><language>zh-cn</language><lastBuildDate>Tue, 25 Mar 2008 18:12:35 GMT</lastBuildDate><pubDate>Tue, 25 Mar 2008 18:12:35 GMT</pubDate><ttl>60</ttl><item><title>Radius协议</title><link>http://www.blogjava.net/huyi2006/articles/188616.html</link><dc:creator>胡意</dc:creator><author>胡意</author><pubDate>Tue, 25 Mar 2008 15:27:00 GMT</pubDate><guid>http://www.blogjava.net/huyi2006/articles/188616.html</guid><wfw:comment>http://www.blogjava.net/huyi2006/comments/188616.html</wfw:comment><comments>http://www.blogjava.net/huyi2006/articles/188616.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/huyi2006/comments/commentRss/188616.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/huyi2006/services/trackbacks/188616.html</trackback:ping><description><![CDATA[RADIUS主要用于对远程拨入的用户进行授权和认证。它可以仅使用单一的“数据库”对用户进行认证（效验用户名和口令）。它主要针对的远程登录类型有：SLIP、PPP、telnet和rlogin等。 <br /><br />其主要特征有： <br /><br />1． 客户机/服务器(C/S)模式 <br /><br />一个网络接入服务器(以下简称NAS)作为RADIUS的客户机，它负责将用户信息传入RADIUS服务器，然后按照RADIUS服务器的不同的响应来采取相应动作。另外，RADIUS服务器还可以充当别的RADIUS服务器或者其他种类认证服务器的代理客户。 <br /><br />2．网络安全（Network Security） <br /><br />NAS和RADIUS服务器之间的事务信息交流由两者共享的密钥进行加密，并且这些信息不会在两者之间泄漏出去。 <br /><br />3．灵活认证机制（Flexible Authentication Mechanisms） <br /><br />RADIUS服务器支持多种认证机制。它可以验证来自PPP、PAP、CHAP和UNIX系统登录的用户信息的有效性。 <br /><br />4．协议可扩展性(Extensible Protocol) <br /><br />所有的认证协议都是基于“属性－长度－属性值”3元素而组成的。所以协议是扩展起来非常方便。在目前很多比较高版本的Linux中，它们都把 RADIUS的安装程序包含在系统源码中。这样使得我们可以很容易地通过免费的Linux系统学习RADIUS授权、认证的原理和应用。 <br /><br /><br />RADIUS协议原理 <br /><br /><br />要弄清楚RADIUS协议为何能实现授权和认证，我们必须应该从四个方面去认识RADIUS协议：协议基本原理、数据包结构、数据包类型、协议属性。下面我们就来详细地介绍这些内容。 <br /><br />协议基本原理 <br /><br />NAS提供给用户的服务可能有很多种。比如，使用telnet时，用户提供用户名和口令信息，而使用PPP时，则是用户发送带有认证信息的数据包。 <br /><br />NAS一旦得到这些信息，就制造并且发送一个“Access-Request”数据包给RADIUS服务器，其中就包含了用户名、口令（基于MD5加密）、NAS的ID号和用户访问的端口号。 <br /><br />如果RADIUS服务器在一段规定的时间内没有响应，则NAS会重新发送上述数据包；另外如果有多个RADIUS服务器的话，NAS在屡次尝试主RADIUS服务器失败后，会转而使用其他的RADIUS服务器。 <br /><br />RADIUS服务器会直接抛弃那些没有加“共享密钥”（Shared Secret）的请求而不做出反应。如果数据包有效，则RADIUS服务器访问认证数据库，查找此用户是否存在。如果存在，则提取此用户的信息列表，其中包括了用户口令、访问端口和访问权限等。 <br /><br />当一个RADIUS服务器不能满足用户的需要时，它会求助于其他的RADIUS服务器，此时它本身充当了一个客户端。 <br /><br />如果用户信息被否认，那么RADIUS服务器给客户端发送一个“Access-Reject”数据包，指示此用户非法。如果需要的话，RADIUS服务器还会在此数据包中加入一段包含错误信息的文本消息，以便让客户端将错误信息反馈给用户。 <br /><br />相反，如果用户被确认，RADIUS服务器发送“Access-Challenge”数据包给客户端，并且在数据包中加入了使客户端反馈给用户的 信息，其中包括状态属性。接下来，客户端提示用户做出反应以提供进一步的信息，客户端得到这些信息后，就再次向RADIUS服务器提交带有新请求ID的 “Access-Request”数据包，和起初的“Access-Request”数据包内容不一样的是：起初“Access-Request”数据包 中的“用户名/口令”信息被替换成此用户当前的反应信息（经过加密），并且数据包中也包含了“Access-Challenge”中的状态属性（表示为0 或1）。此时，RADIUS服务器对于这种新的“Access-Request”可以有三种反应：“Access-Accept”、“Access- Reject”或“Access-Challenge”。 <br /><br />如果所有的要求都属合法，RADIUS返回一个“Access-Accept”回应，其中包括了服务类型(SLIP, PPP, Login User等)和其附属的信息。例如：对于SLIP和PPP，回应中包括了IP地址、子网掩码、MTU和数据包过滤标示信息等。 <br /><br />数据包结构 <br /><br />RADIUS数据包被包装在UDP数据报的数据块（Data field)）中，其中的目的端口为1812。具体的数据包结构如表1。 <br /><br /><br />8位 8位 16位 <br />code Identifier Length <br />Authenticator（128位） <br />Attributes…（不定长） <br /><br /><br /><br />· Code Code域长度为8位，具体取值见表2。其中，1、2、3用于用户认证，而4、5则是统计流量用，12、13 用于试验阶段，255作为保留。 <br /><br /><br />code 含义 <br />1 Access-Request <br />2 Access-Accept <br />3 Access-Reject <br />4 Accounting-Request <br />5 5Accounting-Response <br />11 Access-Challenge <br />12 Status-Server(experimenta) <br />13 Status-client(experimenta) <br />255 Reserved <br /><br /><br /><br />· Identifier Identifier域长度为8位，主要用于匹配请求和回应数据包，也即是数据包的编号。 <br /><br />· Length 长度为16位，取值范围（20&lt;=Length&lt;=4096），此长度包括Code、Identifier、Length、 Authenticator和 Attribute五个数据域的长度总和（Code、Identifier、Length、Authenticator为定长，Attribute为变 长)。超出范围的数据将被视为附加数据（Padding）或直接被忽略。 <br /><br />· Authenticator 长度为16个字节(128位)，主要用于鉴定来自RADIUS服务器的回应，同时也用于对用户口令进行加密。 <br /><br />(1) Request Authenticator <br /><br />在“Access-Request”数据包中，Authenticator是一个16字节的随机数，称为“Request Authenticator”。它在NAS和RADIUS服务器之间通过“共享密码”(secret)传输数据的整个生命周期中是唯一的。　　 <br /><br />(2) Response Authenticator <br /><br />在“Access-Accept”、“Access-Reject”和“Access-Challenge”中的Authenticator域被称为“Response Authenticator”。 <br /><br />有下面的计算方法： <br /><br />ResponseAuth = MD5(Code+ID+Length+RequestAuth+ Attributes+Secret) ——（公式1） <br /><br /><br /><br />· Attributes 属性域的数据格式如表3所示。 <br /><br /><br />8位 8位 不定长（0或多个字节） <br />Type Length value… <br /><br /><br /><br />Type指示了Atribute的类型，通用的有几十种，如表4所示。 <br /><br /><br />Type 说明 Type 说明 <br />1 User-Name 5 NAS-Port-Id <br />2 Password 6 Service-Type <br />3 CHAP-Password 7 Framed-Protocol <br />4 NAS-IP-Address … … <br /><br />数据包类型 <br /><br />RADIUS数据包的类型由其Code域（头8位）指定。 <br /><br />· Access-Request（接入-请求） <br /><br />“Access-Request”数据包由NAS发出，由RADIUS服务器接收。 <br /><br />其中的“User-Password”或“CHAP-Password”属性值被默认地以MD5方法加密。 <br /><br />数据包结构如表5所示。 <br /><br /><br />8位 8位 16位 <br />Code＝1 Identifier-随着Attributes的Value变化而变化，重传时则保持不变 Length <br />Authenticator（128位）—根据Identifier变化而变化 <br />Attributes…（不定长） <br /><br /><br /><br />Attributes应该包括以下几个属性： <br /><br />◆ “User-Name” <br />◆ “User-Password”或“CHAP-Password” <br />◆ “NAS-IP-Address” <br />* “NAS-Identifier” <br />◆ “NAS-Port” <br />◆ “NAS-Port-Type” <br /><br /><br /><br />· Access-Accept <br /><br />“Access-Accept” 由RADIUS服务器发出，返回给NAS。表示用户的信息是合法的。其中包括了必要的配置信息，以便下一步为用户提供服务。数据包结构如表6所示。 <br /><br /><br />8位 8位 16位 <br />Code＝2 Identifier-和“Access－Request”的Identifier相同 Length <br />Authenticator(128位)－属于Response Authenticator，由公式1计算得到 <br />Attributes…（不定长） <br /><br /><br /><br />Access-Reject“Access-Reject”由RADIUS服务器发出，返回给NAS。表示用户的信息是非法的。其中应该包括一个或多个的“Reply-Message”（回复消息，包含一些便于NAS返回给用户的一些错误信息）。数据包结构如表7所示。 <br /><br /><br />8位 8位 16位 <br />Code＝3 Identifier－和“Access－Request”的Identifier相同 Length <br />Authenticator（128位）－属于Response的Authenticator，由公式1计算得到 <br />Attributes…（不定长） <br /><br /><br /><br />属性 <br /><br />属性如表8所示。其中，Length的计算方法为：Type+Length+Value。 <br /><br /><br />8位 8位 不定长（0或多个字节） <br />Type Length Value… <br /><br /><br /><br />Value有4种类型： <br /><br />◆ String —— 0~253字节，字符串 <br /><br />◆ Ipaddress —— 32位，IP地址 <br /><br />◆ Integer —— 32位，整数 <br /><br />◆ Time —— 32位，从00:00:00 GMT, January 1, 1970到当前的总秒数 <br /><br />从这里可看出，RADIUS协议是一个不定长的协议栈。<img src ="http://www.blogjava.net/huyi2006/aggbug/188616.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/huyi2006/" target="_blank">胡意</a> 2008-03-25 23:27 <a href="http://www.blogjava.net/huyi2006/articles/188616.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>内存数据库在BSS账务处理中的应用</title><link>http://www.blogjava.net/huyi2006/articles/178434.html</link><dc:creator>胡意</dc:creator><author>胡意</author><pubDate>Tue, 29 Jan 2008 16:19:00 GMT</pubDate><guid>http://www.blogjava.net/huyi2006/articles/178434.html</guid><wfw:comment>http://www.blogjava.net/huyi2006/comments/178434.html</wfw:comment><comments>http://www.blogjava.net/huyi2006/articles/178434.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/huyi2006/comments/commentRss/178434.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/huyi2006/services/trackbacks/178434.html</trackback:ping><description><![CDATA[
		<p>        BSS系统是每个电信运行商的核心业务支撑系统。近年来，随着支持用户量和话单量的成倍增长和实时业务的不断扩展，数据处理量大量增加，业务处理模式日趋复杂，必然导致主机CPU和I/O占用不断成线性增加。在此情况下，即使增加硬件支持，现有架构下系统的处理速度也很难得到质的提高。<br /><font size="5">引言</font><br />中国加入WTO之后，电信市场将逐步向外资开放，2006年开始外资将全面进入中国电信业，国际先进的服务模式和服务水平势必会对国内电信运营商提出更高的挑战。同时国内电信业的竞争格局也发生了深刻的变化：第三、四张移动牌照即将发放，竞争形势更为残酷；用户增量市场逐渐萎缩，作为我们运营商更需要的是如何提高自身服务质量，在存量市场中保持原有客户以及从竞争对手中获得客户。这些都意味着市场的竞争已逐步由技术驱动转向市场驱动和客户需求驱动，电信运营商必须从传统的经营模式向“以客户为中心，以市场为导向”的经营模式转变，也将从单纯的网络竞争、价格竞争转向网络、价格与服务、渠道、品牌相结合的全方位的竞争模式。<br />电信业正进入新一轮的高速发展时期，市场需求成为驱动力??市场部门不断推出的各种各样促销计划和市场推广活动，以及用于刺激用户使用运营商的服务以扩大用户群的全新变化，使得计费账务系统必须实现非常复杂的资费、折扣的管理能力和资费批价的能力。随着电信业务的迅猛发展，电信运营商的计费账务系统的压力也越来越大，如何保证计费账务系统的实时性成为各运营商关心的重点。<br />BSS系统是每个电信运行商的核心业务支撑系统。近年来，随着支持用户量和话单量的成倍增长和实时业务的不断扩展，数据处理量大量增加，业务处理模式日趋复杂，必然导致主机CPU和I/O占用不断成线性增加。在此情况下，即使增加硬件支持，现有架构下系统的处理速度也很难得到质的提高。由此对业务产生了极其不利的影响：账务功能不灵活，系统对业务需求的支撑灵活度不够；难以在短时间内响应市场需求，效率与灵活度难以兼得；计费实时性得不到确切的保障，无法给用户提供实时准确的查询服务；账务批处理情况下可能造成与营业应用的性能相互影响。为此，现有的BSS系统进行框架结构上的全面改造已经是大势所趋。</p>
		<p>  内存数据库介绍<br />1．什么是内存数据库<br />众所周知，相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相对于从磁盘上访问数据能够极大地提高应用的性能。一方面由于从磁盘上读写数据时需要进行磁头的机械移动，直接从内存中读写数据则是电信号的移动，两者速度完全不在一个数量级上；另外一个容易被忽略的时间就是系统调用时间，因为每次对磁盘进行访问都需要进行一次操作系统的系统调用，而系统调用相对于普通的库函数调用要花费更多的时间。之所以要进行系统调用是因为处于用户态的应用程序不能直接对外部设备进行操作，而需要进入内核态，由操作系统调用相应设备的驱动程序完成对设备的操作。系统调用一般是通过中断来完成得，CPU只有在完成当前时钟周期的操作后在下一个时钟周期处理中断请求，并且在进行中断处理时需要进行上下文信息的保存与切换。所以一个应用如果频繁地进行系统调用也会极大地降低系统地性能。正是由于这两方面的原因，使得从磁盘上读写数据比从内存中读写数据的时间开销要大得多。<br />传统的数据库管理系统的所有数据都是放在磁盘上进行管理，需要频繁地访问磁盘来进行数据的操作。如上所述，由于磁盘数据访问本身的性能瓶颈，数据库管理系统的性能提升受到了很大的限制。然而，近年来，随着计算机技术的飞速发展，要解决这一问题已经有了现实可能：内存容量的不断提高，而价格不断下跌；计算机进入了64位时代，操作系统可以支持更大的地址空间。<br />正是基于技术的发展，以及市场上对更加快速和实时的数据库管理系统的需求，出现了内存数据库系统。内存数据库系统抛弃了磁盘数据管理的传统方式，基于全部数据都在内存中管理进行了新的体系结构的设计，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，所以数据处理速度一般比传统数据库的数据处理速度要快很多，一般都在10倍以上。</p>
		<p>2．内存数据库和磁盘数据库的性能测试对比<br />以下比较基于内存数据库和磁盘数据库中完全相同的数据库表结构和应用，测试对比的数据库为Oracle 9i和ALTIBASE 3.5.7，在相同的测试环境下进行。<br />表1　<br />INSERT：对oracle和ALTIBASE进行相同表的插入操作，查看插入的效率。 </p>
		<p>INSERT：对oracle和ALTIBASE进行相同表的插入操作，查看插入的效率。</p>
		<p>3．内存数据库和利用程序吊用内存的对比<br />由于内存的高速特点，早在2000年以前就有通过进程吊用内存的方式来进行程序处理，内存数据库提供的是一个模块化结构，保持一个核心引擎相对不变，外围可变，提供标准扩展接口和灵活的二次开发能力和良好的流程优化能力：</p>
		<p>在BSS系统中采用内存数据库的理由<br />拿江苏联通过去的BSS系统为例，账务处理模块的性能瓶颈是在计费处理和销账处理。<br />由于数据量大、用户资料量大、计费处理模型相对复杂、以Flist支持字段变化和格式可配置等原因，使得现在的计费处理速度相对较慢。而由于清单数据量非常大，将其全部放入内存数据库中是不太可能的。为了利用内存数据库的高速度，则只能采取折中的方法，全部清单数据放在磁盘数据库中，根据实际情况只将一段时间内的清单数据保存在内存数据库中，费用累计和优惠可以针对这一段时间内的清单数据进行一个事务性处理。其他数据，例如累计费用数据，用户资料，费率和优惠信息等相对与清单数据来说数据量较小，可以直接放在内存数据库中。将数据加载到内存数据库中的基本原则是，数据经常用到且数据量不会很大，数据查询操作比数据写和更新操作要频繁。除计费处理外，当其他业务应用需要用到这些数据时也都直接从内存数据库中取。<br />对于销账处理而言，由于在销账处理的过程中涉及到多张表，在用户请求缴费时，在数据库中会将查询出来的资料信息和费用信息放在两张临时表中，一个为资料信息临时表，一个为费用临时表。由于所有缴费人员都同时用到这两张临时表，在传统数据库中往往出现大量争用，大大延长这两张物理表查询所需数据的时间。将这两临时表放在内存数据库中后，由于内存处理速度远远快于磁盘IO，争用出现的可能大为降低，极大减少了单独事务的相应处理时间，得以满足大量并发访问的要求。</p>
		<p>图1　江苏联通BSS原账务处理流程</p>
		<p>当然，如果不采用内存数据库来管理以上的数据，我们可以采取将这些数据组织成相应的数据结构，并用一些共享内存算法来进行查询和更新处理。但是从前面提到的两者对比来看，这样做，开发量大，开发周期长，对程序员要求高；建立的系统也会难以维护、查询和二次开发，并且逻辑结构复杂，接口也难以扩展；而最关键的是，数据完整性和一致性难以保障。相对于利用程序开发调用内存处理来说，内存数据库自有其优势。首先，内存数据库是产品化的数据库管理软件，已经是完整的产品，极大缩短了开发周期；其次，内存数据库有着开放的平台和接口，程序开发和移植更加灵活便捷，也便于维护和二次开发；可以通过使用统一的SQL语言方便的查询内存中的数据；在数据库中保障数据的安全性和完整性。这些优势，对于快速部署和简化维护都是有利的。</p>
		<p>内存数据库在江苏联通BSS账务处理系统中应用的特点和效果<br />江苏联通在账务处理系统中采用了韩国的产品ALTIBASE内存数据库。为完成公司提出的计费实时性指标要求，我们认为只有从底层彻底改变整个账务处理的体系架构，才能对性能有质的提高。ALTIBASE内存数据库管理系统是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。在江苏联通运用之前，在电信领域ALTIBASE内存数据库只有韩国SK有大型的全面解决方案。江苏联通在综合分析了SK的案例以及组织了多次大规模周详的测试后才决定运用此产品。<br />江苏联通是国内第一家将内存数据库运用于大型支撑系统的运营商。因为账务处理模块是效率瓶颈最大、也是对系统压力最大的一个模块，对用户打电话后查询话单的实时性感知度以及小额欠费都有较大影响，江苏联通重点针对账务处理系统引入了ALTIBASE技术，以便于提高客户满意度和减少费用流失。<br />自ALTIBASE内存数据库在江苏联通BSS账务处理系统中上线一年来，运行一直非常稳定。在应用中，只把最需要的中间数据放到内存库中，节省了内存的开销又提高了效率，把好钢用在了刀刃上。因为原先的账务处理瓶颈就在于读取营账的用户数据以及写入账务中间数据的频次非常高，频繁的物理读写造成了I/O的瓶颈，而且会影响前台系统的性能。通过采用复制技术将Oracle磁盘数据库中账务处理需要用到的营账数据实时复制增量数据到ALTIBASE内存数据库中去，将处理好的中间账务结果也写入ALTIBASE，这样做到了只把造成瓶颈的数据放到内存中处理，也就是用最快速的存储资源解决了开销最大的处理操作。另外，ALTIBASE内存数据库管理系统为需要容错服务的系统提供实时数据库复制的功能，采用联机日志的网络复制实现了双机之间数据的同步。采用双机热备的方式，既实现了高可用性又实现了负荷分摊。在我们的设计架构中实现了双机热备，同时我们将前台的实时话费的查询接口都链接到备库上，这样就实现了双机分摊账务和营业两种应用的功效。</p>
		<p>
				<br />图2　江苏联通BSS现账务处理流程</p>
		<p>1．内存数据库在江苏联通BSS账务处理系统中应用的特点<br />(1)只把最需要的中间数据放到内存库中，节省了内存的开销又提高了效率，把好钢用在了刀刃上<br />因为原先的账务处理瓶颈就在于读取营账的用户数据以及写入账务中间数据的频次非常高，频繁的物理读写造成了I/O的瓶颈，而且会影响前台系统的性能。我们采用了复制技术将Oracle磁盘数据库中账务处理需要用到的营账数据实时复制增量数据到Altibase内存中去，将处理好的中间账务结果也写入Altibase，这样做到了只把造成瓶颈的数据放到内存中处理，也就是用最快速的存储资源解决了开销最大的处理操作。<br />2．采用双机热备的方式，既实现了高可用性又实现了负荷分摊<br />ALTIBASE内存数据库管理系统为需要容错服务的系统提供实时数据库复制的功能，采用联机日志的网络复制实现了双机之间数据的同步。在我们的设计架构中，备机既实现了双机热备、同时我们将前台的实时话费的查询接口都链接到备库上，这样就实现了双机分摊账务和营业两种应用的功效。<br />3．投资保护<br />使用内存数据库可节省硬件投资和系统维护成本。通过对比，如果要达到目前的计费实时性指标要求，按照开发商的建议，要将CPU扩展到32个，内存64G，同时系统开发商还要作大量的程序修改工作；而目前在10个CPU、95G内存上系统正常运行，CPU的平均占用率大约在55%--75%（原先为95%）。按照常识，1G内存的价格约为1颗CPU的1/10。即节省了约19个CPU的投资。而在收益方面：根据指标数据，采用内存数据库后，平均小额欠费率下降到老系统的55％左右，按此推算，每月给公司节约成本千万以上。<br />结束语<br />在当今电信领域，传统的一些支撑系统的架构已经逐渐不能满足日益增长的业务需求和客户需求，引入一些新的技术来解决我们生产中遇到的问题是必然的，这些新的技术架构很可能在今后会成为一种发展趋势，就像SAN替代DAS、关系型数据库替代传统数据库那样。<br />ALTIBASE在江苏联通BSS系统中的运用就是一个采用新技术架构实现系统目标的典型案例。主要有以下几点经验可以借鉴于同类的新产品的应用上：<br />（1）不轻易对现有架构做大范围的改动，保证框架稳定；<br />（2）控制成本、有效使用，将好钢用在刀刃上；<br />（3）针对系统中最主要的问题，投入最合适的产品或解决方案，实现既定的目标。<br />江苏联通在账务处理系统中率先采用ALTIBASE内存数据库体系架构，提高了系统处理速度2.5倍，使得系统的实时性大大提高，降低了小额欠费率、减轻对生产系统的压力。<br />内存数据库只是多种新技术中有代表性的一种而已，只要解放思想、选用得当，完全可以在投入不大的情况下以这类实用的产品解决系统中本来难以改变的瓶颈。在未来的BSS发展方向中内存数据库会逐渐成长为一股中坚力量，在客户细分、用户行为分析、产品管理、欠费控制系统等需要复杂高速运算的系统中发挥作用。</p>
		<p> </p>
<img src ="http://www.blogjava.net/huyi2006/aggbug/178434.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/huyi2006/" target="_blank">胡意</a> 2008-01-30 00:19 <a href="http://www.blogjava.net/huyi2006/articles/178434.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>