How about a XHTML based UI render engine?

OpenSource是一个热闹、喧嚣的世界，在同一个技术领域，就会有众多的项目来提供各自的解决方案。大浪淘沙，真正成为大家接受的、普遍应用的framework、library或者tools，比例可能就不高了。

在RCP这个领域，普遍接受的一种方式就是采用XML来定义UI，毫无疑问，这种做法将最终成为RCP的主流，采用这种方式的项目或者技术包括：

1. Microsoft. MS的官方技术就是XAML，很有可能成为明天的一个事实标准。
   
2. Mozilla的XUL。是Mozilla的底层基础，也成为很多其它项目的参考。
3. Luxor：以XUL为基础的Java实现。
   
4. SwiXML：XML + Swing，跟Swing结合紧密。
5. JDNC：也提供了基于XML的UI框架。
6. MXML：Macromedia Flex所采用的用来描述基于Flash的UI。

以上可能仅仅是千军万马中的一些领头羊，有的是商业化的产品和成熟的技术，有的则还是OpenSource领域的一些年轻的项目。其它各具特色的类似技术，如果在google上进行搜索，真实数不胜数。
其实，我个人认为，XHTML毫无疑问，应该被包括到这样的一个UI框架中，并且新的框架应该尽可能使XHTML的一个自然扩展。这样考虑的出发点是：

1. XHTML已经是一个非常成熟的技术，具有最多的应用（虽然现在的大部分WEB并不完全是XHTML的，但两者的距离非常小），支持XHTML的话，可以最大限度的服用历史的资源。
2. XHTML作为一个多年发展的技术，在UI上具有相当的表达能力，这些都是目前的这些框架所不具备的。象Bindows这样的框架，居然可以在XHTML的基础之上，render出相当复杂的UI，这也足以说明XHTML的UI表述能力是相当强大的。
3. 现 在的很多XML UI框架更多的是对桌面组件的一个XML化，其基础是一些标准化的UI组件，这些恰恰是XHTML的缺陷，XHTML更多的偏重于文档式的界面，在交互能 力上存在不足。但这两者恰恰是互补的，缺一不可。像SwiXML这样的XML要表述XHTML的UI能力，是相当费劲的。
   
4. XHTML提供的布局和排版能力，远远的超过了Swing中的Layout，而且要简单很多。同样的功能，在Swing中对应无数的LayoutManager，但都没有达到XHTML的表达能力和简单程度。

实际上，XML的namespace能力实际上提供了一种在XHTML的基础上进行扩展的能力，而且在现有的很多产品中已经应用了这种技术，例如， Microsoft就充许在IE中浏览VML，而且VML可以集成在HTML中。Mozilla也有对SVG的支持插件。这给我们提供了一种新的思路，在 设计这些新的UI框架时，我们是否可以基于XHTML，并进行相应的扩展呢？

1. 利用XHTML作为类似HTML的表述语言，支持HTML，CSS等，支持DOM和脚本访问。
2. 使用SVG作为Graph的表述语言。
3. 可以集成一个标准的桌面组件的命名空间，例如：XUL
4. 在此基础上，定义一个扩展的框架，支持扩展的XML命名空间，各自满足不同的需要。可以根据需要来进行用户自己的扩展。

我想，如果有了这样的一套XML UI render的框架，或许在一定的程度上可以实现对UI的统一，到达一个新的高度。

学习CSS

在WEB的世界中，CSS的地位可谓是最为核心的技术了。无论是在HTML中，还是在XML中，CSS的地位都相当的高。
下一个学习的任务是，好好的学习一下CSS。理解之。

主要的资源：
http://www.mozilla.org/docs/web-developer/
http://www.w3.org/TR/REC-CSS1
http://www.w3.org/TR/REC-CSS2 更为复杂、全面
http://www.richinstyle.com/guides/css2.html 一些指导
http://www.mozilla.org/xpfe/ XUL的一些文档

看来了解CSS2，对WEB上的界面就可以得心应手了。

