Saturn's Weblog

.NET Remoting有三种内置通道(Channel)，包括Http, Tcp和IPC通道。如何正确的选择一个通道对Remoting应用程序的传输效率和稳定性会有较大影响。

简单说来，当以下情况出现时推荐使用HTTP管道：

• 分布式系统部署在WAN中，需要穿透防火墙或代理服务器
• 有与其他Web Service系统进行交互的需要
• 使用IIS来架设和部署分布式系统

当出现以下情况时，推荐使用TCP管道：

• 对传输效率要求极高
• 大文件传输

IPC管道的使用由其本身的定义和特性所限制，所以推荐在跨进程的分布式应用程序中使用。

这是我采用英文撰写的一篇关于.NET Remoting文章的一部分，现在仅摘录出其中关于Remoting Channel的部分，以下为原文：

Remoting channels should be properly selected when distributed a real-time system.  A good decision of choosing a channel may improve both the transportation efficiency and the availability of the distributed application.

One should keep in mind that whether to choose one built-in channel with specific formatters depends on the requirements of the real-world distributed applications.

Using the HTTP Channel

When the messages of the distributed system are mainly required to transport over the Internet, it is better to use the HTTP Channel because of the potential impacts of the firewalls. There is always a good chance that the HTTP communication over port 80 or 8080 in some case will be enabled on most firewalls to provide web services to their Internet browser users. In this case, the HTTP Channel with either binary formatter or SOAP formatter should be used to improve the availability of the whole system.

When the distributed system is required to communicate with other remoting or distributed technologies, XML Web Service for example, the HTTP Channel with SOAP formatter is recommended in order to improve the interoperability of the distributed system.

When using IIS to host the server-side distributed components, it is also recommended to use the HttpChannel with the binary formatter for any application which spans multiple hosts (Rammer 2002).  The reason is that IIS provides a host of built-in advantages: built-in authentication, built-in encryption (SSL), and the ability to disable HTTP keepalives which further increases the scalability of your application as it reduces dependencies on single servers. At the same time, the binary formatter helps increase the transportation efficiency of serialized messages.

Using the TCP Channel

When the distributed system requires high performance and all the components are located in LAN, it is better to utilize the TCP Channel. For example, it is given that the system is required to transport large files across different application domain in Intranet, there is no better choice than using the TCP Channel with binary formatter that suits this case. However, this can be also completed successfully by using the HTTP Channel with binary formatter.

Using the IPC Channel

When the distributed system is required to across processes on a single computer, it is recommended to use the IPC Channel. Because the IPC Channel uses named pipes, and compared to use the built-in HTTP or TCP Channel, applications can generally obtain the highest communication performance while still being able to use impersonation and delegation to control access to the remote object. 

在编程资料中，经常会看到Glue Code这个词组。

Glue的意思是“胶水，粘合剂”的意思，那么顾名思义，Glue Code就是粘合代码的意思。

更确切的讲，按照维基百科上的解释：

In programming, glue code is code that does not contribute any functionality towards meeting the program's requirements, but instead serves solely to "glue together" different parts of code that would not otherwise be compatible.

翻译过来，大概意思就是：

在编程中，用glue code所描述的代码并不用来实现程序所需要的任何功能，它仅仅用来将多段代码粘合在一起，从而不至于产生兼容性问题。

儿童节的前一天，星期天。

我作为伴郎参加了一位兄弟在异国他乡的婚礼，这打破了我个人的好几个记录。

记录一：第一次做伴郎，虽然自始至终不知道我的“伴娘”是谁。因为婚礼准备时间仓促，由于找不到真正的情侣作为货真价实的伴郎伴娘；就只有抓我们这些朋友作为壮丁了。

记录二：第一次参加澳大利亚的婚礼，算是比较传统。整个过程在Melbourne Marriage Registry举行，由有经验的Minister主持，非常浪漫。由于激动，新郎Denial紧张到发抖，以至于最后念错了台词……。

还好没将I Do说成I donnot，哈哈，玩笑。

