2008年5月28日
多谢 erlang-china 的提醒，今天从 mailing list 中翻出了关于RPC的讨论，深有感触 -- 牛人就是牛人！！！
关于 RPC is bad 的主要论点如下：
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
这和我在自己的硕士论文中的观点有些相似：完全使用消息机制进行构件间的通讯。构件可以
是分布式的或在容器中的，基于消息的通讯都是完全适用的。对于网络应用同样如此。对于流行
的网络协议，HTTP，FTP，LDAP 等等都是消息式的，完全经历了时间的考验。
posted @
2008-05-28 00:32 JBahamut 阅读(44) |
评论 (1) |
编辑 收藏
2007年10月7日
感谢blogjava，大半年没更新了，我的blog竟然还可以登录
发现自己真的是很懒啊，总是没法坚持写些东西，从本质上说我还是个不擅长写作的
程序员，正确的表达自己比写出正确的程序要困难许多，表达出能让别让共鸣的东西
更是难上加难。
但是，文章还是必须要是会写的，牛皮也是必须要会吹的。神啊，请允许我再一次许诺吧，
试着写点东西吧。
posted @
2007-10-07 23:10 JBahamut 阅读(40) |
评论 (2) |
编辑 收藏
2006年12月26日
整理收藏夹竟然发现了自己的blog-_-!!
翻翻发现最新的文章竟然是半年以前了，还号称“不再偷懒了”，实在惭愧啊。项目一忙起来
确实是顾不上了，回来还有看动画片的重任在身自然更是无暇顾及了，说到底自己终久不是
喜欢码字的人。不过翻翻以前写的东西还是蛮有意思的，有些东西回头看看还是很有好处
的，于是决定还是写写吧，哪怕下一次会是半年以后^_^
最近工作搞定了，FileServer也初见成果，正在整理代码，是时候好好整理一下前段时间工作的体会了，第一次组织项目还是有很多感想可写的，请各位看官（如果有的话）敬请期待吧！！！
posted @
2006-12-26 21:29 JBahamut 阅读(44) |
评论 (0) |
编辑 收藏
2006年5月20日
最近一直在准备做File
Server，要支持分布式存储和虚拟文件系统，我还希望能再进一步，加上日志系统。一切都始于我无止境的yy，现在仔细想想，难度真的是挺大的，不知道
我这半瓶酒能不能应付。不过是我负责，终于可以按我的想法组织项目了^_^
作为一次难得的锻炼机会，我准备把整个过程都记录下来，希望能够坚持下来。那就先表个态：
我要写Blog了！！！不能偷懒了！！！！
之所以突然要写了，是因为前两天写自然基金的申请，发现许多东西只有写出来了才会有更
深刻的理解，并且写的过程还可以整理思绪，提供了足够的时间给我这样反应迟钝的人思考。而且想想研究生已经一年了，好像什么也没有留下，遇到什么问题还是
google，虽然许多已经见过并且解决了。就因为没有记录下来，没有形成积累白白浪费了许多时间，希望以后能有改观。今天就到这里，先贴个链接：
http://www.sdsc.edu/srb/index.php/Main_Page
一个分布式存储系统，貌似很不错
ps：竟然不能插入链接，难道是Firefox的问题？
posted @
2006-05-20 01:05 JBahamut 阅读(58) |
评论 (0) |
编辑 收藏
2005年9月9日
序列化是将对象变为连续的字节流，用于对象的持久化，网络传输等场合
一个类希望能被序列化必须实现 Serializable 接口，Serializable 本身并没有声明任何
方法，只是起标记作用。可序列化类的子类自然也是可序列化的。因而实现序列化是非常方
便的，只要在类的声明时添加 implenment Serializable 就可以了，java 虚拟机会帮你处
理剩下的工作。序列化是递归的，一个类想要序列化则它的所有数据成员都必须是可以序列
化的，否则在序列化时会抛出 NotSerializableException 异常。jsdk 中基本数据类型的
封装类（Integer， Float etc），Component 都是可序列化的，如果容器中的对象都是可
序列化的，则容器时可序列化的。java.lang.refect 包中的类不能序列化，Socket,
URLConnection 不能序列化。
对于只实现了 Serializable 接口的类，可以想象 java 是如何将它们序列化的：首先要利
用反射机制得到所有需要序列化的数据成员，包括 private 成员，得到 private 成员的过
程是非常规的，必定要经过严格的权限和安全检查。所以用 java 自己的序列化方式开销是
非常大的，这也是为什么会有这篇文章的原因，这里要讨论 java 提供的可以由我们自己控
制的序列化对象的方式。
覆写
private void writeObject(ObjectOutputStream out)
private void readObject(ObjectInputStream in)
这两个方法会在对象序列化和反序列化时被调用，通过覆写这两个方法我们可以完全控制整
个序列化的过程。我们注意到这两个方法都是 private ，这意味我们无法显示的调用这两
个方法，而 java 虚拟机在调用这两个方法时也必然要经过严格的权限和安全检查。与传统
的序列化方式（只实现 Serializable 接口）相比，这种方法减少了利用反射的次数以及获
取 private 成员所需要的额外开销，因为在这两个方法中所有的数据成员都是可以自由使
用的
实现 Externalizable 接口
该接口中定义了两个方法
public void readExternal(ObjectInput in) throws IOException
public void writeExternal(ObjectOutput out)
throws IOException, ClassNotFoundException
这两个方法会在对象序列化和反序列化时被调用。很明显这两个方法都是 public 的，所以
我们可以显示的将一个对象序列化到一个输出流，而 java 虚拟机在调用这两个方法时也不
会有任何的限制。
ANY-ACCESS_MODIFIER Object writeReplace() throws ObjectStreamException;
ANY-ACCESS_MODIFIER Object readResolve() throws ObjectStreamException;
这两个方法在序列化和反序列化时被调用,可以替换将要写入或读出的对象,在实现Singleton模式
时可能会用到
这三种方法实现序列化效率是显而易见的:传统方式最慢，实现 Externalizable 接口方式
最快。但自己控制序列化过程有个明显的缺点就是当类的数据成员改变时，序列化过程也同
时需要修改，相反这正好是传统方式的优点：任何改动都不会影响对象的正确序列化，虚拟
机会帮你完成一切工作，虽然不算出色。
当我们考虑性能问题时，序列化总应该是我们首先要注意的方面，尤其是那些只实现了
Serializable 接口的类，它们往往就是性能的瓶颈所在，特别是一些对象需要反复的被序
列化和反序列化，实现 Externalizable 接口会给你不小的惊喜。而对于实现
Externalizable 接口后需要保持数据成员和序列化方法一致的问题实际算不上问题，因为
当我们考虑性能问题时应该已经到了编码的最后阶段，这时整体框架和数据结构都已经非常
稳定了，数据成员被修改的可能已经非常低了，即使被修改了，能大幅提高性能，多写两行代
码也不是令人沮丧的事情。
以上只是单纯的讨论序列化的过程，实际上序列化总是和 I/O 操作同时发生，因为序列化
就是为了传输或是存储，所以对 I/O 的优化方法在这里也是同样适用的。
使用ObjectOutputStream.writeObject()时,在流的内部会有一个引用缓存,所有已经写入流的
对象如果再次被写入则直接使用以前引用而不重新传输新的对象,这样可以提到流的效率,但同样带来
问题,一个对象写入流后,被修改,再次写入流,再另一端ObjectInputStream得到的是
两个相同的对象,这一点一定要注意
posted @
2005-09-09 14:07 JBahamut 阅读(186) |
评论 (2) |
编辑 收藏
2005年8月24日
关于 overloading 和 overriding
首先 java 中所有的方法都采用后绑定，就是在运行时绑定（除了被声明为 final 和 static 的）
java通过方法的 signature 来判断一个方法与其他方法的关系，是无关的，overload 或 override
方法的 signature 可以肯定的是方法名和参数。返回值，权限修饰词（public private），final，
static 修饰词的情况有点复杂后面依次讨论。
final && private
被声明为 final 或 private 的方法都是不能被 override 的，一定要注意这是两个语义完全不同的词，
他们除此以外没有任何联系。final 不仅不允许子类 override，并且禁止子类使用名字和参数相同但返回
值不同的方法 overload(如例子中的 functionEight（）），而 private 不同，他对子类是不可见的
你完全可以在子类中定义一个与父类一摸一样的方法（这完全合理）。因此说 private 隐含有 final 的
意思并不准确。 private 就是说 It's mine~~~~~~~~~ 对于类以外，没有人知道它的存在。final
只是说这个方法不想被你覆写。
返回值
返回值不是方法的 signature，当方法名和参数相同时编译器会强制要求返回值必须一致，但子类 override
父类的方法返回值可以不同,同样有一个条件返回值类型之间要有继承关系！！（例子中的
functionTwo() functionThree() functionFour() 很好的演示这种关系）。要 override，
子类的返回值类型必须是父类的返回值类型的子类（有点拗口，看看 fanctionTwo() functionFour
就会明白了），这也应该是我们想要的行为。
public && private && protected
继承时方法的权限可以扩大但不能缩小(public > protected > none > private)(例子
functionSix() and functionSeven())
static
你可以覆写 static 方法，就像 functionFive() 一样，看起来是 override，但实际上 static
方法始终是前绑定，即在编译时绑定的。所有永远不会产生多态的效果，我们还是打消 override
static 方法的念头吧
posted @
2005-08-24 01:17 JBahamut 阅读(93) |
评论 (0) |
编辑 收藏
用 catch 捕获异常后程序会继续执行，如果一个异常被抛出至到被 catch 程序继续执行，
或者被抛出 main，printTrace。程序继续执行的位置是异常被catch的地方。所有初看起来
在catch后的语句和finally里的语句没什么区别，在catch后都会执行。这里要强调的是
finally中的语句是一定会执行的，在下面的几种情况中finally的语句会执行而catch后的
语句不会执行
1.在catch中又抛出异常
2.try，catch，finally在循环中，try块中使用 coninue 或 break
finally是在出现异常后必须要处理的事情，而catch后的语句是认为程序已经从错误中恢复，
在正常状态下继续执行。
在一个 try 块之后可以后多个 catch 块，每块捕获不同的异常。当一个异常被抛出后，安
顺序找到匹配的为止
一个异常可以说明是谁引起了他（cause），可以用构造函数或initCause（Throwable e）
函数来说明。许多异常没有带 Throwable参数的构造函数，但 initCause 一定是可用的
继承于 RuntimeException 的异常是 unchecked，也就是说编译器不会强制程序捕获或向上
抛出异常，这类异常不强制用户处理，（当然你依然可以捕获这类异常，只要你愿意）。
这类异常会一路闯过 main。
复写父类的方法时，你只能抛出那些在父类方法中抛出的异常。这样一来子类方法抛出的异
常只能是父类方法抛出异常的子集。但这个约束对构造函数是无效的。注意：派生类的构造
函数不能捕获任何基类抛出的异常
posted @
2005-08-24 01:15 JBahamut 阅读(88) |
评论 (0) |
编辑 收藏
2005年8月23日
个人心得
这段时间一直在修改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中关于分布式事务的处理方式
容器处理事务的规则
posted @
2005-08-23 23:04 JBahamut 阅读(596) |
评论 (0) |
编辑 收藏