电信行业Http接口(通道)设计思路与实现过程

前面好像有人回复了这个问题了：
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。

其实大家最担心的就是HTTP的响应问题，目前就我了解电信有的项目使用的是webservice，其实应该说性能还好（我之前做过中国电信的一个项目，使用的就是webservice）。至于安全性，我个人认为采用验证IP应该就可以了，没有必要搞得太复杂，一般来说能连到电信网络的系统不是一般系统做得到的。

这个网关其实可以参考一下MM7 API,发送跟接收在里面都有实现,只要再稍稍改造下即可.

电信业的那数据库设计看的我脑袋那个疼啊 我在也不想碰了~

何必这么复杂参考MM7呢，其实很简单，用xml消息，按照一定的格式整合消息在服务端解析就可以了。而且还方便以后的扩展，解析消息的类是可以扩展的。且，即使以后不使用HTTP而改用MQ的方式（电信行业系统大多数都会使用MQ）因为性能和系统压力的需要。
网关其实也需要分层的，安全性我觉得还是直接有专业的安全网关来作吧，要接入到电信系统第一步要做的就是先通过验证，这个应用网关采用客户端地址校验足够了。

怎么建立长连接？一个客户端一个长连接？客户端每次调用都使用已有的连接？没明白具体是咋回事。
另外，生命期要多长？

呵呵， 复杂也是因为业务上复杂造成的。其实现在软件系统最怕的就是过渡设计，这种情况在电信行业也比较突出。为了一个无足轻重或者是添花的小功能都会导致设计上的过渡和复杂，这就需要很好的谈判与周旋技巧了。

以后电信行业逐渐会做到融合（无论是电信网和互联网的融合，还是预付费与后付费的融合）。

在这个API中多线程,长短连接,还有安全验证都有很好的实现.这个API是中兴给移动写的,它的并发我测试过,可以达到每秒100以上.

移动的网络和系统建设我不是很清楚，中国电信我倒是比较了解。但是就我个人了解到的情况是其实移动的系统建设的不如电信，移动靠的是什么我觉得就是垄断（无线的发展，因为移动在初期垄断了无线）。
现在移动也慢慢在像电信的系统学习，开始构造CRM这些东西了。（都是题外话了）

其实我的最主要目的就是怕过渡的设计，适合的就是最好的。

几个运营商的sp平台都支持地址群发。1l的是不是做sp代理的？
小的sp不能直连运营商，听说注册资金过千万的才能连。。。。

关于接口可以参考facebook.com或者51.com的实现吧.通过public key和private key来实现安全认证.性能和可靠性大家都看得到.