儿童节的这一天，我搬家了。

搬出了原来住的Homestay和那些可爱的朋友们。

说实话，来到墨尔本快半年了，能来到这个Homestay，我很幸运，在这里我找到了家的感觉。如果不是因为公交车经常晚点导致我Timetable紊乱，我也许不会搬出来。

或许很少人能明白，一个在外漂泊的人找到家那种的感觉。

我无法做更多的事情，只能心存感激；然后尽我的能力，让更多的人得到我力所能及的帮助。

本文主要探讨跨平台调用Web Service出现："服务器未能识别 HTTP 标头 SOAPAction 的值"的解决办法。

症状一：

Web Service + ASP.NET 应用程序部署到服务器默认目录中，在IE中用http://<服务器地址>/<程序目录名>/<默认启动页面名>发生“服务器未能识别 HTTP 标头 SOAPAction 的值”错误。

症状二：

在Java平台上调用.NET Web Service的服务时，出现"服务器未能识别 HTTP 标头 SOAPAction 的值"。

症状三：

在Java平台下调用.NET WEB Service，出现数据时有时无。

解决对策：

给.NET的WebService类（即.asmx文件下的类）添加属性[SoapDocumentService(RoutingStyle=SoapServiceRoutingStyle.RequestElement)]

小知识：

什么是SoapAction？它在WSDL中有何作用？

SOAPAction HTTP request header被用来标识SOAP HTTP请求的目的地，其值是个URI地址。SOAP发送并不限制格式、URI特征或其必须可解析，那么在这种情况下，发送一个HTTP SOAP请求时，其HTTP客户端必须使用/指明SOAPAction HTTP request header。

SOAPAction header的内容可以被用在服务端，诸如：防火墙适当的过滤基于HTTP的SOAP请求消息等场景。SOAPAction header的值为空串("")表示SOAP消息的目的地由HTTP请求的URI标识；无值则表示没有指定这条消息的目的地。

在利用AJAX从后台程序提取数据，然后在前端页面显示出来的过程中，我们经常会碰到AJAX提取的数据被缓存，导致结果异常的问题。

具体原因是因为AJAX依赖于JavaScript，而浏览器会自动将JavaScript代码和文件数据缓存在客户端，这有利于用户下次访问时页面的快速下载和解析。

要解决数据被缓存，大概有两种做法。

第一种，是在客户端进行，在AJAX发送请求到后台数据处理页面的URL上加一个随机字符串 即可。这样一来，浏览器会认为AJAX发出的HTTP请求每次都不同（URL不同），从而每次都重新请求。具体做法如下：

xmlHttp.open("GET", "ajax.php?r="+new Date().getTime(), true);

既然是随机字符串，还可以使用：+math.random()，只要保持字符串随机即可。

另外一种是在服务器端进行。具体做法是修改HTTP头信息，手动设置让其过期。下面以PHP为例说明：

