The fundamental problem of RPC, which is trying to make remote calls look local, is based on essentially trying to ignore the problems covered by the fallacies or trying to pretend they don't even exist



严重同意，理由如下：



Network partitions are real, timeouts are real, remote host and service

crashes are real, the need for piecemeal system upgrade and handling

version differences between systems is real, etc. The distributed

systems programmer *must* deal with these and other issues because

they affect different applications very differently.



这一点非常赞同，也深有同感。在做FileServer的时候所有的节点都是通过RMI进行通讯，最初使用RMI的目的就是

简化网络部分的开发，对于一般的开发人员无须理解RMI，动态代理，只需要像使用本地方法一样就可以访问远程

节点。这种方案确实很好的隐藏了网络细节，使网络对开发人员完全透明，但有个问题始终无法很好的处理：异常。

网络错误是随时都有可能发生的，对于不同的错误需要根据环境和需要做具体的处理，比如，多试几次，尝试下一个

节点，对于无法处理的还可以直接抛出。而这种策略的选择和使用必须由应用逻辑层完成，可是应用层假设是不知道

网络存在的，它甚至无法知道自己调用的方法中哪个是远程调用，哪个是本地调用。这种矛盾从根本上说明了网络的

复杂性和多样性是开发分布式应用的程序员必须面对的，是逃不掉的，要直面这惨淡的人生T_T



下面阐述了使用类型系统的缺陷：

Such systems also have problems with impedance mismatch between the

IDL and whatever languages you're translating it to. If the IDL is

minimal so that it can be used with a wide variety of programming

languages, it means advanced features of well-stocked languages like

Java and C++ can't be used. OTOH if you make the IDL more powerful so

that it's closer to such languages, then translating it to C or other

more basic languages becomes quite difficult.

On top of all that, no matter how you design the IDL type system, all 

the types won't -- indeed, can't -- map cleanly into every desired 

programming language.



类型系统一直都在进化，从弱到强到动态，你相信会有一种类型系统可以和所有

的其他语言进行完美的映射吗？如果真存在，类型系统的进化就毫无意义了。定义

一个新的语言，然后映射到其他语言，最后号称“我是跨语言跨平台的！”，这种

解决问题的方式根本就是有问题的。WSDL使用XML描述，有着更好的可扩展性，只是

酒瓶换新酒，根烂了，再换也没用。



Ultimately, RPC is a leaky abstraction. It can't hide what it tries to

hide, and because of that, it can easily make the overall problem more

difficult to deal with by adding a lot of accidental complexity.



下面对为什么 message queuing system 适合分布式系统做了很好的总结：

Message queuing systems work well because (in no particular

order):



* they don't pretend to be programming language procedure or method

calls, so they avoid the associated impedance mismatch problems

* they don't try to hide distributed systems issues

* coupling is low -- drop a message into a queue here, pick up a

message from a queue there

* queues can be persistent, or more generally, delivery guarantees can

be varied as needed

* asynchrony

* payloads need not conform to some made-up IDL type system

* getting two different messaging systems to interoperate is easier

than getting two different RPC or distributed object systems to

interoperate

   之所以突然要写了，是因为前两天写自然基金的申请，发现许多东西只有写出来了才会有更 深刻的理解，并且写的过程还可以整理思绪，提供了足够的时间给我这样反应迟钝的人思考。而且想想研究生已经一年了，好像什么也没有留下，遇到什么问题还是 google，虽然许多已经见过并且解决了。就因为没有记录下来，没有形成积累白白浪费了许多时间，希望以后能有改观。今天就到这里，先贴个链接：

这段时间一直在修改ECperf，主要心得都是EJB应用方面的，对EJB部署的复杂和调试的痛苦深有感触，其中主要原因可能是我对EJB不太熟悉，没有用EJB开发应用的经验，以下的几点心得在熟手看来可能是理所当然的，但却折磨我了好久。

1．              EJB部署

部署应用实际上就是将应用安装到应用服务器上，按书上部署Hell Word时没有遇到丝毫困难，但在部署ECperf时却冒出了一堆问题。其中困扰我最久的就是EJB互相引用的问题，实际上只需要将所有的引用关系和JNDI名写入sun-ejb-jar.xml就可以了（借助sun的部署工具很容易实现，不同的应用服务器会有不同的文件名如，格式可能也会不同）。在ejb-jar.xml中，每个EJB必须申明自己引用的EJB的类型，home接口，remote接口，和ejb的引用名，引用名不需要与JNDI名相同，在sun-ejb-jar.xml要申明ejb引用名对应的JNDI名。DataSource也需要如此设置，对于env-entry好像不需要在sun-ejb-jar.xml中申明。由此可以看出应用服务器对EJB所能访问的资源做了严格的控制，而ejb不是直接引用JNDI名，也为ejb应用提供了一定的灵活性。

2．              EJB调用

在同一容器调用EJB和远程调用EJB有很大不同。同一容器中调用者与被调用者有相同的Context，因此不需要额外设置，而在远程调用需要指定java.naming.factory.initial和java.naming.provider.url，另外还要部署时产生的client jar。

在调用PortableRemoteObject.narrow()得到home接口时抛出java.lang.ClassCastException

一般将client jar 放到 classpath中就可以解决，这里主要用到的是remote接口和home接口的stub。如果不将client jar 放到classpath中也可以得到home的接口，但由于使用了不同的classload，在用PortableRemoteObject.narrow()进行转型被视为不同的类而转型失败，我在用sun的部署工具得到的 client jar中竟然没有stub（可能是部署文件的问题），所以远程调用始终不成功。

3．              下一步学习的方向

继续研究远程对象是如何返回的

Classload 是如何工作的

JDBC中关于分布式事务的处理方式

容器处理事务的规则