BlogJava-Vikings-文章分类-frame-work

Tapestry 4.0 beta 新特性4-7

Vikings — Tue, 08 Nov 2005 10:00:00 GMT

Tapestry4新特性(四)-源代码标注的异常处理

Tapestry本来提供的debug功能就十分强大，4.0版本中提供了更加详细的报错机制，可以显示错误的代码，并在报错的地方加亮标注，具体截图请看附件(谁能告诉我怎么将多余的照片删除呀)

Tapestry4新特性(五)-Friendly URLs

Tapestry4.0以前版本中的URL一直被人所诟病，当然现在已经有很多的解决方
案，4.0版本中已经对此做了改进，
因为现在的版本需要通过hivemind来配置，所以需要设置hivemind.xml中的一些属
性，具体配置如下：

stateful-extension="sdirect"/>

同时web.xml中加入映射：

tapestry4

org.apache.tapestry.ApplicationServlet

tapestry4

*.html

tapestry4

*.direct

tapestry4

*.sdirect

tapestry4

/assets/*

tapestry4

*.svc

如果希望首页的调用不是通过/app来映射，可以在web.xml中更改redirect：

redirect

org.apache.tapestry.RedirectFilter

redirect-path

/Home.html

这样键入http://localhost:8080/tapestry4，系统导航到http://localhost:
8080/tapestry4/Home.html,
添加一个Page页面例如Test.page，在Home.html中加入jwcid="@PageLink" page="Test">test，
在生成的Home.html中生成的test的链接地址为：http://localhost:
8080/tapestry4/Test.html

Tapestry4新特性(六)-自动定位页面类文件

关于此特性的介绍请参考：http://jakarta.apache.org/tapestry/current/UsersGuide/page-class.html 说明：
通俗点说就是您可以不定义.page文件或者定义的.page文件中不指定class 属性，而让服务器自动根据.html文件的路径来寻找对应的类文件。 配置：
在.application的定义文件中添加：这样如果在文档根目录下有个Home.html文件，你就可以将Home.java放到 org.edynasty.pages(实际开发中配置为您自己的包名)包中，tapestry自动根据 Home.hmtl构造org.edynasty.pages.Home来定位页面的类文件,当然您也可以在WEB -INF目录下放一个Home.page,不需要定义class属性，tapestry自动按照上边的原理定位。 效果：
这样您可以不需要维护.page中的class属性，直接根据.html文件来写对应的类文件。而且可以根据业务逻辑来定义目录结构，例如将 org.edynasty.pages.user定义为user相关的类，.html也就可以放到user目录下边，目录结构如下： user/ListUsers.html user/EditUser.html course/ListCourses.html course/EditCourses.html Home.html

Tapestry4新特性(七)-Application和Session范围对象的使用

Application和Session范围对象的使用

关于此特性的介绍请参考：http://jakarta.apache.org/tapestry/UsersGuide/state.html
说明：
Application和Session范围的概念就不说了，T4以前的版本只可以分别指定一个对象，
以前版本的定义如下:

,
T4中可以指定任意多的对象，而且默认的visit和global仍然可以使用。

配置：在hivemodule.xml的定义文件中添加：

两个user分别对应Application和Session范围，在需要使用user的page中注入：

，通过
getter和setter方法调用。

效果：怎么说呢，可以不需要在一个visit中定义N多属性，因为Session的创建需要资源，
只要操作一个visit的属性，就需要创建整个visit，分别定义之后，可以在需要存取时分别创建。

Vikings 2005-11-08 18:00 发表评论

TapeStry 4.0 beta 新特性 1-3

Vikings — Tue, 08 Nov 2005 09:55:00 GMT

[原文]
http://spaces.msn.com/members/jface/PersonalSpace.aspx?_c01_blogpart=blogmgmt&_c=blogpart

Tapestry4新特性(一)－default binding types

一、default binding types(默认的绑定类型)
每一个组件的参数都可以定义默认的绑定类型，如果一个绑定的参数没有前缀，将使用默认的绑定类型。
下面的代码实现同样的功能:

     加粗的部分显示前后的变化，之所以可以这样定义，是因为Insert组件定义value参数的默认绑定类型为ongl.
     注意：默认的绑定参数总是可以被显式的绑定声明覆盖掉。
    如果没有定义默认的绑定参数，那么在html模板中定义的默认绑定参数为literal，页面定义文件里的默认绑定参数为ognl

修订：

从beta4版本开始，此特性已经被删除，

Beta4的change log：

Remove default-binding attribute from element(HLS)

但是“如果没有定义默认的绑定参数，那么在html模板中定义的默认绑定参数为literal，页面定义文件里的默认绑定参数为ognl”这个效果经测试依然存在。

怀念：

此段文字在beta3中存在，beta4后就删掉了！

Binding Type Defaults

Tapestry 4.0 introduces a new idea: default binding types. Each component parameter may define a default binding type (using the default-binding attribute of the element).

If a binding reference does not have a prefix, the default binding type is used.

Because of this, the following two snippets are identical:

This works because the Insert component defines the default-binding for the value parameter to be "ognl". Likewise, the source and value parameters of the Foreach component are defined to be "ognl". However, the element parameter of the Foreach component has a binding type of "literal".

This is a decision made by the component author. If a particular parameter is (nearly) always bound using a particular binding type, then a default-binding may be set. The default binding can always be overriden with an explicit binding type prefix.

What about parameters that don't define a default binding type? The answer to this question (which includes all informal parameters), is that it depends on whether the parameter is bound in an HTML template, or in a page or component specification. In an HTML template, the default binding type is "literal". In a specification, the default binding type is "ognl".

Tapestry4新特性(二)－listener method

二、listener method
如果使用过tapestry的应该知道listener方法在4.X以前版本中的定义，如public void formSubmit(IRequestCycle cycle)，方法必须
有一个IRequestCycle参数。参数的取得方式如下：Object[] parameters = cycle.getServiceParameters();
在4.X中参数的取得可以通过以下两种方式：

调用IRequestCycle.getListenerParameters()方法,需要传入IRequestCycle实例作为参数。
按照参数的声明顺序依次定义为listener方法的参数。

第二种方法比较符合软件的设计思维，而且参数的类型在传入后保存，而不是想象中的统一String类型。
例如：
. . .
其中objectId为String类型，index为int，声明中使用了默认的参数绑定类型。
对应的方法声明如下
public void doClick(String objectId, int index)
{ . . . }
此为第二种方式，可见方法的定义符合自然习惯，当然你也可以通过传统的方法，如下所示： public void doClick(IRequestCycle cycle)
{ Object[] parameters = cycle.getListenerParameters();
String objectId = (String)parameters[0];
int index = ((Integer)parameters[1]).intValue(); . . . }
这种方式是为了向后兼容以前的版本，当然也适用那种参数数目不确定的情况。 Tapestry默认搜索以下的方法声明：

public void method(parameters)（页面的跳转 cycle.activate()如何实现？）
public void method(IRequestCycle cycle, parameters) （倾向于使用此方式）
public void method()（无需参数传递和页面跳转的情况，估计可能性不大）
public void method(IRequestCycle cycle)（传统方式）

不要试图通过参数的类型来映射listener方法，tapestry是根据参数的数目来确定方法的。

Tapestry4新特性(三)－global property source

三、Global Property Source(全局的消息属性配置)
消息属性配置听起来不是很舒服，暂时这样称呼好了，消息属性配置也就是通称的国际化配
置，通过配置一个properties文件使不同语言的浏览者看到对应语言的版本，一般
的使用如下，一个page页面，例如example.page,同目录下放一个
example.properties,在 example.html中使用来指定显示值，
中文可以使用example_zh_CN.properties来配置。看起来挺方便的，可
tapestry4.0以前的版本的国际化不支持全局的属性配置文件，必须每个页面定义
自己的，无法几个页面共享，但实际开发中，多页面共享属性配置是很常见的，
tapestry4.0中可以通过以下方式获得全局的属性配置文件：
创建一个跟你的项目全局配置文件，如yourApp.application,此文件在4.0以前的
版本中是必须的，4.0中如果没有必要配置，可以不需要此文件(扯远了),yourApp
是根据你在web.xml定义的，例如

tapesty4

org.apache.tapestry.ApplicationServlet

那属性定义文件就应该是tapestry4.properties,这样在此文件中定义一个：test=
测试，在Home.html中使用< span key="test">test,看到“测试”正确显示。

Vikings 2005-11-08 17:55 发表评论

Jive论坛与Spring框架,经典代码和架构!

Vikings — Wed, 18 May 2005 15:46:00 GMT

Jive论坛与Spring框架

板桥里人 http://www.jdon.com 2004/07/01

　　没有一种新技术是凭空诞生的，它的萌芽或胚胎总是或多或少显现于以前的技术中，Jive论坛是大家潜心研究的设计型应用程序，其相关解析可见本栏的GoF设计模式专栏。

　　Jive和Spring同为由JavaBeans组成的J2EE Web系统，Jive作为早期成功设计案例，其主要架构成为大多数纯JavaBeans系统的流行架构，Spring也不例外。

　　Spring框架除了是一种Web层应用框架，还提供了访问EJB层的接口，也有JDBC/ORM的直接操作。Spring框架主要魅力是使用IoC模式和AOP实现了Jive系统的通用功能，从而使得Jive这样的纯JavaBeans架构设计可以重用在其它系统中。

　　如果你感慨于Jive的设计理念，但是又苦于无法重用其设计时，Spring框架已经帮你实现了。

　　同时也要注意到：Spring框架类似“杂烩”，它包含了很多J2EE应用的工具，类如对EJB的调用，它的MVC与Struts JSF也是相竞争的，以纯Ioc和AOP设计来说，Spring框架也是一种很重的(Heavy、Weight)框架。Spring框架是复杂的，如果想以Spring替代EJB，那么无疑按了葫芦浮起瓢。

　　将Jive论坛和Spring框架联系起来，会帮助更多理解设计模式的程序员迅速掌握最新的设计思潮，而不是一种跳跃式的强迫接受。如果你对Jive有很好的研究，将会发现Spring框架是Jive设计的更加通用的提升。

　　在Jive中,ForumFactory是整个系统的入口和突破点，Jive通过ForumFactory将整个系统掌控在一个工厂模式下，这样做的好处是：便于控制系统的JavaBeans，例如，客户端通过ForumFactory可创建一个Forum或访问一个Forum，但是是否有权限访问呢？如下图：

　　
　　 Jive通过ForumFactory将这种访问引导到相应的Proxy类去，如ForumFactoryProxy类等，通过代理模式对这些类进行权限控制访问。这是代理模式的一个主要用处，但是研读Jive的代理模式会发现，要为每个类实现一个Proxy类，非常琐碎，有没有更优雅的方式呢？当然使用动态代理。

　　Spring框架基本是抽象上述设计，Spring框架对所有JavaBeans的管理也是基于一个总入口Bean Factory机制，不同的是，BeanFactory可以管理所有应用的JavaBeans，使用者只要将自己的JavaBeans通过配置文件告诉BeanFactory，那么BeanFactory将会加载这些JavaBeans，例如：

　　
　　　　
　　　　
　　

　　在Jive中，ForumFactory加载Jive自己的JavaBeans是通过工厂实现DbForumFactory实现的，如下代码，DbForumFactory引发了后台一系列功能实现，这是纵向，而return new ForumFactoryProxy这个语句则类似引来一个切面，从一个横向方面实现了权限访问等功能：

private static String className = "com.jivesoftware.forum.database.DbForumFactory";

public static ForumFactory getInstance(Authorization authorization) {
　　　　 //If no valid authorization passed in, return null.
　　　　 if (authorization == null) {
　　　　　　 return null;
　　　　 }
　　　　 //以下使用了Singleton 单态模式
　　　　 if (factory == null) {
　　　　　　 synchronized(initLock) {
　　　　　　　　 if (factory == null) {
　　　　　　　　　　　　 ......

　　　　　　　　 try {
　　　　　　　　　　　　　　 //动态转载类
　　　　　　　　　　　　　　 Class c = Class.forName(className);
　　　　　　　　　　　　　　 factory = (ForumFactory)c.newInstance();
　　　　　　　　　　 }
　　　　　　　　　　 catch (Exception e) {
　　　　　　　　　　　　　　 return null;
　　　　　　　　　　 }
　　　　　　　　 }
　　　　　　 }
　　　　 }

　　　　 //Now, 返回 proxy.用来限制授权对forum的访问
　　　　 return new ForumFactoryProxy(authorization, factory, 　　　　　　　　　　　　　　　　　　　 factory.getPermissions(authorization));
　　 }

　　既然Spring框架也是通过一个Bean Factory加载所有的类，那么它是如何加载的？通过IoC模式，也就是依赖性注射模式。在我以前文章“IoC模式”中，我比较了Factory工厂模式创建对象和Ioc模式的注射对象实现之间的异同，Ioc相比工厂模式则更加解耦了调用者和被调用者之间关系，使用Ioc模式，无需在调用者代码中涉及被调用者的具体实现。

　　Spring框架不但可以向自己容器中注射应用者自己定义的JavaBeans（也就是创建它们），而且也可以向这些JavaBeans通过set方法实现数据赋值。

　　一旦Bean Factory运行时刻掌管这些激活的对象，Spring通过AOP方式，从一个横切面为这些JavaBeans提供了权限访问、事务锁等通用功能的实现，这种实现是基于动态代理模式，而动态代理是AOP实现的一种方式。

　　前面提到，Jive中使用代理模式实现权限访问，比代理模式更加简洁和抽象的是动态代理，使用动态代理将使得调用者无需指定被调用者的代理类，这是动态代理区别代理模式的本质。

　　动态代理这一优势，又可以体现在另外一句话语上：动态代理拦截了调用者对被调用者的调用，正是这一功能符合了AOP的拦截器功能，为AOP实现提供了可能。

　　Spring框架使用了动态代理实现的AOP，正是通过动态代理机制拦截了外界对Bean Factory管理下的对象的调用。如下图：

　　以上只是大体解构了Spring的架构，Spring框架在这个架构下，还顺带了很多其它功能，如Web MVC、 DAO JDBC、 DAO ORM 、以及remote，后者类似我设计的EJB方法调用框架。

　　总之，Spring确实是Ioc和AOP的完美应用，Ioc用来装载JavaBeans，创建这些对象；AOP用来拦截这些对象的使用，这才是框架设计的必然经典方式。

ZT:
http://www.zahui.com/html/6/40477.htm

Vikings 2005-05-18 23:46 发表评论

EJB 工作原理 (ZT) -相见恨晚

Vikings — Tue, 03 May 2005 19:04:00 GMT

原帖: xanada ----
http://www.hibernate.org.cn/viewtopic.php?t=3832&postdays=0&postorder=asc&start=0

前两天在这个版块的精华区里翻到了Robbin关于EJB的调用原理的分析，受益非浅，但感觉用纯文字来表达效果似乎不够直观，而且对RMI的阐述也略嫌少了些。这里我根据自己的一点体会，在Robbin帖子的基础上再来说说这个话题，供大家参考。

首先，我想先说说RMI的工作原理，因为EJB毕竟是基于RMI的嘛。废话就不多讲了，RMI的本质就是实现在不同JVM之间的调用，工作原理图如下：

它的实现方法就是在两个JVM中各开一个Stub和Skeleton，二者通过socket通信来实现参数和返回值的传递。

有关RMI的例子代码网上可以找到不少，但绝大部分都是通过extend the interface java.rmi.Remote实现，已经封装的很完善了，不免使人有雾里看花的感觉。下面的例子是我在《Enterprise JavaBeans》里看到的，虽然很粗糙，但很直观，利于很快了解它的工作原理。

1. 定义一个Person的接口，其中有两个business method, getAge() 和getName()

java代码:

public interface Person { 
    public int getAge() throws Throwable; 
    public String getName() throws Throwable; 
} 

2. Person的实现PersonServer类

java代码:

public class PersonServer implements Person { 
    int age; 
    String name; 

    public PersonServer(String name, int age) { 
        this.age = age; 
        this.name = name; 
    } 

    public int getAge() { 
        return age; 
    } 

    public String getName() { 
        return name; 
    } 
} 

3. 好，我们现在要在Client机器上调用getAge()和getName()这两个business method，那么就得编写相应的Stub(Client端)和Skeleton(Server端)程序。这是Stub的实现：

java代码:

import java.io.ObjectOutputStream; 
import java.io.ObjectInputStream; 
import java.net.Socket; 

public class Person_Stub implements Person { 
    Socket socket; 

    public Person_Stub() throws Throwable { 
        // connect to skeleton 
        socket = new Socket("computer_name", 9000); 
    } 

    public int getAge() throws Throwable { 
        // pass method name to skeleton 
        ObjectOutputStream outStream = 
            new ObjectOutputStream(socket.getOutputStream()); 
        outStream.writeObject("age"); 
        outStream.flush(); 

        ObjectInputStream inStream = 
            new ObjectInputStream(socket.getInputStream()); 
        return inStream.readInt(); 
    } 

    public String getName() throws Throwable { 
        // pass method name to skeleton 
        ObjectOutputStream outStream = 
            new ObjectOutputStream(socket.getOutputStream()); 
        outStream.writeObject("name"); 
        outStream.flush(); 

        ObjectInputStream inStream = 
            new ObjectInputStream(socket.getInputStream()); 
        return (String)inStream.readObject(); 
    } 
} 

注意，Person_Stub和PersonServer一样，都implements Person。它们都实现了getAge()和getName()两个business method，不同的是PersonServer是真的实现，Person_Stub是建立socket连接，并向Skeleton发请求，然后通过Skeleton调用PersonServer的方法，最后接收返回的结果。

4. Skeleton实现

java代码:

import java.io.ObjectOutputStream; 
import java.io.ObjectInputStream; 
import java.net.Socket; 
import java.net.ServerSocket; 

public class Person_Skeleton extends Thread { 
    PersonServer myServer; 

    public Person_Skeleton(PersonServer server) { 
        // get reference of object server 
        this.myServer = server; 
    } 

    public void run() { 
        try { 
            // new socket at port 9000 
            ServerSocket serverSocket = new ServerSocket(9000); 
            // accept stub's request 
            Socket socket = serverSocket.accept(); 

            while (socket != null) { 
                // get stub's request 
                ObjectInputStream inStream = 
                    new ObjectInputStream(socket.getInputStream()); 
                String method = (String)inStream.readObject(); 

                // check method name 
                if (method.equals("age")) { 
                    // execute object server's business method 
                    int age = myServer.getAge(); 
                    ObjectOutputStream outStream = 
                        new ObjectOutputStream(socket.getOutputStream()); 

                    // return result to stub 
                    outStream.writeInt(age); 
                    outStream.flush(); 
                } 

                if(method.equals("name")) { 
                    // execute object server's business method 
                    String name = myServer.getName(); 
                    ObjectOutputStream outStream = 
                        new ObjectOutputStream(socket.getOutputStream()); 

                    // return result to stub 
                    outStream.writeObject(name); 
                    outStream.flush(); 
                } 
            } 
        } catch(Throwable t) { 
            t.printStackTrace(); 
            System.exit(0); 
        } 
    } 

    public static void main(String args []) { 
        // new object server 
        PersonServer person = new PersonServer("Richard", 34); 

        Person_Skeleton skel = new Person_Skeleton(person); 
        skel.start(); 
    } 
} 

Skeleton类 extends from Thread，它长驻在后台运行，随时接收client发过来的request。并根据发送过来的key去调用相应的business method。

5. 最后一个，Client的实现

java代码:

public class PersonClient { 
    public static void main(String [] args) { 
        try { 
            Person person = new Person_Stub(); 
            int age = person.getAge(); 
            String name = person.getName(); 
            System.out.println(name + " is " + age + " years old"); 
        } catch(Throwable t) { 
            t.printStackTrace(); 
        } 
    } 
} 

Client的本质是，它要知道Person接口的定义，并实例一个Person_Stub，通过Stub来调用business method，至于Stub怎么去和Server沟通，Client就不用管了。

注意它的写法：
Person person = new Person_Stub();
而不是
Person_Stub person = new Person_Stub();

为什么？因为要面向接口编程嘛，呵呵。

感谢您有耐心看到这里，关于RMI，我想说的就这么多了。但是好象还没写到EJB，本人就累了个半死，算了，我还是先去睡觉，明天再往下续吧。。。

本人没有用过Weblogic，这里就结合WebSphere来讲讲各个类的调用关系吧。

假定我们要创建一个读取User信息的SessionBean，需要我们写的有3个文件：
1. UserServiceHome.java
Home接口

2. UserService.java
Remote接口

3. UserServiceBean.java
Bean实现

WSAD最终会生成10个class。其它7个是什么呢？我们一个一个数过来：

4. _UserServiceHome_Stub.java
这个当然就是Home接口在Client端(动态加载)的Stub类了，它implements UserServiceHome。

5. _EJSRemoteStatelessUserServiceHome_a940aa04_Tie.java
Home接口在Server端的Skeleton类，"a940aa04"应该是随机生成的，所有其他的相关class名里都会有这个标志串，Tie是Corba对Skeleton的叫法。

6. EJSRemoteStatelessUserServiceHome_a940aa04.java
Home接口在Server端的实现，当然，它也implements UserServiceHome。

7. EJSStatelessUserServiceHomeBean_a940aa04.java
由#6调用，create _UserService_Stub。(为什么#6不能直接create _UserService_Stub呢？后面再讲。)

8. _UserService_Stub.java
Remote接口在Client端(动态加载)的Stub类。它implements UserService。

9. _EJSRemoteStatelessUserService_a940aa04_Tie.java
Remote接口在Server端的Skeleton类。

10. EJSRemoteStatelessUserService_a940aa04.java
Remote接口在Server端的实现，当然，它也implements UserService。并且，它负责调用UserServiceBean——也就是我们所写的Bean实现类——里面的business method。

那么，各个类之间的调用关系到底是怎么样的呢？简单的说，就是两次RMI循环。

先来看看Client端的程序是怎么写的：

java代码:

try { 
    InitialContext ctx = new InitialContext(); 

    //第一步 
    UserServiceHome home = 
        (UserServiceHome) PortableRemoteObject.narrow( 
            ctx.lookup(JNDIString), 
            UserServiceHome.class); 

    //home: _UserServiceHome_Stub 
    System.out.println(home.toString()); 

    //第二步 
    UserService object = home.create(); 

    //ojbect: _UserService_Stub 
    System.out.println(object.toString()); 

    //第三步 
    int userId = 1; 
    UserInfo ui = object.getUserInfo(userId); 
} 

在第一步之后，我们得到了一个UserServiceHome(interface)定义的对象home，那么，home到底是哪个class的instance呢？用debug看一下，知道了home原来就是_UserServiceHome_Stub的实例。

从第二步开始，就是我们的关注所在，虽然只有简单的一行代码，
UserService object = home.create();
但是他背后的系统是怎么运做的呢？我们进入代码来看吧：

1. 调用home.create()

java代码:

UserServiceHome home; 
UserService obj = home.create(); 

2. 实际是调用_UserServiceHome_Stub.create()，在这个方法里面，Stub向Skeleton发送了一个create的字串：

java代码:

org.omg.CORBA.portable.OutputStream out = _request("create", true); 
in = (org.omg.CORBA_2_3.portable.InputStream)_invoke(out); 

3. Server端的Skeleton接收Stub发来的request，并调用相应的方法：

java代码:

_EJSRemoteStatelessUserServiceHome_a940aa04_Tie._invoke() { 
    ...... 
    switch (method.length()) { 
        case 6: 
            if (method.equals("create")) { 
                return create(in, reply); 
            } 
        ...... 
    } 
} 

java代码:

_EJSRemoteStatelessUserServiceHome_a940aa04_Tie.create() { 
    EJSRemoteStatelessUserServiceHome_a940aa04 target = null; 
    result = target.create(); 
    org.omg.CORBA.portable.OutputStream out = reply.createReply(); 
    Util.writeRemoteObject(out,result); 
    return out; 
} 

4. Skeleton调用的是UserServiceHome的Server端实现类的create方法

java代码:

EJSRemoteStatelessUserServiceHome_a940aa04.create() { 
    UserService _EJS_result; 
    _EJS_result = EJSStatelessUserServiceHomeBean_a940aa04.create(); 
} 

5. #4又调用EJSStatelessUserServiceHomeBean_a940aa04.create()

java代码:

    UserService result = super.createWrapper(new BeanId(this, null)); 

至此，我们终于结束了第一个RMI循环，并得到了Remote接口UserService的Stub类_UserService_Stub，就是#5里面的result。

这里有一个问题，为什么#4不直接create _UserService_Stub，而又转了一道#5的手呢？因为#4 extends from EJSWrapper，它没有能力create Stub，因此必须借助#5，which extends from EJSHome，这样才可以生成一个Stub。如果不是为了生成这个Stub，应该可以不走#5这一步。

OK, now we got the object which is instanceOf _UserService_Stub, and implements UserService

现在我们的Client端走到第三步了：
UserInfo ui = object.getUserInfo(userId);

继续看代码，开始第二个RMI循环：

1. 调用object.getUserInfo()

java代码:

UserService object; 
object.getUserInfo(userId); 

2. 实际是调用_UserService_Stub.getUserInfo(int arg0)，在这个方法里面，Stub向Skeleton发送了一个getUserInfo的字串和arg0这个参数：

java代码:

org.omg.CORBA.portable.OutputStream out = _request("getUserInfo", true); 
out.write_long(arg0); 
in = (org.omg.CORBA_2_3.portable.InputStream)_invoke(out); 

3. Server端的Skeleton接收Stub发来的request，并调用相应的方法：

java代码:

_EJSRemoteStatelessUserService_a940aa04_Tie._invoke() { 
    switch (method.charAt(5)) 
    { 
        case 83: 
            if (method.equals("getUserInfo")) { 
                return getUserInfo(in, reply); 
            } 
        ...... 
    } 
} 

_EJSRemoteStatelessUserService_a940aa04_Tie.getUserInfo() { 
    EJSRemoteStatelessUserService_a940aa04 target = null; 
    int arg0 = in.read_long(); 
    UserDTO result = target.getUserInfo(arg0); 
    org.omg.CORBA_2_3.portable.OutputStream out = reply.createReply(); 
    out.write_value(result,UserDTO.class); 
    return out; 
} 

4. Skeleton调用的是UserService的Server端实现类的getUserInfo方法

java代码:

EJSRemoteStatelessUserService_a940aa04.getUserInfo() { 
    UserServiceBean _EJS_beanRef = container.preInvoke(this, 0, _EJS_s); 
    _EJS_result = _EJS_beanRef.getUserInfo(id); 
} 

最后的最后，#4终于调用了我们写的UserServiceBean里的getUserInfo方法，这才是我们真正想要去做的事情。

至此，第二个RMI循环也终于结束了。

回顾一下上面的分析，可以很清晰的看到两次RMI循环的过程，下图(见链接)描述了整个流程：

http://www.pbase.com/image/27229257
http://mk23.image.pbase.com/u42/nobo123/upload/27229257.ejb2.jpg

黄色的1，6，10是程序员要写的，其余是系统生成的。

#1是Home interface, #2和#4都implements 了它。
#6是Remote interface, #7和#9都implements 了它。
#10是Bean实现。

写到这里，基本要说的就说完了。这实在是一项累死人的工作，希望您能稀饭。欢迎补充，欢迎摘错。谢谢，呵呵。

简单讲，就是为了适应分布式开发的需要。

首先，回到我最后给出的流程图。

Client端最原始的冲动，肯定是能直接调用#10.UserServiceBean就爽了。那么第一个问题来了，
Client和Server不在一个JVM里。

这好办，我们不是有RMI吗，好，这个问题就这么解决了：
1. UserServiceBeanInterface.getUserInfo()
2. UserServiceBeanStub
3. UserServiceBeanSkeleton
4. UserServiceBean

用着用着，第二个问题来了，
UserServiceBean只有人用，没人管理，transaction logic, security logic, bean instance pooling logic这些不得不考虑的问题浮出水面了。

OK，我们想到用一个delegate，EJBObject，来进行所有这些logic的管理。client和EJBObject打交道，EJBObject调用UserServiceBean。

注意，这个EJBObject也是一个Interface，#6.UserService这个interface正是从它extends而来。并且EJBObject所管理的这些logic，正是AppServer的一部分。

现在的流程变为了：
EJBObject
1. UserService.getUserInfo()
2. UserServiceStub
3. UserServiceSkeleton
4. UserServiceImp
5. UserServiceBean

这已经和整幅图里的#6, #7, #8, #9, #10一一对应了。

现在能满足我们的需求了吗？不，第三个问题又来了：
既然是分布式开发，那么我当然没理由只用一个Specified Server，我可能需要用到好几个不同的Server，而且EJBObject也需要管理呀

OK，为了适应你的需要，我们还得加再一个HomeObject，首先它来决定用哪个Server(当然，是由你用JNDI String设定的)，其次，它来管理EJBObject。

注意，这个EJBHome也是一个Interface，#1.UserServiceHome这个interface正是从它extends而来。并且EJBHome管理EJBObject的logic，也是AppServer的一部分。

现在的调用次序是
1. EJBHome.create()
2. EJBHomeStub
3. EJBHomeSkeleton
4. EJBHomeImp(EJSWrapper)
5. EJSHome

得到EJBObject

6. UserService.getUserInfo()
7. UserServiceStub
8. UserServiceSkeleton
9. UserServiceImp
10. UserServiceBean

现在已经完全和流程图的调用顺序一致了。

综上所述，EJB的调用确实很麻烦，但是搞的这么麻烦，确实是有搞的麻烦的道理，实在是不得不为也。

哎哟，好累啊。希望我把这个问题说清楚了，您也没给我绕迷糊。谢谢。

Vikings 2005-05-04 03:04 发表评论