http://www.mozilla.org/newlayout/xml/xml-devcon/slides/slide9.xml 等网页提供了一些XML+CSS+javascript的例子，可以通过DOM查看器来帮助进行调试工作。

How a C++ compiler implements exception handling

好文章：介绍C++编译器是如何实现异常的。
本地

有时间的话，我应该也研究一下GCC是如何实现异常管理的，Hotspot是如何实现异常处理的？这些底层的技术确实是很有魅力的。

关键词：
SEH：Structure Exception Handle
Functions/Stack Struture, Calling convention, Caller, Callee
C++ Exception

Function's prologue creates EXCEPTION_REGISTRATION structure on its stack frame and registers it with the operating system. The epilogue restores the EXCEPTION_REGISTRATION of the caller.

When VC++ compiles a function, it generates two set of data for the function:

a) Exception callback function.
b) A data structure that contains important information about the function like the catch blocks, their addresses, the type of exception they are interested in catching etc.

在C++异常处理过程中，需要

1. Unwind stack including destroy local objects

又一个测试框架： TestNG

TestNG is a testing framework inspired from JUnit and NUnit but introducing some new functionalities that make it more powerful and easier to use, such as:

• JSR 175 Annotations (JDK 1.4 is also supported with JavaDoc annotations).
• Flexible test configuration.
• Default JDK functions for runtime and logging (no dependencies).
• Powerful execution model (no more TestSuite).

在 http://beust.com/testng/main.htm 上可以看到相关的信息。

核心的annotation：

public @interface Configuration {

public boolean beforeTestClass() default false;

public boolean afterTestClass() default false;

public boolean beforeTestMethod() default false;

public boolean afterTestMethod() default false;

public String[] parameters() default {};

public boolean enabled() default true;

public String[] groups() default {};

public String[] dependsOnGroups() default {};

public String[] dependsOnMethods() default {};

}

public @interface Test {

public String[] groups() default {};

public boolean enabled() default true;

public String[] parameters() default {};

public String[] dependsOnGroups() default {};

public String[] dependsOnMethods() default {};

public long timeOut() default 0;

public int invocationCount() default 1;

public int successPercentage() default 100;

}

就我个人而言，我对junit的模式已经相对习惯，因此，这里就对junit与testng的一些特性进行比较：

TestNG	Junit	比较
Unit test的代码使用annotation标注，因此，可以在任何类、方法中编写测试代码，只需要使用annotation标注即可。	从TestCase继承的子类，并使用setUp/tierDown，testXXXX的命名模式。	虽然TestNG的更为灵活，不够，从项目管理的角度上来看，Junit的做法可能更加有效。
支持测试的倚赖关系。当进行一个测试时，需要首先进行其它的测试（一个方法或者一个组）	不支持	*** 避免进行一些不必要的测试。能够缩短测试的时间。
beforeTestClass	与TestCase的构造方法相似	*
afterTestClass	没有对应的功能	*
beforeTestMethod	setUp
afterTestMethod	tierDown
测试分组，使用group来定义	没有这个概念，但可以把一个TestCase作为一个组	*
支持Parameter，这样可以在测试的配置文件中配置测试的参数	不支持	***

从我的角度上来上，由于JUnit确实是足够的简单的了，几乎没有干任何多余的事情，因此，我更倾向于对Junit进行一定的增强。不如说：

1、在JUnit上增加annotatation来描述测试的元信息，提供对测试内容的文档话表述，这样可以产生更好的测试结果、报表。

2、利用annotation来增强测试之间的依赖关系。可以依赖一个方法或者一个test suite。

3、可以通过annotation/factory的方式来增强测试的方法，比如说对超时时间的测试、对执行效率的测试。

或许通过对Junit的增强来得更为容易，一来开发人员学习周期更短，二来可以重用的东西更多，包括eclipse等插件、ant工具以及相应的测试报告工具等。

基于interface的设计与基于POJO的设计