header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
 header ("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); // always modified
 header ("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
 header ("Pragma: no-cache"); // HTTP/1.0

其他语言，比如ASP，J2EE，做法与此非常类似。

通常情况下，我们只需要选其以上两种方法的其中一种即可。

在Java里面有内建的排序函数，比如要对一列字符数组进行排序，可以使用如下方法：

double[] lengths = {120.0, 0.5, 0.0, 999.0, 77.3};
Arrays.sort(lengths);
System.out.println(Arrays.toString(lengths));

当然，我们可以用最原始的排序方法，比如冒泡法来对数组列进行排序，如下：

Integer[] arrIds = {12,24,1,2345,24,10};

int len = arrIds.length;

int temp;

if(len>0){
    for(int i = 0;i<len;i++){
  for(int j=len-1;j>=i;j--){
      if(arrIds[j]>arrIds[i]){
    temp = arrIds[i];
    arrIds[i] = arrIds[j];
    arrIds[j] = temp;
   }
  }
 }
}

for(int i=0;i<len;i++){
    System.out.println(arrIds[i]);
}

可以将以上算法简单的封装成方法，在实际中应用。

今天在用NetBeans下开发BPEL时碰到了一个非常郁闷的事情，极可能是个BUG。

在NetBeans 6.5下，当我在一个WEB Project中调用已经部署好的BPEL时，SOAP始终返回的是Null值，就是我标题里面的NullPointerException。

此BPEL流程在逻辑和代码上绝对没有问题，这100%可以肯定，理由是在部署在服务器上的复合应用程序里面，我做过TEST CASE，SOAP数据返回一切正常。

让人崩溃的事情出现了，当我直接通过桌面用户的程序或者Console应用程序来Consume这个BPEL WebService却可以返回正常的数据。

于是，我开始怀疑是服务器的问题，在J2EE容器由Tomcat换成Glassfish后，发现问题依旧。

值得注意的是，在NetBeans的邮件列表里面有不少人碰到与我类似的问题。但到目前为止，我仍没有找到原因所在。

NetBeans 6.5对BPEL开发的支持实在是比较鸡肋。举个例子来说，我到现在为止都没有发现直接支持RESTful WebService的NetBeans插件。Eclipse倒是不少，比如JOpera，它可以直接将RESTful WEB服务返回过来的数据编组为SOAP格式，再供BPEL作为合作伙伴方式调用。

最近几天，关于wolframalpha挑战Google搜索引擎霸主地位的新闻在业界抄的是沸沸扬扬。

一款名为WolframAlpha（简称WA）的新型网络搜索引擎于16日正式上线（英文网址为www.wolframalpha.com）。这种搜索引擎不会返回大量网页链接，而是基于新的算法和大型数据库，直接给出答案。

我并不认为现在的wolframalpha能够对Google造成任何形式的挑战和威胁，那些耸人听闻的说法不过是媒体的大肆炒作罢了。毕竟类似wolframalpha目前这种新式语义化搜索技术尚不成熟，而以一种不成熟的技术去颠覆Google苦心经营了十年的搜索帝国，这显然是天方夜谭。更何况，从心理学角度讲，用户对Google本身的依赖，并不只决定于Google搜索技术水平，还由Google在某一特定区域的品牌价值决定。

这也是就为什么Google在中国市场很难战胜Baidu的原因。2005年的时候，百度可以自豪的称，百度更懂中文。但经过若干年的本地化，谷歌对汉语搜索的支持似乎并不比百度差多少。不过，就目前的市场份额来看，Google仍然不能对百度造成太大的威胁。这主要是因为中国网民已经对百度，或者说这个品牌产生了依赖。

回到wolframalpha挑战Google这一话题上来。

人们对于wolframalpha作为“Google杀手”的愿景，实际上是对未来搜索引擎的愿景——语义化搜索。

传统搜索引擎，不管是雅虎，Google还是百度，对搜索结果的处理都是首先对搜索关键字进行分析，然后根据“网页受欢迎度”对其已索引的网页进行排序，然后展现给用户，由用户对信息进行进一步检索。这里所提到的“网页受欢迎度”就是我们通常所说的“网页评级”。

换句话说，搜索引擎本身并不理解用户输入关键字的具体意思，它只对字符本身进行匹配。

传统搜索引擎的诟病就出在这里：一个网页评级很高的网站所输出的某篇文章（比如国内的几大门户网站），或许文章的“质量”并不高，而且可能并不是用户所希望检索到的文章。但就是因为这篇文章所在网站的网页评级很高，导致这篇文章在搜索引擎的排序却很高。这其实在一定程度上是对用户的一种误导，因为用户失去了以最短时间获取最高质量文章的机会，他们得到的结果可能仅是一些牛头不对马嘴的文章，此时他们需要更多的时间来进一步对这些文章进行筛选甄别。换个角度，如果某个独立博客上有一篇非常优秀的文章，但正是因为这个博客本身的网页评级不高，导致这篇文章失去了被“曝光”的机会。

语义化搜索引擎所需要做的就是传统搜索引擎没有做到，或者说没有做好的这一部分。那就是：搜索引擎“理解”用户输入文字的意思，然后根据语义给出筛选结果。

Wolframalpha正是一个集成此思想的新型搜索引擎，它就像一个互联网的先知，负责回答用户的各种问题，比如在Wolframalpha上搜索"China"，你会看到有关中国的各种统计信息，包括人口，GDP，语言等等很多信息。

假设你进一步精确你的搜索关键字，输入"Where is China"（中国在哪？），Wolframalpha会直接告诉你中国在世界地图中的位置。

至此，或许你已经不难理解为什么国外媒体喜欢将Wolframalpha当作Google杀手了。

语义化搜索引擎，国外比较有名的还有Hakia（国内的我还没有发现，如果谁发现了请告诉我），它同样以文章质量的评级来对搜索结果进行排名，而非受欢迎程度。Hakia还是一个SaaS的典型应用，在以后的文章中我还会提到。

毫不夸张的说，语义化搜索本身的确可以对Google造成致命一击，但问题是，现在的wolframalpha并不等于语义化搜索引擎。如果你多尝试输入几次关键字，就会发现它目前能回答的问题很少。但不管怎样，Wolframlapha的出现或许昭示着搜索引擎格局的重大变更。互联网的准则就是"Nothing is impossible"(没有什么不可能)，不相信这句话的人结局会很悲惨，比如现在的雅虎。

但不管怎样，我斗胆预言，在未来二十年内，搜索引擎的格局势必会再次发生转变，而转变的重心之一即是搜索引擎的语义化。

最近正在做的一个项目使用Java在同一个客户端中Consume多个REST类型的WebService，包括Yahoo! Search API, YouTube Video API和Flickr。

我这里想说的不是如何使用Java来调用这几个知名的WebService，而是我个人在客户端制作过程中编写的几个简单实用的函数。关于Java调用WebService的具体方法和方案，我会在稍后的系列日志中详细说明。

说明：由于我本人也是正式接触Java不久，如果以下函数有不妥的地方，请告诉我。

1、Java中的向上取整：

我们知道，在PHP中如果要对一个浮点数进行向上取整操作，只需要使用PHP的内置函数ceil即可。

比如，要将1/3向上取整为1，只需要如下操作：

echo ceil(1/3);

那么在Java中，我们也可以编写一个小函数来实现上面的功能：

public int ceil(int a, int b){
    return(((double)a/(double)b)>(a/b)?a/b+1:a/b);
}

2、Java中将Unix时间戳字符串转换成普通日期格式。

//Convert Unix timestamp to normal date style
private String TimeStamp2Date(String timestampString){
  Long timestamp = Long.parseLong(timestampString)*1000;
  String date = new java.text.SimpleDateFormat("dd/MM/yyyy hh:mm:ss").format(new java.util.Date(timestamp));
  return date;
}

在调用Yahoo! News Search的WebService中，当我们提交了一个REST请求之后，假定Yahoo服务器回传给我们一个XML格式文档（假定是因为REST可以以多种格式回传数据流，比如JSON和CSV），此时每条新闻的日期均采用Unix时间戳来显示。在实际运用中，我们需要将它们转换成人们可以理解的正常格式。这就用到了下面我写的这个简单函数。

FAQ：什么是Unix时间戳？

Unix时间戳（英文为Unix epoch, Unix time, POSIX time 或Unix timestamp）是从1970年1月1日（UTC/GMT的午夜）开始所经过的秒数，不考虑闰秒。

我的博客程序后台使用的是TinyMCE编辑器，今天花了点时间给编辑器整合了Geshi代码高亮。

C#语法高亮测试：

1 2 3 

private static void test(){  Console.WriteLine("Welcome to cnSaturn.com"); }

ASP语法高亮测试：

1 2 3 

function test(){  response.write "Welcome to cnSaturn.com" }

JAVA语法高亮测试：

1 2 3 

public static void test(){  out.println("Welcome to cnSaturn.com"); }

PHP语法高亮测试：

1 2 3 

public function test(){  echo "Welcome to cnSaturn.com"; }