主要掌握javaBean、socket、servlet、jsp、JDBC、IO流等。bean是一种规范,也是组件,它主要用来处理业务逻辑部分及存取数据库中数据,servlet是服务器端的小应用程序,它主要用于控制业务流程的,taglib是自定义标记库,它用于封装一些java代码,便于复用。

解决方案 »

  1. EJB是核心,感觉也是最难的一部分。
      

  2. ejb jms jndi jta weblogic 连接池一个ejb客户端为了完成一个用例需要执行商业逻辑。 怎样让一个开发者用一个轻量级的态度实现一个用例的 
    3.在一个大型公司中服务器资源经常被一个小组控制。 
    对一个有建立了的并且正在工作的发布的ejb集合的大型 
    公司,很难让其他项目的小组对已有的类施加影响和改变。 简单说,用session facade和business delegate开发会导致 
    长期的变化->发布->测试的round-trip,会成为大型项目的 
    瓶颈。问题的关键是商业逻辑放在一个session bean层, 
    几乎是重量级的开发。 综上所述: 
      使用Command模式来封装商业逻辑到轻量级的command 
    bean,使客户端从EJB解耦,在一个网络调用中执行,作为 
    EJB层的一个facade。 一个command bean只是一个有get,set和一个execute方法的 
    普通Java类,和最初的command模式(四人帮(gof),1995)描述 
    的一样。应用到EJB,Command模式为了达到和session facade 
    和business delegate相同的好处提供了一个轻量级解决方案: 
    一个隐藏ejb层的对象模型,在一个事物和一次网络调用中执 
    行一个用例,完成使客户端从ejb解耦的facade。command模式 
    通过提供本地交互的类达到这一点,不过实际上在一个远程 
    ejb服务器上执行,对客户端透明。 Command被用来封装应用程序中的单独的工作单元。比如 
    placeOrder,transferFunds,等等的用例,将有它的商业/工作流 
    逻辑封装在只为那个用例的特定的Command,如图1.7所示。 和一个command交互的客户端十分简单。一旦一个客户端得到 
    一个command(创建一个或从一个factory得到,取决于实现), 
    它只是简单的对command设置属性,直到command包含所有需要 
    执行用例的数据。这时客户端能调用command的execute方法, 
    然后简单的执行command上的get直到得到所有command和用例 
    的结果数据。 当客户端执行command,有趣的事情在幕后发生。不是本地执行, 
    command实际上传输到一个远程ejb服务器并在ejb服务器的JVM 
    中执行。然而,所有的在执行用例的过程中被command调用的 
    ejb发生在ejb服务器上,一个用例能在一个事物中执行。这个 
    行为的实现机制晚些时候将在这个模式的讨论中讲解。 使用transfunds例子,一个客户端将设置用来取钱,存钱,传输 
    量的账号的ID。调用transfunds command的execute后,客户端 
    将得到最后账户的平衡,如1.8图所示。 可能Command模式最完善的实现之一是IBM的Command框架,和websphere 
    一同出现,是IBM为电子商务的模式的一部分。有很多实现ejb command 
    模式的方法,不过他们都有3个要素: 1.Command bean。一个有get,set和一个包含需要执行一个用例的商业逻辑 
    的execute方法的简单的java bean。command bean是应用程序开发者需要 
    写的command模式的唯一部分,下面所解释的其他组件是可以跨工程复用的。 2.客户端路由逻辑。通常负责执行命令(command)并把它发送到远程ejb 
    服务器的一个类的框架。这个路由逻辑通常对客户端不可见,通过调用 
    command的execute方法来触发。路由逻辑/框架是一个普通的能被跨工程 
    复用的类的集合。 3.远程Command server。Command server是简单的接受命令(commands) 
    并执行它们的服务。应用到ejb,command server类是一个接受命令(command) 
    作为参数并本地执行之的stateless session bean。Command server也是 
    普通的(generic)并且完全跨项目可复用。 客户端和这3个组件之间的交互如图1.9所示。在这个例子中,客户端调用 
    路由逻辑组件上的executeCommand方法。在IBM command框架中,客户端 
    只需要调用command自己的execute,因为方法调用将实际上被command的 
    超类接收到,它是路由逻辑框架的一部分。 在幕后,CommandExecutor代理了对一个ejb command目标(因为它是路由 
    逻辑的一部分,所以没有在图1.9中表示出来)的调用,它被编码成知道ejb 
    并且知道怎样发送命令(command)到command server stateless session 
    bean。通过接受命令(command),command server简单的调用command的 
    execute方法,command然后继续它的商业逻辑。 Command模式的好处如下: 
    1.因为轻量级的开发/分发过程,方便了RAD。 
    把一个用例写成Command bean比写成一个session 
    bean方法相对更容易和快速去分发和测试。经常 
    的变化能在一个普通java类上做,而不是一个 
    完全的EJB。 2.把商业逻辑从表示逻辑分离。Command通过封装 
    command内的商业逻辑来作为服务器上对象模型 
    的一个facade,只暴露一个简单的command接口 
    让客户端使用。这个分离让客户端和服务器分开 
    的演进。 3.强制用例在一个单独的round trip中执行。 
    因为command实际上在EJB服务器上执行,只需要 
    一次网络调用(和一个事务)来完成一个复杂的 
    用例。 4.使客户端从ejb解耦。客户端是完全的从服务器的 
    实现细节解耦的--所有它们能看见的只是command bean, 
    command bean看上去象是本地类。 5.命令(command)可以本地执行或产生哑(dummy)数据。 
    空的或虚的命令(command)能在项目开始前被创建, 
    允许表示层开发者去对于商业逻辑和ejb小组相对独立的 
    写,编译,和测试他们的代码。 很多方面command模式听起来像个终极的解决方案,综合了 
    session facade和business delegate的好处,和一个 
    轻量级的基础。然而,好处和通常一样,被重要的trade-off 
    所平衡: 
    1.非常粗粒度的事务控制。因为command只是普通java bean, 
    没有自动的标记一个command去在一个特定的事务设置或 
    isolation level下运行的方法,而你用session bean方法可以。 
    Command只能在执行它们的Command server的事务设置下运行。 
    这个的结果是用不同的jndi名字和事务设置(在deployment 
    descriptor中配置)来分发多个command server session bean。 
    路由逻辑组件需要被配置成发送特定的命令(command)到command 
    server。就是说,一种方法想发送只读command到没有事务的 
    session bean,然而更新命令能在command server下用tx_required 
    和可序列化的isolation level运行。 2.command是无状态的。command对象不能存储任何状态到执行它的 
    session bean中。用command模式在ejb层存储状态是不可能的。 3.笨拙的错误处理。因为command框架是通用的(generic),从 
    command只有CommandException能被抛出。这意味着,应用程序 
    异常,如NoMoneyAccountException,需要被捕获并用CommandException 
    封装。然后客户端需要为了特定的异常透视到command对象里面。因为 
    异常不是显式的宣称的,客户端失去了编译期检查异常处理的好处。 4.command在大型项目中会变得无法管理。用成千的command, 
    大型项目会爆炸的,很多command有重复的商业逻辑的部分, 
    特别当不同的项目小组使用同样的后端领域模型。这使得 
    维护商业逻辑层比起在session bean方法中实现用例的session 
    facade(很好的分组到数目很小的session bean中)困难得多。 
    这种类的激增将是大型项目的严重问题。 5.Command Server ejb-jar紧密的耦合到command bean和 
    其它ejb。因为command bean在command server的环境下 
    执行,为了使command bean反序列化和执行,command bean 
    类需要和command server session bean一起分发(在相同的 
    ejb-jar或EAR中)。这意味着只要command bean变化了,command 
    server session bean EAR或ejb-jar将需要重新分发(因此command 
    server classloader能读到所有包含的command的新版本),为了 
    测试变化,或完全重起(如果你的应用服务器不支持热分发)。 
    还有,command bean需要看见任何在它们的商业逻辑中使用到的 
    home,remote,local home,或local interface。这需要或者当 
    ejb被任何它们的command bean存取时command server分发到 
    相同的EAR,或者存取ejb的interface和command server的ejb-jar 
    打包到一起。 command模式和session facade模式一起提供了两个重要的好处: 
    他们作为一个facade和它们在一个网络round trip中执行。另一个 
    command模式比session facade模式好的主要优点是把客户端从 
    ejb解耦了,用business delegate和session facade一起也可以达 
    到。因此,开发者怎样从中选择呢?把command看作是更便宜(cheaper) 
    的session bean会有所帮助。它们是轻量级的,更快的先导开发过程, 
    以后来的差的可维护性作为代价。
      

类似问题 »