看了上一篇文章，大家一定觉得我在吹牛，不就是一个发送短消息的小程序，也敢称企业级短信平台，呵呵，别着急，昨天的内容就好比万里长征的第一步，只有第一步走出去才会有以后的千千万万步，所以第一步要走好走扎实才行。
费话就不多说了，马上开始今天的内容。
昨天我们的目标很明确，就是做一个能发送短消息的小程序，而今天的需求就更复杂一些，我常说具体问题具体分析，但这次我不能再这样了，因为需求是多种多样的，为了不使本文沦为长篇大论而无法收尾，我尽量把问题简单化，所以我们这次的这个DEMO仅仅是构建一个发送短消息的平台。
既然是一个平台，就需要有服务提供者和服务使用者。两种之间的关系显然是一种调用和被调用的关系。既然是一个平台，那么我们当然希望它能在大多数环境下使用，比如说可以针对互联网上的用户提供发送服务，可以只针对局域网内用户提供发送服务，可以只针对本机用户提供发送服务（废话…@#$#^%）。既然是一个平台，我们当然希望这个服务能很容易的被其它的客户端引用，比如说windows应用程序或是web应用程序。
OK，面对以上三个对短信平台的基本要求，我们可以看到这将是一个分布式的项目。值得庆幸的是，.NET已经为我们进行分布式开发提供了充分的准备，我们只需要拿起手中的利器就能毫不费力的取得胜利。而这些利器就是Remoting和Web Service。和昨天一样，如果你对这些技术不是很了解，可以查阅网上的资料，但你并不需要很深入的学习（暂时不需要），因为他们都高深莫测，想一口吃个胖子是不可能的，我们可以通过一些实例来逐渐深入的学习和熟悉它们。
（图１：发送短消息的简单用例）
通过上面的用例可以看出，服务调用者是通过“发送短消息”这样一个接口来实现发送的，说到服务接口，我们马上就会想到web service，对，就是这么一个东东，用它来做为服务接口再合适不过了。一下就被你猜中，是不是觉得太简单了？
先不要高兴的太早，服务端以web服务的形式出现是不切合实际的。这样做的后果是：在每次请求时都需要重新打开手机的串口，初始化服务，然后才能发送，首先这样会因为时间上的延误造成调用端超时、死锁，其次我们并不能保证每次连接都能成功，如果不成功就会造成信息丢失，这显然是不允许的。造成以上情况的直接原因是web service和所有web应用程序一样，不能保持对象状态，只能对请求作出回应。因此在建立web service的同时，我们还需要在服务端创建一个对象来保持短信服务的状态并监控连接和发送情况。这个对象一般情况下是一个windows应用程序，但在我的这个DEMO里它是一个windows服务，因为我希望它一开机就加载。
这样的话，我们的服务器端就运行了两个应用程序，一个提供web service接口，一个执行短信发送服务，两者共同合作完成发送短消息的动作。为了使它们能够互相交互，我们有两种选择，一种就是刚才用到web service技术，一种就是Remoting技术。关于Remoting的技术细节，大家可以查看这里。因为两个服务程序在同一台服务器，所以出于性能的考虑我选择了Remoting。
流程已经很清楚了，服务端：服务器开机－>自动加载短信服务－>初始化短信平台；客户端：调用者调用服务->服务接口接收信息->触发“发短信事件”->发送短消息。在搞清楚这些之后我们就可以动手搭建平台了，具体过程我就不细述了，大家可参考本文最下边的DEMO。需要说明的是，这个DEMO只是简单的实现了一些基本功能，并没有考虑安全性、并发性、稳定性和异常处理，因为这些技术细节不在本文讨论范围之内，我会在以后的blog中针对部分内容做更深入的探讨。
以下是这个平台各个模块的功能和要点：
RemoteServer：相当于业务逻辑层，所有短信操作都在这里边。ReadConfig.cs文件里存放手机的端口号和其它参数信息。
WindowsServer：看名字就知道是一个windows服务程序，它是RemoteServer的宿主，它里边的内容很简单，只是注册了一个信道。在第一次接收到调用端请求时，它会构造一个服务对象。并将一直保持其状态，直到服务被中断。
这个程序在使用时需要先注册。注册方法是：installutil WindowsServer.exe 卸载方法是：installutil /u WindowsServer.exe
WindowsTest：调用短信服务的一个windows应该程序，通过它可以打开或关闭串口、发送短消息等。
SmsWebService：服务接口，可以被windows应用程序和web应用程序引用。
WebTest：一个web应用程序，只有一个发送短消息的页子，在它里边引用了上面的web服务。
源码下载：
本文的DEMO（下载关闭）
发表于 @ 2004年09月23日 16:02:00|评论(loading...)|编辑