基于接口的设计作为一种好的设计模式，已经被广泛的获得认同。采用接口，我们可以更好的支持契约式的开发模式（虽然接口本身还缺乏一种良好的契约的描述能 力，更多的Contract实际上是通过文档、注释、或者设计模式的方式来进行补充），从而实现调用者和实现者之间的隔离。基于接口的设计对于OCP等原 则而言，也是一个必然的手段。

在Java的世界中，有很多的设计都是深度的应用了基于interface的设计的，比如：

1. JDBC API：API采用interface的方式，从Connection/DataSource出发，漫延到Statement, PreparedStatement,CallableStatemen,ResultSet,Metadata等等。不同的JDBC驱动程序可以提供不 同的实现，并通过工厂的模式进行选择。
2. JNDI API。于JDBC类似，实现的方式也非常的多，各有各的特色。比如说可以使用LDAP，Database，甚至把文件系统映射成为Context。可以集群，分布。想怎么复杂都可以，并一度成为J2EE的核心支柱。
3. DOM API。一个更为复杂的API，接口非常的多。完整的对XML进行了映射。

毫无疑问，基于接口的设计在很多的方面是取得了巨大的成功地，并且提供了一个完整的、优美的、高效率的解决方案。但是，也会有一些场合，会感觉到过渡的基于接口设计，可能带来的是一种滥用，导致更为复杂、更为低效。因此，在最近的一些技术中，开始对这个问题进行反思：

1. JDOM 是一个对DOM的反思，与DOM的基于接口的思维模式不同，JDOM直接把XML映射到一个POJO的模型中，包括Element, Attribute的类模型，不再使用复杂的工厂模式来创建对象，管理对象之间的复杂关系，反之，可以直接的、简单的创建、修改这些对象。当然JDOM能 够这样做，在一定程度上与其背景有关，DOM试图为跨语言、跨平台（基于Corba的思维模式）提供一个统一的API，而JDOM则更为自然的为Java 服务，更少包袱。JDOM被认为比DOM更简单、高效。（可惜，直到今天，JDOM仍然是JavaAPI中的一个二等公民，地位一直在DOM之下）。
2. JDBC与ADO相比，一直定位在一个更低的层次上，因此，在易用性一直存在不够，而ADO则通过Table/Row/Column的对象模型，支持一个相对简洁的开发模型。毫无疑问，在这里Table/Row/Column的对象模型具有POJO的很多性质。

一个低水平的设计人员会很少的考虑使用接口，什么东西都放到类中去完成（这也是一种典型的过程化思维模式），而一个高水平的设计人员则会充分的考虑如何使 用接口（对于我个人而言，我的接口的喜好胜过抽象类或者类的继承），但如果能够回归到改用POJO，就用POJO的时代，或许才是设计水平的进一步提升。

或如武侠文化中：手中有剑，心中无剑，乃习武第一层次。手中有剑，心中有剑，乃第二层次，手中无剑，心中有剑，可谓武林侠士了，但若为一代武林宗师，当进化到手中无剑，心中亦无剑阿。其实，程序如江湖。

使用 OSGi 作为插件化平台

OSGi(The Open Services Gateway Initiative)是一个开放的框架标准，OSGi定义了一个开放的、普适的标准和平台，为服务提供者、开发人员、软件供应商、最终用户提供一个开发、部署、管理服务的统一的标准。

在OSGi中，最重要的概念是Bundle和Service，一个Bundle就是一个独立部署的单元，任何符合OSGi规范的Bundle可以发布到OSGi框架之上，并实现与其他Bundle的协作和共处。基于OSGi规范，我们的产品开发可以按照其依赖性、功能分布来组织成为多个不同的Bundle，各个Bundle相对独立，可以独立的进行软件的分析、设计、开发、测试，并最终发布到一个统一的框架平台之上。

一个OSGi中的Bundle与下面的概念具有相似性：

l Eclipse中的Plugin。（实际上，eclipse 3中的插件其本身就是一个OSGi Bundle）

l Netbeans中的Module。

