本章节继续借助在线预定图书项目来学习Ice。
实现客户端调用
客户端的写法和之前ice_better_hello中Client的写法基本一样,,测试的时候先把IceBox启动,然后直接跑Client的main方法就可以了,代码虽简单,这里也贴一下,以后这么简单的代码就不展示了:
|
|
新增SMS服务
接下来我们再开发一个简单的服务SMSService,假设是发短信的服务,其接口的Slice文件如下:
SMSService的服务端代码如下,要注意下和OnlineBookService稍有不同,Logger采用了Ice所提供的:
修改config.icebox和config.service:
注意一下,OnlineBook和SmsService的端口不一样,官方不建议将多个服务绑定到同一个EndPoint上。我们再启动下IceBox服务,现在的输出如下:
可见两种Log的输出不一样,具体哪种好,看自己选择吧。下面我们给IceBox加一个配置IceBox.LoadOrder=OnlineBook,SmsService
,可以指定服务启动的顺序。客户端的调用代码就不贴出来了,比较简单。
新增需求
现在有了两个Ice服务,加入现在增加一个需求,通过发送短息完成Book订购,则需要需要在SmsService服务内部发起对OnlineBook接口的调用,这样SmsService就变成OnlineBook的一个客户端了,所以只要遵循个客户端访问服务端的标准做法去调用即可。修改SmsService.java的sendSms()方法:
还有一种共用Communicator的方式来实现:
在config.icebox文件中添加如下配置:
12345# 打印出线程信息Ice.Trace.ThreadPool=1# 共用UseSharedCommunicatorIceBox.UseSharedCommunicator.OnlineBook=1IceBox.UseSharedCommunicator.SmsService=1修改sendSms()方法中构造Ice.ObjectPrx实例的方式,只要有服务的名称就可以了:
1Ice.ObjectPrx base = _adapter.getCommunicator().stringToProxy("OnlineBook");
这种共用Communicator的方式,据说可以实现服务本地调用的优化,从写法上确实也能看出来,没有了Endpoint信息,只有服务的名称了。到目前为止,我们的Endpoint都是写死的,另外对于多个IceBox集群负载均衡也没涉及到。这就引出了以服务注册表Registry为依托的Service Locator组件,以及依赖其而诞生的强大的分布式框架–IceGrid,下一章节我们就来学习IceGrid的相关内容。