质疑buffalo使用burlap协议

buffalo使用burlap做xmlrpc的做法值得反对。
burlap这种内部维持对象类型的协议，不适合用来做ajax-rpc.
burlap适合java服务节点之间的远程调用，并不适合js <-->java.

jdk1.5提供的范型反射功能(新加入的java.lang.reflect.Type类型）注定了一种新的ajax－xmlrpc时代的到来
xml结构内部无需维持普通对象类型，burlap内的map:
<map>
<type>org.demo.User</type>
<string>name</string>
<string>alin</string>
</map>
只要结构匹配，没有<type>
也可以转换成下面任一对象：
User {
String name;
}
User2 {
String name;
}
同样，类似的：
<list>
<length>10</length>
<string>alin</string>
</list>
可以转换成List<String>,也可以转换成String[]。

不知道各位看官到此明白了我的意思没有，这样，类似 buffalo的js端rpc到后台spring exporter就可以直接根据rpc方法的范型参数来自动转类型了，
js端只需传结构，无需知道后台任何类名。

参照burlap和buffalo，我已经实现了一个崭新的ajax rpc组件nanhill-sro(simple remote object)
更多信息请参考：
http://spaces.msn.com/bloomsoft/
http://sourceforge.net/projects/nanhillplatform

下面是nanhill-sro一个简单的test case:
[code:1]
public void testWrapDifferObject() throws XmlParseException {
long idCardId = 100001;
String idCardName = "idddddd";
String xml = this.getSroXml(MAP_START + STRING_START + "list"
+ STRING_END + LIST_START + MAP_START + STRING_START + "id"
+ STRING_END + LONG_START + idCardId + LONG_END + STRING_START
+ "name" + STRING_END + STRING_START + idCardName + STRING_END
+ MAP_END + LIST_END + MAP_END);
// --------- test wrap with TestUser -----------
TestUser wrap = new TestUser();
agent.parseXml(wrap, xml);
for (IdentityCard idCard : wrap.getList()) {
assertEquals(idCard.getId(), idCardId);
assertEquals(idCard.getName(), idCardName);
}
// --------- test wrap with TestUser3 -----------
// notice: TestUser3 only the same structure of the sro xml
TestUser3 wrap3 = new TestUser3();
agent.parseXml(wrap3, xml);
for (IdentityCard idCard : wrap3.getList()) {
assertEquals(idCard.getId(), idCardId);
assertEquals(idCard.getName(), idCardName);
}
}
[/code:1]

大家请注意，这个api是把xml数据注入到对象内与它匹配的结构，但是该对象不仅仅只有xml表示的结构。
agent.parseXml(wrap3, xml);
如果不想把xml注入wrap3,可以直接使用
agent.parseXml(xml),这样输出的对象是一个基本对象的集合（map,list,String....),需要手工转型

性能方面还是有很多优化的地方，但是够用，解析上面这样一个小对象每秒5w次左右。过完年，等代码稳定后再加入reflect cache，就是把处理的object field之类的预先缓存。

基于jdk1.5 reflect，nanhill-sro现在逐渐接近目标

说明,nanhill-sro目前目标是传递数据结构，不是远程对象（所以不考虑引用传递先），只要结构匹配，可以被动被接收方转成任意对象。

下面是一个最新的单元测试，
把同一段sro-xml转成不同对象里的同名属性(属性类型可以不同)

TestUser2里list是对象数组，TestUser3里list是对象链表