在OSGi中，Service是一个良好定义的服务，一个Service包括接口定义（一般的，是一个Java接口），接口的实现（Implementation），在一个Bundle中可以提供1个或多个的服务，也可以使用由其他Bundle提供的服务，OSGi提供了一种注册、发现服务的统一的框架和机制。同时，OSGi也预定义了一些通用的、标准化的服务，包括Preference服务、Package Admin服务、Log服务等，OSGi的Bundle可以使用这些标准的服务。

1.1. OSGi的特点

以下是使用OSGi框架的一些特性和优点：

1、 OSGi是一个开放的标准，已有非常多的厂商对其进行支持。在www.osgi.org上可以获得丰富的文档和帮助。

2、 OSGi框架已经具有open source的实现，oscar(oscar.objectweb.org)就是一个稳定的、opensource的OSGi实现。我们可以直接使用。

3、 OSGi标准已经成熟，并且有可用的opensource实现，我们可以马上在此基础上开展工作。部分通用的Bundle可以马上开始进行开发。

4、 各个Bundle可以独立的规划、分析、设计、开发、测试，并且可以相对灵活的组合称为一个新的产品，这可以支持我们并行的进行多个功能的开发，并尽可能的避免各个子团队之间的依赖性。

5、 各个Bundle可以发布在我们的网站上，用户可以直接升级下载新的Bundle，使用产品提供的新的功能。可以解决我们现在的升级模式。在一个客户处发现的BUG，我们在修改该BUG后，只需发布该Bundle的一个新版本，让客户直接下载（或者自动升级）即可。

6、 在企业应用中，我们可以把Bundle部署在服务器上，前端应用只需要安装好JVM、及oscar等基础平台（约400K）后，从服务器上下载所有的Bundle到本地运行，从而也免除了桌面端的安装、升级的烦扰。

7、 OSGi可以同时作为我们桌面端、Server端的框架，便于我们内部的开发技术统一。很多的Bundle可以直接在Server/Client中共享。从而使得我们在产品开发中可以更一致的进行功能的分解，重用代码。

在Jcom中增加对COM错误信息的支持

在我们的一个项目中，使用了jcom来访问com，jcom可以从http://www.sourceforge.net/projects/jcom中获得，对基于IDispatch的开发提供了较好的支持。

美中不足的是，jcom中没有将com的异常信息完整的抛出到java中，这在java开发时会感觉到很不方便，无法快捷的进行错误的定位。由于是opensource的软件，因此，很容易自己加入这样的一个特性。

原来以为是很简单的事情，但还是搞了好几个小时，主要是对COM的BSTR等数据类型的处理比较生疏，而JNI方法：ThrowException (env, jclassid, char *message）则要求传入的是一个UTF8的字符串，因此，在这里的处理显得比较陌生，但最后还是成功的解决了。

// message 是原来的错误信息，不包括exception等信息
char * tmp_p = message + strlen(message);

// BSTR bstrSource;
//BSTR bstrDescription;

// excepInfo 现在已经作为一个全局的变量，在InvokeHelper中会进行设置。
_bstr_t bstrSource = excepInfo.bstrSource;
_bstr_t bstrDescription = excepInfo.bstrDescription;

_bstr_t msg = message;
msg = msg + excepInfo.bstrSource;
msg = msg + excepInfo.bstrDescription;

// 我们通过BSTR2jstring首先把msg转变成java字符串，然后再转变为UTF8
jstring jsMsg = BSTR2jstring(env, msg);
const char *utf8 = env->GetStringUTFChars(jsMsg, NULL);

//sprintf(tmp_p, " Source=%s Description=%s", (char*)bstrSource2, (char*)bstrDescription2);

jclass clsJComException = env->FindClass(CLASS_JCOM_EXCEPTION);
env->ThrowNew(clsJComException, utf8);

// 记得要释放资源。
env->ReleaseStringUTFChars(jsMsg, utf8);

return NULL;

JavaVM问题列表

1. 在JVM中，Java对象的内存布局如何？在该种内存布局下，对字段、方法的访问机制如何？
   
2. 异常处理是如何实现的？Java异常与底层异常（例如空指针错误、数租越界、除0等）怎么结合？因为这些顶层错误是由CPU产生的。
   
3. 线程同步是怎么实现的？
   
4. 垃圾回收的基本算法？如何实现不停止应用程序来完成垃圾回收？
   
5. JIT是如何工作的？
   
6. 主要的优化机制有哪一些？他们是如何工作的？

这些问题，需要通过对JVM源代码进行分析后逐一进行处理。为此，我想开辟一个一个专门的Category：JVM来记录我对Hotspot虚拟机的分析文稿。

build hotspot

可恶，这个帖子原来是在jroller上的，中文变成这个样子了。

1. ???? j2sdk-1_4_2-src-scsl.zip???Linux??????
   
2. cd $ROOT/build/linux
   
3. make product ??????build/linux/linux_i486_compiler2/product/???????libjvm.so??
   
4. make debug ??????build/linux/linux_i486_compiler2/debug/???????libjvm_g.so??
   
5. ??$JRE_HOME/lib/i386/jvm.cfg?????????? product/debug
   
6. ??product????java -product Demo?????
   
7. ??debug????java -debug Demo???????????????????????????????????????????????????????i386?????????????????_g????????????????for file in *.so; do ln $file `echo $file|sed -e 's/\.so/_g.so/'`; done?
   
8. ???????????????java???????????
   $J2SE/share/src/bin/java.c $J2SE/src/java.h
   $J2SE/solaris/src/bin/java_md.c
   ????? gcc -g -DDEBUG -Di586 -D_GNU_SOURCE -o java_g java.c java_md.c -ldl
   ?????java_g???$JAVA_HOME/bin??
   
9. ??java_g -debug Demo????
   # To suppress the following error report, specify this argument
   # after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux.cpp:1346
   #
   # HotSpot Virtual Machine Error, assertion failure
   # Please report this error at
   # http://java.sun.com/cgi-bin/bugreport.cgi
   #
   # Java VM: Java HotSpot(TM) Server VM (1.4.1-internal-debug mixed mode)
   #
   # assert(sigismember(&act.sa_mask, 32), "incompatible pthread library")
   #
   # Error ID: /home/wangzx/j2se-src/j2se/hotspot/src/os/linux/vm/os_linux.cpp, 1346
   #
   
10. ??java_g -debug -XX:SuppressErrorAt=/os_linux.cpp:1346 Demo???????????????????????product??????assert??????????????????????????????.hotspotrc??????????????java_g -debug Demo????????
    
11. ????GDB????????????gdb????????????

XML based objdump

The linux tool: objdump is a useful tool to dump binary file in specical format such as ELF, COFF, but the usage is not as good as expect. Here is a idea of a new implementation of the objdump tool

• This tool provide a plugable framework for multi binary format, eg, the Java Class file, the OLE2 document, the Flash format etc.


• The binary format is transferred to an XML format which can understand by the framework. It is the response that the binary plugin transfer from the binary to XML


• The framework provide both a GUI and a CLI(Command Line Interface) utility, the GUI version can navigate the binary interactive, the CLI access XML filter to output special information.


• the CLI utility may use a script language as the interview language, such as javascript.

The tool is useful only for low-level research.

JavaVM阅读

这个函数比较关键，是一个对ClassFile进行分析处理，并生成一个java.lang.Class对象

File: share/vm/runtime/classFileParser.cpp Line 1023 - 1434

Compile Hotspot JVM

File share/vm/opto/Compile 文件是进行本地编译的文件。

About GC: Scan Memory

在JVM的GC处理中，经常需要的一个操作是：遍历整个对象堆，查找堆中是否存在对某个对象的引用。

假设我们一次对一块64K大小的对象区域进行GC，而整个堆的大小为100M，我们首先要遍历100M内存，看看是否有可能的指针指向了这64K内存。

for(int *start = (int*)current; start < (int*)end; start++){

int value = *start;
if(value & 0xFFFF0000 == base){
match((int)start);
}

}

这个测试程序从current到end一共是100M的内存，使用 gcc -O3编译选项，运行时间大约为0.10s。

这个时间是一个很关键的，如果不在算法上进行大的改进，那么这个时间将是一个不可压缩的时间。
====== 说老实话，我做这个测试的时候对GC的了解确实比较一般，实际上，现有的GC在进行full gc时，对于100M的对象区，其数量级往往是超过1s的。说明算法的复杂度确实很高的了。

java.c阅读

java.c是编译java或者其他的命令，如javac，javap等的程序，其基本的处理是：根据命令行参数，加载适合的Java虚拟机，并调用该虚拟机的方法，执行制定的类。由于java.c只是JVM的一个启动包装，因此，其代码比较简单。

1、java.c包含了与平台无关的代码，而java_md.c则包含与平台相关的代码，在不同的平台上，对JVM安装的目录、虚拟机的文件结构均略有不同，这些代码就包存在java_md.c中。

在 函数LoadJavaVM中，首先要查找到JVM所在的位置，该虚拟机的名称在Linux上为libjvm.so，在Windows下为 libjvm.dll，在Linux上，使用dlopen装入该动态连接库，然后使用dlsym定为两个函数：JNI_CreateJavaVM, JNI_GetDefaultJavaVMInitArgs，然后调用JNI_CreateJavaVM就可以创建JVM了。

jint JNI_CreateJavaVM(JavaVM **pvm, JNIEnv **env, void *args)
其中JavaVM用于返回创建的JavaVM（在jni.h中定义，包含了几个JavaVM的输出方法），env用于返回JNIEnv结构，该结构包含了众多的jni方法，在后续的处理过程中，可以在C中直接调用jni方法。

在JVM 初始化完成后，通过env->FindClass方法，将要运行的类装入进来。使用env- >GetStaticMethodID方法获得main方法的句柄，然后通过env-& gt;CallStaticVoidMethod来执行main方法。

因此，要进一步的对JVM进行分析，首先要：

• 了解 JNI_CreateJavaVM是如何初始化JVM的


• JNI方法FindClass将负责装载一个类，其中涉及了类的装载的过程。


• JNI方法CallStaticVoidMethod方法，该方法涉及到Java代码的执行。

About GC

这里是我对JVM GC的一个想法：

线程在分配对象时，首先为每个线程提供一个Local的对象分配堆，其大小可以设为4K-32K，由于分配对象首先在线程局部进行，因此，对象分配的操作不需要进行线程间同步，其速度会比从全局堆中分配要快速得多。

当线程局部堆使用完毕后（这个会比较经常的出现，因为线程局部堆较小），对此堆进行垃圾回收。

在 这里我们使用模拟的引用计数法来记录全部堆中对象对局部堆中对象的引用，在putfield/putstatic指令执行时，检查是否把局部堆对象的指针 存储在全局堆下，如果是，则在对象的头中设置标志：本对象已被全局堆中对象引用。（这样做的话，putfield指令速度将会变慢，不够，我估计：该影响 是有限的）

对局部对进行垃圾回收时，仅需要检查线程的局部root（线成堆栈、寄存器），将所有的如下对象视为垃圾：

1. 将所有的从root引用到的对象复制到全局堆中


2. 将所有的被全局堆引用的对象复制到全局堆中


3. 将这些对象所引用到的局部堆中的对象复制到全局堆中


4. 所有其它剩下的对象是垃圾


5. 遍历全局堆，更新所有对局部对象的引用，使其指相新的地址。

在这个垃圾回收过程中，其它的线程基本上不需要进行停顿，除非他们要访问此局部堆中的对象，此时，如何处理呢？

Define a subset of java that can be compiled to native code without JVM

When i read the source code of IBM RVM, I realy think it maybe the next choose of implement a JVM with purely Java itself. Like a Smalltalk VM is coded with Smalltalk itself. Coding a JVM using Java will makes many benifit.

However, I think it is necessary to define a Subset language of Java which can be compiled to native code without JVM support, the language share the same grammer with java, but with a more constrict. Let us naming it as "rawj" which means it is raw without JVM support.

A rawj program can be compiled to native code, so it share the low-level memory mode, just like C. a rawj program maybe compiled to a DLL/SharedObject.

without a JVM, all service from JVM is not support,

javascript的一些想法

象www.smartclient.com 这样的基于JavaScript的GUI组件，有一个问题就是JavaScript下载的尺寸非常的大，我觉得可能有一个比较适合的办法就是：

对每一个JavaScript方法，可以在服务器上建立她的唯一版本，而在客户端则使用代理的方式，即可以使用一个Stub来替代这个方法，这个Stub的唯一职责就是从服务器上下载真实的版本，然后执行她。

采用这种方式时，对于一些暂时不使用的方法，完全可以推迟下载时间，我们也可以对一个应用程序进行模拟运行，对那些每使用到的方法进行统计，让这些方法滞后下载。

这 个方式可以与我构想的Java2Javascript思想结合起来，就是说，Javascript代码实际上时使用Java开发的，通过一个工具将 Java编译成为等效的Javascript，从而充分利用Java的开发特点。在这种下载模式下，如果客户使用的IE浏览器，则用户可以只下载IE的版 本，而如果是Mozilla浏览器，则下载Mozilla的版本。

Ideas about Rich Client Platform

What is Rich Client Platform? There is a lot of products which focus on this idea, such as Micromedia's Flex, Bindows, MS XAML, and new eclipse platform. etc.

For me, a RCP should be:

• Rich UI. the HTML is not rich UI, but the DHTML is rich, but still not enough. There is no enough till the RCP support extensible UI.
  
• Simplest and suitable for movable via internet. Not all functions packed to a box and which will install first, but the functions is seperate into a lot of little box, and each box can be download when in need. Like web pages but not the same.(a box may be complex that an simple page, and can process more process local)
  
• Can used as desktop application and internet application, in more, an RCP should bring them as one thing. no Desktop/Web application futher more

the RCP should be popular in SOA time, i think the general architecture would be:

• An low level Rich Client Presentation Framework. both the SWT/Swing/Windows.Forms can be used. I like Swing better because it is the realy cross-platform framework and suitable for internet usage. the framework support presentation with a unify component model, lets name it as RCC(Rich Client Components), a RCC maybe simple UI component, or complex UI component, or other not-UI components as well.
  
• An high level Rich Client Presentation Framework which provides a unified ui-layout, such as eclipse's persestre/view/preference and others. That is required for manage complex application. the eclipse's layout is a good choice.
  
• An Rich Client Browser(RCB) which able to execute an rich client application, just like a browser can execute a html page. also, the browser can provide download-on-need, local-cache, local-storage management services for RichClientUnit(RCU)
  
• to run a RCU, pass its URL to RCB, the RCB will download it if neccessary(include first time installation, each time initialization, or destroy/uninstall operation)
  
• a RCU may contains one or more RCC, in eclipse-like platform, it may include Perspertive, View, Editor, like a plugin. when the RCB execute it, the main view is displayed and the since now, the RCU can process user interactive.
  
• RCU may use a lot of RCC, each RCC is identified with its namespace, and maybe download and shared for other RCU. the framework provide a rich set of basic RCC.
  
• The RCU general access resource on server, but it can have local storage for temp usage. When the RCU need to access server resource or service, it general using the SOA architechure, such as SOAP/WebService and others.
  
• A good way to code the RCU is using XML file, an RCC can also be XML, the process logic can be script(such as javascript) or native code(such as java/c#) which bind with the RCU. the script can using service provide by RCB(such as SOAP/HTTP), or using other RCC(which can be download).

Bind E4X + JSON + AJAX

最近的IT，新技术是一茬接一茬，单这几个名次，就够完的了：

E4X：EcmaScript for XML，在javascript语言中直接支持对XML的处理，包括内置的XML数据类型，XML语法支持，XML从此可以成为javascript中的 一等公民。个人的感觉是，象原来的XSLT技术，在E4X中或许就很简单了，不再需要一个新的语法，javascript已经够强大了。XML的数据表示 能力又足够的强大，E4X作为一种新的脚本语言，力量不可忽视。

JSON：Javascript Object Notation，一个基于Javscript语言的对象定义子集，采用javascript的简介的语法，提供了类似于XML的数据描述能力。JSON 的优点就是既具备XML的强大描述能力（当然只是XML的一个子集），但又提供了非常良好的javascript处理能力（相比使用Javascript 来处理XML，要简单很多），而且，因为非常简单，在java等语言中进行支持也非常的简单。不够我个人认为，把JSON作为XML的一种 javscript映射机制，可能更为有用。在java等语言端，直接处理XML使得这个世界更为简单。或许在E4X环境中，JSON的使用相对有限很 多。

AJAX：Asynchronized Javascript + CSS + HTML + XML and etc. 这个技术其实目前已经在google的一些项目中获得了应用，不再像传统的WEB应用那样，需要进行页面的刷新就可以实现本地的交互，给用户的总体感觉有 很大的提高。像Bindows这样的项目更是把这样的技术发挥到了极致，WEB应用就像传统的VB应用似的，无论是从用户的角度上来看，还是从变成人员的 角度上来看。都采用相同的用户界面，相似的组件模型，相似的事件驱动机制。

实际上，现在又越来越多的基于javascript的复杂应 用，前一段时间，我参加了oracle的BPEL培训，很神奇的是，oracle的bpel编 辑器，虽然是一个eclipse的插件，但居然是使用IE+javascript开发的，（不知道java的部分代码有多少，反正核心是基于 javascript的，run在IE上）。可惜的是，程序的鲁棒性还是一般，总是会有莫名其妙的错误。哎，不管怎么样，这样的一种开发方式，确是让人惊 诧的。

像DHTML这样的复杂应用，确实是让人又爱又恨的，爱的是，这种软件最为Open，想怎么改，就怎么改，DIYS，给了技术人员 最大的发挥。恨的是，复 杂性确实很高啊，虽然每个地方都很简单，但放在一起就复杂了。而像Java这样的东东，虽然每一个地方相对要复杂一些，但构造大的软件却有很大的优势，尤 其是强类型带来的整个软件的较强的吻合，不是很容易拆拆卸卸，但也不太容易出错。

或许，我们需要在Java及JavaScript这样的语言中达到一定的平衡，把应该让Java来干的事情让Java来干，把适合于Javascript的任务交给js来干，广泛的使用XML作为复杂的数据表示语言，来作为Java/Javascript世界的数据总线。

比方说：
1、Java提供核心的组件，服务，以及提供一个支持的框架，作为整个应用的底层框架支持，和核心逻辑处理。
2、Javascript用来开发基于组件的应用，充分利用javascript的动态处理能力以及带来的简洁性。
3、使用XML来作为描述性的基础，把抽象好的处理逻辑数据化。包括用户界面、交换的数据等。
4、 使用XML Schema来作为XML的强类型语言，用于约束、验证XML数据，在Java端，采用JAXB2技术来进行XML-Java的绑定，以支持Java对 XML的自然处理（强类型处理），在js层，采用E4X技术来直接处理XML。或者也建立类似的把XML直接映射到JS对象的机制。
5、通过一些机制来提高js代码的鲁棒性和可重构能力。包括单元测试、覆盖测试（利用工具自动）、可重构的支持框架等。这一块，我的考虑不是很多。
6、我原来构想的JS2JS（JavaSource 2 Javascript)应该是一个很好的想法，就是把java代码翻译成为javascript，这样，可以充分的利用java的建模优势，来开发大部分的的javascript代码，利用java的强类型机制。

或许，更重要的是，我们需要设计一个杀手级的应用，来演示这种javascript与java结合的应用开发模式，发现更多的问题，然后再提升到一个更高的台阶。

测试

这是我第一次使用www.blogger.com，以前也试过一些别的Blogger，但由于都存在中文的问题，使用得很不爽。不知道www.blogger.com的中文支持得怎么样？如果不错的话，嘿嘿，我就选择它了。

感觉还不错，至少速度还马马虎虎，中文支持没有乱码。