[code:1] public void testWrapDifferObject() throws XmlParseException {
long idCardId = 100001;
String idCardName = "idddddd";
String xml = this.getSroXml(MAP_START + STRING_START + "list"
+ STRING_END + LIST_START + SIZE_START + 1 + SIZE_END
+ MAP_START + STRING_START + "id" + STRING_END + LONG_START
+ idCardId + LONG_END + STRING_START + "name" + STRING_END
+ STRING_START + idCardName + STRING_END + MAP_END + LIST_END
+ MAP_END);
// --------- test wrap with TestUser3 -----------
TestUser3 wrap3 = new TestUser3();
agent.parseXml(wrap3, xml);
List<IdentityCard> cardList = wrap3.getList();
assertEquals(1, cardList.size());
for (IdentityCard idCard : cardList) {
assertEquals(idCard.getId(), idCardId);
assertEquals(idCard.getName(), idCardName);
}
// --------- test wrap with TestUser2 -----------
TestUser2 wrap2 = new TestUser2();
agent.parseXml(wrap2, xml);
IdentityCard[] cardArray = wrap2.getList();
assertEquals(1, cardArray.length);
for (IdentityCard card : cardArray) {
assertEquals(card.getId(), idCardId);
assertEquals(card.getName(), idCardName);
}
}[/code:1]
[code:1]public class TestUser2 {

private IdentityCard[] list;

public IdentityCard[] getList() {
return list;
}

public void setList(IdentityCard[] list) {
this.list = list;
}



}[/code:1]
[code:1]public class TestUser3 {

private List<IdentityCard> list;

public List<IdentityCard> getList() {
return list;
}

public void setList(List<IdentityCard> list) {
this.list = list;
}



}[/code:1]

js端 (修改buffalo.js)
[code:1]
var sro = new Sro("retrieveObj.do");

function getParam() {
var user = new User;
user.username = "alin";
user.password = "143df859fd84";
var userArray = [user, user];
var intArray = [[1, 2, 3, 4], [2, 3, 4, 5]];
var strArray = ["hangzhou", "shanghai"];
return [intArray, strArray, userArray];
}

function testReceiveDifferObj() {
sro.remoteCall("receiveDifferObj",getParam(), function(reply) {
var rs = reply.getResult();
alert("all item len: " + rs);
});
}

function testReceiveDifferObj2() {
sro.remoteCall("receiveDifferObj2",getParam(), function(reply) {
var rs = reply.getResult();
alert("sum all item: " + rs);
});
}

function testReceiveDifferObj3() {
sro.remoteCall("receiveDifferObj3",getParam(), function(reply) {
var rs = reply.getResult();
alert("sum all item: " + rs);
});
}
[/code:1]

remote service
[code:1]
public int receiveDifferObj(int[][] intArray, String[] strArray, User[] user) {
int len = 0;
len += intArray.length * intArray[0].length;
len += strArray.length;
len += user.length;
return len;
}

public int receiveDifferObj2(int[][] intArray, String[] strArray,
List<User> user) {
int len = 0;
len += intArray.length * intArray[0].length;
len += strArray.length;
len += user.size();
return len;
}

public int receiveDifferObj3(int[][] intArray, String[] strArray,
List user) {
int len = 0;
len += intArray.length * intArray[0].length;
len += strArray.length;
len += user.size();
return len;
}
[/code:1]

That's all!!! js端不传任何对象类型，后台自动转

我不大熟悉 burlap 协议，不过如果建造基于 RPC 的应用的话，个人比较倾向于使用 JSON-RPC。因为 JSON 对于 JavaScript 来说更加自然，JavaScript 解释器本身就包含对于 JSON 的原生支持（native support），解析的效率相信会比解析 XML DOM 更高一些。

js端的性能不是本贴的目的


主要是第3楼
我的代码(nanhill-sro)可以在后台自动转method parameters类型

基本上这类东西对于我来说差别都不大，如果今天 Michael 跟我关系不错，我就使用 buffalo，明天 Michael 跟我关系崩了，我就使用 JSON-RPC。
RPC 的开发方式使用的时候需要特别当心，滥用 RPC 调用甚至误以为其与本地调用一样简单所导致的恶果早已经在对 EJB 的口诛笔伐中被讨论过无数次了。

基本上我的看法就是：想在这个狭小的领域玩出很多花活，价值不大。还是多关注一下 UI 和 usability 吧。

对,协议只是小功能.我的代码也不大更新了,有时debug下

ajax ui得另开贴了


1.是全dom对象(qooxdoo) + 后台生成(echo2)

2.在html上加widget(dojo)

提一个问题：

你使用了JDK5.0的语法特性，那么虽然调用的时候简化了类型指定，但是就无法在JDK1.4.2以下版本运行了，是吗？

对的,1.4没法区分

目前在嫖dwr的java 2 js ing...