曾功立(来自火星的战神) 职业之路 负责金财核心项目架构， 使用技术J2EE、SPRING、HIBERNATE、RCP。 大家多多交流，共同发展。 http://zenggongli.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 weblogic集群经验 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/185739  发表时间: 2008年04月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

经验在WebLogic Server 8.14上配置集群，以及通过Proxy Server来访问集群

 

必要条件

Ø  集群中的所有 S erver必须位于同一 网段 ，并且必须是IP广播(UDP)可到达的

Ø  集群中的所有Server必须使用相同的版本,包括Service Pack

Ø  集群中的Server必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器

 

配置

在同一网段内的不同机器上配置集群

机器类型

操作系统

硬件配置

角色

备注

DELL PC

Win2000  Server

IP:10.16.92.1 PORT:7080

Administrator  Server

 

DELL PC

Win2000  Server

IP:10.16.92.1 PORT:8080

Proxy  Server

 

DELL PC

Win2000  Server

IP:10.16.92.1 PORT:7082

Managed Server

 

DELL PC

Win2000  Server

IP:10.16.92.4 PORT:7084

Managed Server

 

 

 

启动服务

Ø  启动Administrator Server

使用startWebLogic命令启动Administrator Server

Ø  启动Managed Server

使用startManagedWeblogic命令启动Managed Server，它的命令格式是：

startManagedWeblogic.cmd   Managed Server的名称   Administrator Server地址

如: startManagedWeblogic server1 http:// 10.16.92.1:7082

同理可以启动nodeB和nodeC，以及Proxy Server

注意:

可能使用console/服务器,启动不了非admin服务器,必须使用命令行.

非admin服务器必须先启动server\bin\startNodeManager.cmd

配置服务器的计算机,可能带来5500端口冲突

 

 

分发处理

  HttpClusterServlet通过一个WebLogic服务器代理对WebLogic集群中的其他服务器成员的HTTP请求， 同时HttpClusterServlet还为代理的HTTP请求提供负载平衡与容错处理 。

  注意:proxyServer只是发布分发web,业务具体web要部署到cluster上.

   

Ø  生成配置文件web.xml 

<web-app>

    <display-name>ProxyWebApp</display-name>

    <servlet>

        <servlet-name>HttpClusterServlet</servlet-name>

        <servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>

        <init-param>

            <param-name>WebLogicCluster</param-name>

            <param-value>10.16.92.1:7082|10.16.92.4:7084</param-value>

        </init-param>

    </servlet>

    <servlet-mapping>

        <servlet-name>HttpClusterServlet</servlet-name>

        <url-pattern>/</url-pattern>

    </servlet-mapping>

    <servlet-mapping>

        <servlet-name>HttpClusterServlet</servlet-name>

        <url-pattern>*.jsp</url-pattern>

    </servlet-mapping>

    <servlet-mapping>

        <servlet-name>HttpClusterServlet</servlet-name>

        <url-pattern>*.html</url-pattern>

    </servlet-mapping>

    <servlet-mapping>

        <servlet-name>HttpClusterServlet</servlet-name>

        <url-pattern>*.htm</url-pattern>

    </servlet-mapping>

</web-app>
 
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 23 Apr 2008 10:09:56 +0800 http://zenggongli.javaeye.com/blog/185739 http://zenggongli.javaeye.com/blog/185739 SOA知识汇总 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/175436  发表时间: 2008年03月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

企业服务总线解决方案剖析
1.介绍了面向服务的体系结构(service-oriented architecture，SOA)和企业服务总线(Enterprise Service Bus，ESB)的基本知识，ESB的技术沿革，以及ESB与SOA之间的关系。
http://www-128.ibm.com/developerworks/cn/webservices/ws-esb1/

2.对IBM最新的应用服务器WebSphere 6中对ESB的支持进行实例化的介绍，希望通过具体的例子让读者更快，更方便的利用WebSphere 6的提供的基础设施向SOA(Service Oriented Architecture)进行迁移。
http://www-128.ibm.com/developerworks/cn/webservices/ws-esb2/

3.介绍如何应用IBM的WBI 5系列实现ESB，并通过具体的例子让读者更深入的了解IBM WBI系列产品中对ESB的支持，从而更快，更方便的利用WBI 5提供的基础设施向SOA架构进行迁移。
http://www-128.ibm.com/developerworks/cn/webservices/ws-esb3/
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 24 Mar 2008 14:54:31 +0800 http://zenggongli.javaeye.com/blog/175436 http://zenggongli.javaeye.com/blog/175436 JSF组件开发指南 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/162762  发表时间: 2008年02月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

JSF 组件模型

JSF 组件模型与 AWT GUI 组件模型类似。它有事件和属性，就像 Swing 组件模型一样。它也有包含组件的容器，容器也是组件，也可以由其他容器包含。从理论上说，JSF 组件模型分离自 HTML 和 JSP。JSF 自带的标准组件集里面有 JSP 绑定，可以生成 HTML 渲染。



JSF 组件的示例包括日历输入组件和 HTML 富文本输入组件。您可能从来没时间去编写这样的组件，但是如果它们已经存在，那会如何呢？通过把常用功能变成商品，组件模型降低了向 Web 应用程序添加更多功能的门槛。



组件的功能通常围绕着两个动作：解码和编码数据。

解码（decoding） 是把进入的请求参数转换成组件的值的过程。

编码 (encode) 是把组件的当前值转换成对应的标记（也就是 HTML）的过程。



JSF 框架提供了两个选项用于编码和解码数据

使用直接实现 方式，组件自己实现解码和编码

使用委托实现 方式，组件委托渲染器进行编码和解码。

如果选择委托实现，可以把组件与不同的渲染器关联，会在页面上以不同的方式渲染组件；例如多选列表框和一列复选框。因此，JSF 组件由两部分构成：组件和渲染器。JSF 组件 类定义 UI 组件的状态和行为；渲染器 定义如何从请求读取组件、如何显示组件 —— 通常通过 HTML 渲染。渲染器把组件的值转换成适当的标记。事件排队和性能验证发生在组件内部。

在图 1 中可以看到数据编码和解码出现在 JSF 生命周期中的什么阶段




图 1. JSF 生命周期和 JSF 组件



所有 JSF 组件的基类是 UIComponent。在开发自己的组件时，需要继承 UIComponentBase，它扩展了 UIComponent 并提供了 UIComponent 中所有抽象方法的默认实现。组件拥有双亲和标识符。每个组件都关联着一个组件类型，组件类型用于在 face 的上下文配置文件（faces-config.xml）中登记组件。可以用 JSF-EL （表达式语言）把 JSF 组件绑定到受管理的 bean 属性。可以把表达式关联到组件上的任何属性，这样就允许用 JSF-EL 设置组件的属性值。在创建使用 JSF-EL 绑定的组件属性时，需要创建值绑定表达式。在调用绑定属性的 getter 方法时，除非 setter 方法已经设置了值，否则 getter 方法必须用值绑定获得值。组件可以作为 ValueHolder 或 EditableValueHolder。ValueHolder 与一个或多个 Validator 和 Converter 相关联；所以 JSF UI 组件也与 Validator 和 Converter 关联



像表单字段组件这样的组件拥有一个 ValueBinding，它必须绑定到 JavaBean 的读写属性。组件可以调用 getParent 方法访问它们的双亲，也可以调用 getChildren 方法访问它们的子女。组件也可以有 facet 组件，facet 组件是当前组件的子组件，可以调用 getFacets 方法访问它，这个方法返回一个映射。Facets 是著名的子组件。

这里描述的许多组件的概念将会是接下来展示的示例的一部分，所以请记住它们！





提示！

在许多情况下，可以在保持组件本身不变的情况下，通过改变渲染而简化开发过

程。在这些情况下，可以编写定制渲染器而不是定制组件。



JSF 组件的LoginComponent



我们用一个又好又容易的示例来开始 JSF 组件的开发：

下面是我要采取的步骤：



1. 扩展 UIComponent

创建一个类，扩展 UIComponent

保存组件状态

用 faces-config.xml 登记组件

2. 创建定制标记，继承 UIComponentTag

覆盖 encode

覆盖 decode

用 faces-config.xml 登记渲染器

3. 定义渲染器或者内联地实现它

返回渲染器类型

返回组件类型

设置可能使用 JSF 表达式的属性





详细结构：由component 、model 、renderer 、taglib 、utils(可选) 组成。




Step 1 扩展Components

具体代码请参考Sample , 这里只叙述一些重要的方法

第一个类是LoginComponent.java LoginComponent是整个组件开发的核心类。

它必须继承一个UIComponent ,这里它继承的是UIInput

每个组件都关联着一个组件类型，组件类型用于在 face 的上下文配置文件（faces-config.xml）中登记组件






<component>

<component-type>sonic.Loginr</component-type>

<component-class>mycomponents.component.LoginComponent</component-class>

</component>



JSF提供了数值绑定机制，使得在Faces标记中访问bean property 很容易，其原理是用 JSF-EL （表达式语言）把 JSF 组件绑定到受管理的 bean 属性。可以把表达式关联到组件上的任何属性，

这样就允许用 JSF-EL 设置组件的属性值,比如：

<h：inputText id=”user” value=”#{ userBean .username}” />

Valuebinding 在解析userBean.username这个keypath的时候，会使用反射（reflection）访问UserBean中的username property、如果没有就为null.。





在创建使用 JSF-EL 绑定的组件属性时，需要创建值绑定表达式。在调用绑定属性的 getter 方法时，除非 setter 方法已经设置了值，否则 getter 方法必须用值绑定获得值。




//get The UserName value

public String getUserText() ...{

if(this.userText!=null)

return this.userText;

else...{

ValueBinding vb = this.getValueBinding("userText");

if(vb==null)

return "";

else

return (String)vb.getValue(getFacesContext());

}

}





//Get the Password value

public String getPswText() ...{

if(this.pswText!=null)

return this.pswText;

else...{

ValueBinding vb = this.getValueBinding("pswText");

if(vb == null)

return "";

else

return (String)vb.getValue(getFacesContext());

}

}




所有 JSF 组件的基类是 UIComponent。在开发自己的组件时，需要继承 UIComponentBase，它扩展了 UIComponent 并提供了 UIComponent 中所有抽象方法的默认实现。



它的主要作用就是保存和恢复组件的状态。由saveStore(),restoreState() 两个方法来执行。

getFamily（）方法主要是返回在faces-config.xml中定义了相关联的渲染器






<render-kit>

<renderer>

<component-family>sonic.Loginr</component-family>

<renderer-type>sonic.Loginr</renderer-type>

<renderer-class>mycomponents.renderer.LoginRenderer</renderer-class>

</renderer>

</render-kit>



UIComponent 类的一个职责是为其绑定的model property 提供UI表示（UIComponent＆Render其实对应MVC中的View）。 UIComponent定义有value property , 用了缓冲在请求相应中inbound(接受请求值) , outbound（处理后的请求值）这个property 还在

Apply Request Values 阶段暂时保存了对提交的值转换之后的结果，最终，组件value字段的内容会在

Update Model Value 阶段 被转换到对应的bean property .



由于，我的组件是一个复合组件，有2个textbox ， 他不能在updateModel()这个方法中自动绑定与bean相关联的属性，所以在这个里面就要重载updateModel(),手动绑定属性到bean中。


public void updateModel(FacesContext context) ...{

// TODO Auto-generated method stub

ValueBinding vb = this.getValueBinding("userText");

if (vb != null)...{

vb.setValue(context,this.getUsername());

this.setUsername(null);

}


ValueBinding vb2 = this.getValueBinding("pswText");

if (vb2 != null)...{

vb2.setValue(context,this.getPassword());

this.setPassword(null);

}

super.updateModel(context);

}








Step 2 创建一个LoginTag为 LoginComponent创建定制标记


l LoginTag 必须 extends UIComponentTag

l 在web.xml中的 <jsp-config></jsp-config>中添加标记定位


<jsp-config>

<taglib>

<taglib-uri>http://www.ygsoft.com</taglib-uri>

<taglib-location>/WEB-INF/login.tld</taglib-location>

</taglib>

</jsp-config>






l 添加login.tld


setProperty()这个方法允许这个代码允许 LoginComponent的 value 属性绑定到后台 bean


protected void setProperties(UIComponent component) ...{

/**//* have to call the super class */

super.setProperties(component);

CompUtils.setAttribute(component,"userLabel",userLabel);

CompUtils.setAttribute(component,"pswLabel",pswLabel);

CompUtils.setAttribute(component,"userText",userText);

CompUtils.setAttribute(component,"pswText",pswText);

CompUtils.setAttribute(component,"loginSuccess",loginSuccess);

CompUtils.setAttribute(component,"loginFailure",loginFailure);

CompUtils.setAttribute(component,"errorStyleClass",errorStyleClass);

((LoginComponent)component).setRequired(true);

}



public final static void setAttribute(UIComponent component,

String attrName, String value) ...{

if (value != null) ...{

if (Util.isVBExpression(value)) ...{

ValueBinding vb = Util.getValueBinding(value);

component.setValueBinding(attrName, vb);

} else ...{

component.getAttributes().put(attrName, value);

}

}

}




errorStyleClass属性不是setValueBinding的，它们被添加到 JSF 组件的属性映射 中。Renderer类会使用属性映射去渲染类和样式属性。这个设置允许特定于 HTML 的代码从组件脱离所以是用getAttributes().put(attrName, value);来设定的



最后是把渲染器映射到组件


public String getComponentType() {

return "sonic.Loginr";

}

<component>

<component-type>sonic.Loginr</component-type>

<component-class>mycomponents.component.LoginComponent</component-class>

</component>

============================================================================

public String getRendererType() {

return "sonic.Loginr";

}

<render-kit>

<renderer>

<component-family>sonic.Loginr</component-family>

<renderer-type>sonic.Loginr</renderer-type>

<renderer-class>mycomponents.renderer.LoginRenderer</renderer-class>

</renderer>

</render-kit>








Step 3 定义一个独立渲染器LoginRender


其实渲染器可以在UIComponent里面的，这里使用的是使用委托实现方式，组件委托渲染器进行编码和解码。

渲染器的作用其实主要是html的输出，其中的重点是encodeBegin， decode



LoginComponent组件是一个 UIInput 组件，这意味着它接受输入(UIOutPut组件不用decode)，所以 必须 进行解码。decode方法可以从会话、cookie、头、请求等处读取值。在大多数请问下，decode方法只是像上面那样从请求参数读取值。Decode 方法负责从请求取得输入，并解码成适合组件的数据



Encode 编码，编成HTML码,Rander类里面就是encodeBegin , encodeEnd这里就是写在encodeBeanin里面，其实对应自定义标签里面的doStartTag() , doEndTag();

encodeBegin()里面主要是用 ResponseWriter

响应写入器（javax.faces.context.ResponseWriter）可以容易地处理 HTML 这样的标记语言






ResponseWriter writer = context.getResponseWriter();

比如：

writer.startElement("table", component);

writer.writeAttribute("width", "60%", null);

writer.writeAttribute("align", "center", null);

writer.writeAttribute("border", "0", null);

writer.writeAttribute("cellpadding", "0", null);

writer.endElement("table");



生成的HTML代码就是


<table width=”60%” align=”center” border=”0” cellspacing=”1”></table>
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 17 Feb 2008 12:14:41 +0800 http://zenggongli.javaeye.com/blog/162762 http://zenggongli.javaeye.com/blog/162762 项目经理面试指南 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/162761  发表时间: 2008年02月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

本文的目的是为应聘项目经理提供帮助。项目管理是升迁的途径，需要运用你过去的开发经验，而且薪水通常高于程序员。应聘项目经理的准备工作包括：复习一些常用的概念、术语，问自己一些在面试中经常问到的问题。学会运用一个或多个项目管理计划编制工具。通过以上的准备，将为你应聘这个职位增加信心。

想好你要说的内容并准备回答涉及面广泛的问题是成功应聘的重要方面。与应聘技术职位不同的是，项目管理问题的答案往往是主观的。要牢记技术项目的项目经理的职责是组织项目成员通过完成技术任务而达到某种商业目标。该技术任务应该是可应用或维护的，都必须满足客户/用户的要求和期望。

本文的目标并不是教授如何进行项目管理。这方面有许多很好的书、杂志和研讨班。本文或本文的参考书目中将列出一些。本文将介绍如何回答有关应聘问题的方法和思路。你可以根据自己的经验，观察其他项目经理，应聘职位的岗位描述对答案进行组织。无论被问到什么问题，无论你如何回答，记住运用一个项目经理最有用、最重要的特性…….常识。

什么是真正的项目管理

任何成功的项目都不可能是某一个人的功劳。一个成功的项目是多个部门的众多人员共同努力的结果。这些人，组成一个项目团队，具有不同技术水平，才能，工作风格和知识。

项目团队需要有一个共同目标，共同的前景，并且清楚的知道他们要做的工作。该团队，无论采取何种报告结构，必须能够很好地工作和激励以达到商业目标。

项目经理是项目团队的领导。他/她的职责是激励团队以积极的方式完成任务。该职位需要具有技术和人际技能，需要每天关注的内容（顺序如下）如下：


业务
公司
项目
团队
个人
技术和方法的变更


项目经理的技能应包括技术技能和管理技能，坚实的技术基础能够在技术方面对团队起指导作用，管理技能有助于沟通和解决问题。

管理技能不仅限于技术方面，还包括解决问题的能力，估算能力，编制计划的能力，人际和沟通能力。

你可能已经意识到自己忽视或缺乏某些领域的知识。因此，本文的读者为：


没做过项目经理的人
已经是项目经理，但认为自己的技能已经过时的人


项目经理是什么


项目经理角色


项目管理是估算、计划编制、重组、整合、评估和修正等过程的不断重复，其中包括管理人员，用户参与和解决问题，直至达到项目的商业目的。


管理层需要什么样的人


每个经理都在找有能力完成某一商业目标的人。最困难的是要了解他们懂什么和能做是么。比较困难的是，不知道需要多少人。

因此，你必须使招聘人员认为你是真诚可靠的。这不仅限于项目范围内，还包括与管理层和客户保持联系。

管理是指无论在有利或不利的环境中都能应对自如。在问题没有被详细表述或没有可选的解决方案时，你必须表现出你的管理才能。如果你让管理层来解决所有的问题，那要你还有什么用，管理层正在做你做的工作呢。


人员管理技能


了解人们的心理和他们的工作方式是项目经理必需的素质之一。每个人都不同。通过了解你的和别人的工作方式，可以缓解压力，便于沟通。

IBM多年来的口号是“尊重每一个人”。这具体表现为了解你日常工作中接触的人。要做到这点，你必须了解你自己并且知道你是如何激励别人或对别人施加压力的。

阅读迈尔斯-布里格斯（Myers-Briggs）人格类型分析方面的书籍是一个很好的开端。Katherine Briggs和她女儿Isabel Briggs-Myers制作的问卷（MBTI迈尔斯-布里格斯人格类型定向）用于帮助人们发现他们的个人风格及对团队产生的影响。该问卷是在Carl Jung的“心理类型”基础上发展而来的。此类书在书店有关自我提升和心理学的分类中均能找到。

你应该理解个人工作风格，并且牢记这些实践经验。以下所列的项目应该成为与人相处的第二种本能。也是每个想成功的项目经理必备的常识：


尊重每一个雇员（供应商）
虚心倾听
做出见识广博的决策
不要当众批评别人
了解自己的实力和做事的先后顺序
真诚地听取团队成员的意见和建议
对目标和交付产品有清楚的了解
在IT团队中提倡合作和信息共享
了解每个人的做事风格及他们的优缺点
表扬应以团队成员喜欢的方式，真诚地表达
将负面影响视为成长的机会
以积极的方式提供指导


你不能管理你无法控制的东西

如前所述，项目管理是执行一系列可重复的任务以完成某个商业目标。为了完成任务，你必须建立控制体系。因此，应对下列方面的问题有所准备：

度量方法：度量方法如果没有管理好或运用好，会产生负面影响。度量方法可以作为计划编制的“输入”，可以在项目进展过程中和结束时进行统计，为下一个项目或项目的下一个阶段提供参考。用度量方法来评估员工的绩效是不恰当的。

项目计划：通过制定项目计划能够得到正在执行的任务的关键检查点。这些检查点是达到商业目标的路标。要记住项目计划不仅只对新的开发项目有用。他们在支持和维护中同样重要。许多项目经理都犯同样的错误，他们编制一个十分出色的计划，但从不付诸实施。事实上，他们很少按计划进行工作。

预算：估算和编制计划的同时要做预算。许多项目经理要制作和管理他们自己的预算。如果你能使实际工作进展和计划一致，那么你的工作就会变得比较简单。大多项目管理工具都具有使费用（按小时，天，或年计）与某个资源相关。许多公司的财务部门认为的资源费用包括企业一般管理费用。另外一些公司可能根据项目名称或用户，管理方式，员工和顾问分别计算。（对于顾问，还要考虑他们的加班费）设备费用也要单独考虑。记住还要考虑运行项目应用所需的软件工具和硬件。（例如销售部门的彩色打印机）

员工工作计划：人是任何项目中有价值的。一个人可以促进项目成功或项目进展顺利，也可能对项目产生破坏。员工工作计划能对员工的成长起到建设性和实际作用。大多组织有自己的格式。但无论形式如何，下列事项必须包括：


职责明确
客观地评价员工的优缺点
为员工提供参与制定其发展方向和对其进行评估的机会


项目管理的奖励/压力

项目经理的角色是一柄双刃剑。这个职位要承担一定的压力，也会得到相应的奖励。一旦你成为项目经理，就必须对这两方面做好准备。

成功地完成一个系统，每个人都会得到奖励。能够帮助员工开发他们的潜能是项目经理特有的回报。在任何任务中，人都是最重要的元素。通过运用自己的管理技能造就了一个充满活力的团队，是一件值得骄傲的事。

人员同样是最大的压力。人毕竟会受到那些不受你控制的事物的影响。团队成员的家庭困难，彼此间的个性冲突都需要项目经理来处理。

任何有关应用或团队成员的事情首先要找的就是项目经理。上层领导和用户认为你是对项目的拖延、需求的遗漏、系统中的bug和不正确等唯一的负责人。
本文的参考目录中列出了许多能得到有效的管理实践信息的地方。去寻找管理方面的书籍，包括技术管理和商业管理两个方面。阅读管理大师，例如：Peter Drucker，C. A. Gallagher和A. Maslow写的书和文章。他们提供了在任何领域都使用的管理知识。信息管理大师例如：Tom DeMarco, M. Page-Jones, Ed Yourdon, L. L. Constantine等等提供了许多条理清楚的、经过实践检验的方法。

如果你要同用户一起工作，要阅读一本有关领域的专业书籍。了解业务比了解技术环境更重要。事实上，让用户参加面试过程越来越流行。要准备得更充分，可以买一本《哈佛商业评论》（Harvard Business Review）这是一本很好的杂志，适用于商业读者同样也适用于IT管理。许多IT杂志例如《CIO杂志》及在参考书目中列出的书目中都有有关项目管理和人员管理方面的文章。这些杂志中还包括概括或详细的技术性文章。

可以和美国管理协会（AMA）和其他商业组织取得联系，获取管理信息。值得一提的是，卡奈基梅隆大学的软件工程研究所（SEI）在90年代提出的管理软件过程，最新标准版本为SEI9000。

许多技术研讨会，例如数字咨询和技术转换研究所（Digital Consulting and Technology Transfer Institute）有许多不同领域的项目管理和技术研讨会。另一种途径是通过你所在的组织。他们也许会提供有关授权、谈判和倾听技巧等的课程，所有这些都有助于你准备项目管理。


你应该了解的软件


掌握一种项目管理工具。例如微软的Project和Applied Business Technology/Project Workbench。所有这些工具都有许多有效的项目管理方法和术语字典。

除了上述提到的工具外，还有一个越来越流行的工具可以针对不同技术环境中的项目在计划编制、费用估算和管理方法上提供帮助。这个工具就是LBMS/Process Engineer，具有CASE界面的工具。

如果你使用过此类工具，把这些内容列在你的简历中。当然，不仅要掌握工具，你还必须具有坚实的基础知识和项目管理方法。

一个项目经理必须足智多谋。通过email进行通信已经取代了电话和邮寄备忘录。许多公司有自己的系统，还有许多公司使用Lotus Notes。无论是用何种产品，必须具有如下性能：


能够与处于不同地理位置的人取得联系
能够有效地通知团队（包括供应商）范围，进度的变更
能很快地解决小问题


要记住人们工作方式的差别，性格内向的人更愿意通过email沟通。这样他们可以有时间思考问题的答案而不是在会议上立刻做出答案。

作为一个项目经理，你可能会作报告（report）和介绍(presentation)。因此，需要掌握字处理软件和图形软件。这些软件在市场上都可以买到。在你的简历上列出你会使用的此类软件。


寻找思想


任何行业都有好的项目经理和差的项目经理。你可以从两种项目经理身上得到启示（什么是应该做的而什么是应该避免的）。如有可能，问一些优秀的项目经理他们是如何做的。如果你对你的职业发展道路还不太清楚，你可以拿一篇刚刚读过的有关文章，问问这些项目经理对此文的观点。

一个成功的项目经理的标志有拥有一支气氛融洽的积极的团队，上层领导的信任和用户的尊重。一致的行动是另一个标志，它是衡量领导能力的基础。优秀的项目经理应该了解每个雇员的长处和短处。他们认为失败并不是缺点，而是一次学习机会。

项目经理必须建立一套专业标准。但按照一套完美的例子来进行管理却是一个失败的项目经理。这虽然说明他们的多才多艺，但更体现了他们在授权和沟通方面的能力不足。使原来想积极工作的员工变得消极的做法可以毁了项目经理。你在技术方面的能力应该用于指导和培训员工。如果你参与编程或设计，你不是在开发你的团队，也不是在做项目经理。


项目计划技术


以下是在面试中通常会提到的有关项目计划编制的术语和图表。大多项目计划编制工具都会使用到一些或全部术语和功能。你应该复习一下有用的一个或多个项目管理工具，这有助于你进一步熟悉常用的技术和功能。


图表类型：


甘特图：用图形，特别是条形图，描述项目进度的图表。每一个条形符号代表不同的意义。例如：关键任务的条形符号及/或颜色可能与非关键任务的不同。概要任务（活动或阶段）的符号可能于其他任务不同。

Pert图：用流程图来表示所有任务的现行依赖关系。PERT的意思是计划评价与审查技术，是一种网络图。

任务列表：文本/纵向地列出项目计划。通常至少应包括以下栏目：任务编号，任务名称，开始日期，结束日期，持续时间和工作效率。

工作分解结构：项目任务和/或活动的结构图。

关键路径：是贯穿整个项目的一条路径，表明在限定的时间成功完成项目涉及的各任务间的依赖关系。调整关键路径上任务的时间进度将会影响整个项目的交付时间。关键路径方法（CRM）图是一种网络图，用于项目的进度控制和协调项目的活动和事件。

可交付成果：证明一个或多个任务完成的有形事物。例如：逻辑数据模型。

依赖关系：任务间的联系会影响一个或多个任务的开始时间。例如：在没有弄清需求前，不能开始编程。

JAD/简化方法：联合应用程序设计(简化方法是90年代的术语)。一套面向结果的,大脑风暴式的,有一个共同的商业目的信息集合/分享会议。该方法是IBM公司在1970年开发的，由固定的，结构化的过程组成，并在一个有经验的实施者的领导下进行。简化方法去掉了一些结构,然而,仍要求所有各方都必须参加所有的会议和一个有建模技术的记录员作记录。参加者们包括项目团队,管理(与用户)和行政官员。为会议的成功，每个人必须理解和同意目的并且尽快解决他们的任务。

延迟：是任务的结束时间和与其相关的任务的开始时间之间的延迟时间。这允许任务结束时间和开始时间的重叠和拉长。

方法论：一种明确的、有组织的、可重复的、结构化的方法/技术，以完成一个通用的目的。这些技术或指南定义步骤，任务，角色，目的和可交付成果，这些是任何系统的成功的实现所必须的。

衡量标准：一个一致并且可重复的测量一个项目的大小和复杂性的方法。标准准备在整个项目生命期中使用许多方法中的一个。今天公司使用的流行方法是：

a) 功能点（Allan Abrecht）

b) 重要事件 (Tom DeMarco)

c) 加权平均

d) 代码行

里程碑：在项目生命期的一个重要的事件的结束。通常一个里程碑是在关键的路径上的一项活动。它不必是一个有形的可交付产品例如一个逻辑数据模型，但可以是用户对工作成果的肯定。

阶段/活动/摘要标题：概要级的概念。不是所有的项目管理工具都强调特定的阶段和摘要一级的格式，然而许多标准的开发方法用这些术语进行工作分解。

RAD：快速的应用开发(如果不正确地使用会有破坏作用)。通过应用程序生成器，建模和快速原型工具的使用加快开发工作的一条途径。最大的改进是在整个开发生命周期中加入快速原型。这在编码前了解清楚用户需求提供优秀的工具。

资源限制：一个基于可得到的资源的数量，每个资源的技巧的水平，资源工作时间表而开发的计划和时间表。

范围变更：对原先设计要求的功能增加而没有对人员，时间或费用的影响进行评估。范围变更可能是一个商业用户或一个热心的程序员提出的。两者影响系统的交付并且不能被估计，分析，或记录。

面试中的表达的要点(就算问题没被问)


如果你没有管理经验


对于那些从未正式管理过一个项目的，可能是非正式地管理过的人。在那些情况中，当强调他们的技术背景优势的同时需要明确说明他们没认识到他们已掌握的那些技巧。你可以提及你是怎么不得不在没有授权的情况下领导一个大型的开发团队进行工作的。需要强调的是没有一个稳固的技术的基础,你的工程任务和估计的决定可能被过分简单化。当你是项目的领导人，你需要提供技术的连贯避免团队超负荷工作。


如果你的技术技巧在未来的技术的环境中是落伍或不同的


你不需要理解技术环境的内部是如何工作的，但是你应该理解一般的概念和特征决定环境的能力和弱点。许多项目管理技巧是超出技术范围的。因此,如果你的技术技巧是落伍的，你仍然能强调你在技术上能负独立责任。提及你管理的应用类型和及其商业作用。提及团队是如何有效地完成目标的。强调你的管理哲学。提到上级，与你地位同等的人，你的用户和部下是如何评价你的管理能力的，记住提起任何你掌握的商务领域知识。在面试时应该将你对你的技能落后的恐惧抛在一旁。一旦你拥有这个工作，你将能向公司内的专家询问。在所有组织中都有各方面专家的非正式的机构。你可以到处打听一下，把他们找出来。

问面试官的问题：

即使你通过面试，得到了这个职位，你还需要信息进行估价，这时是你的好机会。如果这将是项目经理的第一个工作任务，这尤其是关键。你需要明白你的工作环境。因此，你可以问下列问题：

1. 公司优先权是什么？

2. 本项目的执行资助者是谁？

3. 公司使用的开发原理体系是什么？

4. 本项目最后期限是什么？

5. 有量度项目成功的方法吗？

6. 你的新经理将怎样保持项目信息灵通？

7. 你的新经理管理哲学和风格是什么？

8. 项目上的人们的技能水平是什么？

9. 你将管理的项目的范围被充分地定义吗？

10. 技术环境已经选好了吗？

以下是典型的项目管理面试中通常会问到的问题（期望的回答）：

很多的问题的答案是主观的，面试官想知道你的观点是否和他们的及公司一致。问题的构成如下：

1. 项目管理软件工具知识，

2. 编制项目计划的技术，

3. 人员管理技能

4. 沟通技能

5. 原理体系知识（标准开发生命周期和项目管理）。

项目管理软件工具知识

问题1：工期和工作量之间的差异是什么？

答案1：工期是商业/日历上的天数，与人数和工作量无关。工作量是与日历天数无关的人的工作。例如：

一天的工作量对于一个一只花50%在时间在上面的人来说，他的工期就是两天。如果两个人全职工作，工期是1天，而工作量是两个工作日。

问题2：怎样和为什么要在编制项目计划时考虑依赖关系？

答案2：根据使用的软件包，依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另一个任务能开始之前有一个任务必须完成。例如，逻辑模型必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如果没有完成的程序对线性测试没有影响。

项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。

问题3：你怎样将人的工作步调与计划结合？

答案3：根据组织使用的具体的工具，可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。

问题4：你怎样将培训，假日和个人教育时间表结合起来？

答案4：每个产品都有标明不工作的天数的公司/全球的日历。每个产品都也有个人的资源日历标明个人不工作的时间。如果项目需要教育和培训，应该把它们象任务那样写在项目计划上。

问题5：你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务？

答案5：它的工期将和整个项目时间一样长，占工作量的百分比很小。被分配给任务的每个人花在该任务的时间占他时间的百分比极低。

问题6：实况报告对计划的作用以及实况与最初预计的比较有何价值？

答案6：根据组织使用的特定的工具，每个工具都为实况报告中输入相互独立的要素/域信息。也可以将报表进行分类，来向团队成员和其他相关团体说明关键路径的变化或时间表的调整。这些报告对已实现工作评价和作为在计划下一个工程或阶段的输入有价值。另一个把估计和实况报告比较的有价值的用途是把范围变更对项目的影响记录下来。

做项目计划的技能

问题7：你为什么制定项目计划？

答案7：项目计划是实现成功的系统的路线图。它提供了一种手段来通知每个人希望他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项目状态和调整特殊的资源。逐项列记的“一览表”协助对任何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供了有用的信息。

问题8：你将怎样着手做项目的计划？

答案8：进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制约做成文件。差的估计源于对业务知识和项目范围缺乏了解。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识别和文档化里程碑和可交付产品。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对项目经理，开发团队，支持团队，以及管理层，商业用户都有益处。

问题9：你将怎样着手制定项目计划？

答案9：在适当的活动和阶段或其他的概括的标准说明下，输入确定的任务。将适当的可交付产品及里程碑和特定的任务联系起来。连接全部需要依赖关联的任务。把资源角色或资源名字加到每个任务上。应用度量结果确定事先的任务工作量，把更多的时间用于需求收集，设计和测试。考虑所有已知的节假日，培训，休假或其他的资源停工时间。计划草案将同支持团体，管理层和商务用户一起复查，做为补充性的输入和最终的批准。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 17 Feb 2008 12:13:26 +0800 http://zenggongli.javaeye.com/blog/162761 http://zenggongli.javaeye.com/blog/162761 Java Web层框架比较 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/162697  发表时间: 2008年02月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

这是Matt Raible在今年6月24-27号召开的JA-SIG夏季会议上所作的主题演讲，Matt从众多方面对Java Web层框架做了一个全面、深入的比较。笔者认为这是一份及时的文档，它对开发者如何判定一个Web层框架的好坏、如何选择适合自己项目的框架有极大的指导作用。本文是对Matt Raible演讲稿的整理归纳。
【作者介绍】Matt Raible，开源框架AppFuse的发起者、主要开发者；《Professional JSP 2.0》、《Spring Live》等书的作者；众多会议的演讲者，MySQL User Conference, ApacheCon, ApacheCon EU等；现任Raible Designs的CEO。

首先，Matt以自己的实践经验，指出了Java Web层框架——JSF、Spring MVC、Stripes、Struts 2、Tapestry和Wicket他们各自的优、缺点：
JSF
优点：
Java EE标准，这意味着有很大的市场需求和更多的工作机会
上手快速并且相对容易
有大量可用的组件库
缺点：
大量的JSP标签
对REST和安全支持不好
没有一个统一的实现。既有SUN的实现，又有Apache的实现——MyFaces。

Spring MVC
优点：
对覆盖绑定（overriding binding）、验证（validation）等提供生命周期管理
与许多表示层技术/框架无缝集成：JSP/JSTL、Tiles、Velocity、FreeMarker、Excel、XSL、PDF等
便于测试——归功于IoC
缺点：
大量的XML配置文件
太过灵活——没有公共的父控制器
没有内置的Ajax支持

Stripes
优点：
不需要书写XML配置文件
良好的学习文档
社区成员很热心
缺点：
社区比较小
不如其他的项目活跃
ActionBean里面的URL是硬编码的

Struts 2
优点：
架构简单——易于扩展
标记库很容易利用FreeMarker或者Velocity来定制
基于控制器或者基于页面的导航
缺点：
文档组织得很差
对新特征过分关注
通过Google搜索到的大多是Struts 1.x的文档

Tapestry
优点：
一旦学会它，将极大地提高生产率
HTML模板——对页面设计师非常有利
每出一个新版本，都会有大量的创新
缺点：
文档过于概念性，不够实用
学习曲线陡峭
发行周期长——每年都有较大的升级

Wicket
优点：
对Java开发者有利（不是Web开发者）
页面和显示绑定紧密
社区活跃——有来自创建者的支持
缺点：
HTML模板和Java代码紧挨着
需要对OO有较好的理解
Wicket逻辑——什么都用Java搞定

接着，Matt通过采访这些框架的作者，与他们讨论各种开源的Java Web框架，并且突出各个框架的长处、听取框架作者对其他框架的看法，希望借此了解这些框架的未来发展方向。

下列是一些被采访者：
JSF, Jacob Hookom
RIFE, Geert Bevin
Seam, Gavin King
Spring MVC, Rob Harrop
Spring Web Flow, Rob Harrop and Keith Donald
Stripes, Tim Fennell
Struts 1, Don Brown
Tapestry, Howard Lewis Ship
Trails, Chris Nelson
Struts 2, Patrick Lightbody
Wicket, Eelco Hillenius

Matt对采访做了如下总结：
JSF:
如果你想让web应用具有类似桌面程序的功能性，那么JSF的标准规范和大量第三方组件库的支持值得你 信赖。
Spring MVC:
综合了许多不同的技术，这使得它可以被广泛地应用到不同类型的项目中去；它可以被当作web应用开发的一个基础平台。
Stripes:
可以被应用到存在大量复杂数据交互的程序中；有强大的类型转换、绑定和验证功能；可以使管理大的复杂表单以及直接映射它们到域对象变得简单……
Tapestry:
在中到大型项目中，表现突出（当然，你也可以只把它应用到单个页面上），在这些项目中，你可以通过简单地创建新的组件起到杠杆作用。
Struts 2:
通常更适合于那些希望可以真正开始做事并且愿意花费大量时间来学习他们使用的开源工具的小项目组。Struts 2的目标不是那些更喜欢拖放式开发的“扶手椅程序员”。
Wicket:
非常适合于这样的内/外部网应用：UI很复杂并且你希望可以充分利用你的开发者资源。

上面的总结，基本是突出了各个框架的长处。然而，哪些又是他们不好的地方呢？

Matt提出了评价一个框架好坏与否的标准：
Ajax支持 是不是内置了？是否便于使用？
书签能力 用户能否将某个页面收藏起来并且可以方便地返回到该页面？
验证 使用是否简单？是否支持客户端（JavaScript）验证？
可测试性 脱离容器测试控制器，是否足够简单？
提交和重定向 框架如何处理重复提交问题？
国际化 如何支持国际化？控制器利用国际化信息，是否容易？
页面修饰 框架支持哪种类型的页面修饰/组成机制？
社区和技术支持 提出问题，能否被快速地、恭敬地回答？
开发工具 是否有支持这个框架的好的工具，尤其是IDE？
市场需求 学习了这个框架，它能否帮你找到份工作？
岗位数量 在dice.com和indeed.com上，对这个框架技能的需求如何？

笔者认为这个评价标准，值得大家借鉴。

然后，Matt按照这些评价标准，对各个框架做了以下阐述：
Ajax支持
JSF：没有内置的Ajax支持，需要使用ICEfaces和Ajax4JSF
Stripes：没有对应的类库，支持流输出
Struts 2：内置Dojo，有用于GWT和JSON的插件
Spring MVC：没有对应的类库，需要使用DWR和Spring MVC扩展
Tapestry：Tapestry 4.1中，有内置的Dojo
Wicket：有Dojo和Script.aculo.us支持

书签能力
JSF：可以任意提交——URL甚至不被考虑
Stripes：使用约定，但是你可以不加理会
Struts 2：有命名空间的概念，这使得收藏某个页面并返回变得容易
Spring MVC：允许完全的URL控制
Tapestry：依然存在一些丑陋的URL
Wicket：允许装配（mount）页面/URL

验证
JSF：默认的国际化信息丑陋，但是配置简单
Stripes和Wicket：用Java类进行验证——不支持客户端验证
Struts 2：使用OGNL完成强大的表达式验证功能；只有在Action上指定了规则，才支持客户端验证。
Spring MVC：允许你使用公共验证器——这是一种成熟的解决方案
Tapestry：有健壮的验证功能——不需自定义就有漂亮的国际化信息

可测试性
Spring MVC和Struts 2：允许利用mocks（例如EasyMock、jMock和Spring Mocks）简单地进行测试
Tapestry：测试困难，因为页面类被抽象、具体类被简化
JSF：页面类可以方便地被测试，实际上很像Struts 2 中的actions
Wicket：有WicketTester——一个强大的解决方案
Stripes：有Servlet API Mocks和MockRoundtrip

提交和重定向
解决重复提交问题的最简单方法是：在提交后重定向
Spring MVC：允许你将参数加到重定向URL上
Stripes、Tapestry和Wicket：有“flash式”的支持
Struts 2：需要一个自定义的解决方案
JSF：需要一个自定义的解决方案，国际化信息很难加入到页面bean中

国际化
JSTL的<fmt:message>标签使国际化变得简单；如何将国际化信息放到控制器类中，还没有一个统一的标准。
Stripes、Spring MVC和JSF：每个地区使用一个资源绑定文件
Struts 2、Tapestry和Wicket：提倡把每个页面/action用到的资源文件分开
JSF：需要在每个页面上定义资源绑定信息
Tapestry：<span key="key.name">标签比较可怕

页面修饰
Tiles能够用于Struts 2、Spring MVC和JSF中；需要对每个页面进行配置。
SiteMesh能够用于所有的这些框架中（不推荐在JSF、Tapestry或者Wicket中使用）；在设置完成后， 只需要很少的维护。

开发工具
Spring MVC：Spring IDE，但是只做XML校验，不是一个UI/web工具
Struts 2：Eclipse
Tapestry：Spindle，对编码者非常有利
JSF：众多IDE支持，并且做得越来越好
Stripes和Wicket：没有任何官方工具
NetBeans目前支持Struts *、JSF（+Facelets）、Tapestry和Wicket，尚不支持Stripes和Spring MVC


市场需求
Struts 1：需求依然很大并且被广泛使用
Spring MVC：越来越受关注，但大部分是因为Spring框架的一些其他特征
JSF：很快地变得流行起来
Struts 2：正在获得地盘，但是相关的工作机会很少
Tapestry：在过去的数年里，受欢迎程度不断增加
Wicket和Stripes：还是未知数


通过以上的比较，我想大家对在自己的项目中应该选择哪种Web层框架，应该有了更清醒的认识。

最后，Matt列出了一些相关资源，也供读者参考。
Struts - http://struts.apache.org
StrutsTestCase: http://strutstestcase.sf.net
Spring MVC - http://www.springframework.org
Spring IDE: http://www.springide.org
Gaijin Studio: http://gaijin-studio.sf.net
Struts 2 - http://opensymphony.org/webwork
Eclipse Plugin: http://sf.net/projects/eclipsework
IDEA Plugin: http://wiki.opensymphony.com/display/WW/IDEA+Plugin
Tapestry - http://tapestry.apache.org
http://spindle.sourceforge.net
JSF - http://java.sun.com/j2ee/javaserverfaces and http://myfaces.apache.org
Java Studio Creator: http://sun.com/software/products/jscreator
MyEclipse: http://myeclipseide.com
IDEA: http://www.jetbrains.com/idea
SiteMesh: http://opensymphony.com/sitemesh
Testing Frameworks
JUnit: http://junit.org
EasyMock: http://easymock.org
jMock: http://jmock.org
jWebUnit: http://jwebunit.sourceforge.net
Canoo WebTest: http://webtest.canoo.com
Tapestry Test Assist: http://howardlewisship.com/blog/2004/05/tapestry-test-assist.html
AppFuse - http://appfuse.org

演讲的最后，Matt以一句“If it works, use it!”作为结尾，可谓精辟！

通过此文，相信大家可以拨开当前Java Web层框架选用上的“迷雾”，见得“月明”了。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 16 Feb 2008 23:01:37 +0800 http://zenggongli.javaeye.com/blog/162697 http://zenggongli.javaeye.com/blog/162697 采用Core J2EE Pattern架构的J2EE 系统，一天十亿次的访问 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/162636  发表时间: 2008年02月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

议程：

入门和Core J2EE Patterns

eBay.com三层架构的目标

关键架构和技术决策

eBay.com如何应用Core J2EE Patterns

结论





一、入门和Core J2EE Patterns

1、目标：

- eBay.com网站的架构

- 架构中模式的地位

- 使用 Core J2EE Patterns的好处



2、eBay介绍

（1）使命

1、全球交易平台

2、拍卖、定价、B2C、B2B



（2）统计数据

- 6900万注册会员

- 28000个分类，1600万商品

- 2002年营业额：148亿7千万美元

-全球社区

-每天十亿次访问量

- 1200多个URL



3、eBay旧的二层架构及其存在的问题

（1）ebay旧的二层架构

-集成在一起的两层架构（架构中各组件之间的耦合度高）

- 330万行C++ ISAPI DLL

-面向功能的设计

- Not for systemic qualities



（2）二层架构存在的问题

-阻碍商业创新（可扩展性不够）

-随着访问量增大，系统线性扩展性面临着挑战（无法通过仅仅增加硬件投入，扩充系统的支撑量）

-高额的维护成本

-不便于“重构”（代码很难通过重构来改善）

- Architects in constant Fire-Fighting Mode



4、2000年底开始三层架构改造



系统向分层、松散耦合、模块化、基于标准的架构过渡


5、ebay架构的改造是基于下面这本书介绍的模式
core J2EE Pattern 最佳实践和设计策略第二版，sun官方网站也提供core J2EE Pattern，见

http://java.sun.com/blueprints/corej2eepatterns/Patterns/





该书介绍了21 种J2EE设计模式，我们可以把他们归类到三层中。

（1）、表示层的设计模式：

- Intercepting Filter (X)

- Front Controller (X)

- Application Controller (X)

- Context Object (X)

- View Helper

- Composite View

- Service To Worker (X)

- Dispatcher View

带(X)表示这些设计模式在eBay.com的架构中采用了。





（2）、商业逻辑层的设计模式:

- Business Delegate

- Service Locator (X)

- Session Facade

- Application Service (X)

- Business Object (X)

- Composite Entity

- Transfer Object (X)

- Transfer Object Assembler (X)

- Value List Handler (X)

带(X)表示这些设计模式在eBay.com的架构中采用了。





3、集成层（也称为数据访问层） 设计模式:

- Data Access Object (X)

- Service Activator

- Domain Store (X)

- Web Service Broker (X)

带(X)表示这些设计模式在eBay.com的架构中采用了。





二、ebay三层架构的目标

1、目标

高可用性、高可靠性、可线性扩展，建立实现系统的无缝增长。

高开发效率，支持新功能的快速交付。

可适应未来的架构，应变将来商业的更新需求。

ebay的系统可用性2002年已到了99.92%.(令人叹服)，每季度网站新增十五个重大功能，

每个星期将近3万行代码在修改，3个星期内可以提供一个国际化版本。



2、为了可适应未来的架构，ebay采用了下面的做法

采用J2EE模式

Only adopt Technology when required

Create new Technology as needed

大量的性能测试

大量的容量计划

大量关键点的调优

Highly redundant operational infrastructure and the technology to leverage it



3、为了实现可线性扩展，ebay采用了下面的做法：

（1） 合理地使用server state

（2） No server affinity

（3） Functional server pools。

（4） Horizontal and vertical database partitioning。



ebay架构采用了服务器分块化的概念，每台服务器上的应用与它的use case有关，即server pool中的一部分服务器专门用于登陆，一部分服务器专门用于显示商品信息。毕竟不同use case访问数据库的方式不同，比如“显示商品信息”use case只是只读操作。而且由于是只读操作，数据库的压力会比较低，我可以只采用几台服务器来承担这部分操作，而更多的服务器用于读写操作多的use case，这样合理地使用服务器资源。

由于不同的应用放在不同的服务器上，这里就涉及到用户状态的复制问题。这就是第一条ebay要求合理地使用server state的原因，就我所知，ebay的用户状态只有很少保存在session中，ebay把用户的状态放到了数据库和cookie中。


4、为了使得数据访问可线性扩展

（1） 建模我们的数据访问层

（2） 支持Support well-defined data access patterns

Relationships and traversals

本地cache和全局cache

（3） 定制的O-R mapping—域存储模式

（4） Code generation of persistent objects

（5） 支持lazy loading

（6） 支持fetch sets (shallow/deep fetches)

（7） 支持retrieval and submit (Read/Write sets)



5、为了使数据存储可线性扩展，eBay采用了下列做法

（1）商业逻辑层的事务控制

只采用Bean管理的事务

Judicious use of XA

数据库的自动提交

（2）基于内容的路由

运行期间采用 O-R Mapping ，找到正确的数据源

支持数据库的水平线性扩展

Failover hosts can be defined

（3）数据源管理

动态的

Overt and heuristic control of availability

如果数据库宕机，应用可以为其他请求服务。





6、应变未来采用的技术

（1）消息系统

子系统之间、数据库之间松散耦合

J2EE的Message Driven Beans

（2）SOAP

对于外部开发者和合作伙伴，通过可用的工具和最佳实践来平衡我们的平台

采用SOAP 来标准化不同eBay应用之间进程内部的通信

采用SOAP满足我们的QoS需求





四、将J2EE的设计模式应用到eBay中

介绍了三个Use cases例子，“查看账号”，“查看商品”，“eBayAPI”，介绍了这三个use case 如何采用J2EE的设计模式实现其设计。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 16 Feb 2008 14:04:08 +0800 http://zenggongli.javaeye.com/blog/162636 http://zenggongli.javaeye.com/blog/162636 EJB编程及J2EE系统架构和设计 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/162634  发表时间: 2008年02月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

摘要：本文阐述了J2EE平台的所有主要技术，围绕J2EE规范所定义的四个层次：客户端层（Client Tier）、Web层(Web Tier)、业务层（Business Tier）及企业信息系统层（Enterprise Information System Tier），介绍J2EE所定义的丰富的技术标准及符合这些标准的开发工具和API，这些技术涵盖了组件技术、Servlets和JSP、EJB技术、数据库访问、分布式通信技术（Java RMI、Java IDL、JNDI、JMS）、安全等；本文试图给出J2EE平台技术概念理解上的一个较为清晰的完整的思路，帮助大家掌握各技术间的相互关系和重要的思想。

关键词：J2EE、JDBC、RMI、JNDI、JMS、EJB、Servlets、JSP、XML

Java 2平台有三个版本：它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java 2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）。其中最重要的就是J2EE平台。
J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如"编写一次、随处运行"的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。
J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。
J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:
保留现存的IT资产: 由于企业必须适应新的商业需求，利用已有的企业信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是公司所需求的。J2EE架构可以充分利用用户原有的投资，如一些公司使用的BEA Tuxedo、IBM CICS, IBM Encina,、Inprise VisiBroker 以及Netscape Application Server。这之所以成为可能是因为J2EE拥有广泛的业界支持和一些重要的'企业计算'领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。
高效的开发: J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务:
状态管理服务 -- 让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。
持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。
分布式共享数据对象CACHE服务 -- 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。
支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。
可伸缩性: 企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。
稳定的可用性: 一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE部署到可靠的操作环境中，他们支持长期的可用性。一些J2EE部署在WINDOWS环境中，客户也可选择健壮性能更好的操作系统如Sun Solaris、IBM OS/390。最健壮的操作系统可达到99。999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。
基于层次化组件模式的J2EE平台把业务逻辑和底层网络技术分离开来，具有可伸缩性、扩展性、易开发性和易维护性，已经成为企业级商业分布式网络计算的事实标准。J2EE是大量业内技术专家、教育专家集体智慧和经验设计出来的一套先进、完美、实用的规范，遵从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单、快速。学习Java，与其说是学一种技术，还不如说是在学习一种编程思想，而J2EE系统平台的思想是通过一个基于组件的应用程序模式为分布式应用程序提供一个统一的标准。



J2EE平台规范是一个由SUN公司定义的用于简化分布式企业级应用开发与部署的基于组件的模式（The J2EE Platform Specification defines a component-based model that simplifies enterprise development and deployment）。它提供了一个多层次的分布式应用模型和一系列开发技术规范。多层次分布式应用模型是根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组件，组件在分布式服务器的组件容器中运行（如Servlet组件在Servlet容器上运行，EJB组件在EJB容器上运行，容器间通过相关的协议进行通讯，实现组件间的相互调用。

J2EE组件和层次

J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议??通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层。

这四层分别是 运行在客户端机器上的客户端层（Client Tier）、 运行在Web服务器上的Web层（Web Tier）、 运行在EJB服务器上的业务层（Business Tier）和 运行在EIS服务器上企业信息系统层（Enterprise Information System Tier）其中Web层和业务层共同组成了三层J2EE应用的中间层，其他两层是客户端层和存储层或企业信息系统层。一般情况下，许多开放商把Web服务器和EJB服务器产品结合在一起发布，称为应用服务器或J2EE服务器。J2EE平台规范也定义了相应层的组件：
I. 客户端层组件
应用客户端程序和浏览器是客户端层组件。客户端层组件可以是基于Web方式的即作为Web服务器的浏览器,也可以是基于传统方式的(非基于Web方式)即独立的应用程序，可以完成瘦客户机无法完成的任务。
II. Web层组件
Java Servlet和JavaServer Pages(JSP)是Web层组件。如图2所示的客户层那样，Web层可能包含某些 JavaBean 对象来处理用户输入，并把输入发送给运行在业务层上的Enterprise Bean 来进行处理。按照J2EE规范，静态的HTML页面和Applets不算是Web层组件。这里的JavaBean和EJB（Enterprise JavaBean）除了共用“JavaBean”这个名字外，这两种组件模式完全没有关系。许多文章把EJB作为原始的“JavaBean”的扩展，这是错误的。EJB并没有扩展或使用JavaBean组件模式。最初的JavaBean（java.beans包）在进程内部（intraprocess）使用，而EJB（javax.ejb包）是在进程间(interprocess)使用的组件。即最初的JavaBean不是为分布式组件而设的。它是最好的组件模式，可能是至今发现的最好的过程内部开发的组件模式，但它不是一个服务器端的组件模式。EJB则能解决在三层结构中由管理分布式商务对象多带来的问题。

III. 业务层组件
Enterprise JavaBeans(EJB)是业务层组件。业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要,由运行在业务层上的EJB 进行处理。 EJB从客户端程序接收数据，进行处理(如果必要的话), 并发送到企业信息系统层(EIS) 层储存的，这个过程也可以逆向进行。
有三种企业级的Bean: 会话(Session)Beans, 实体(Entity) Beans, 和 消息驱动(Message-driven) Beans。 会话Bean 表示与客户端程序的临时交互。 当客户端程序执行完后, 会话Bean 和相关数据就会消失。相反, 实体Bean 表示数据库的表中一行永久的记录。 当客户端程序中止或服务器关闭时, 就会有潜在的服务保证实体Bean 的数据得以保存。消息驱动Bean 结合了会话Bean 和 JMS的消息监听器的特性, 允许一个业务层组件异步接收JMS 消息。

IV. 企业信息系统层组件
处理企业信息系统软件包括企业基础建设系统例如企业资源计划 (ERP), 大型机事务处理, 数据库系统,和其它的遗留信息系统组成了企业信息系统层。 例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。

J2EE的分布式应用技术简介

J2EE平台由一整套服务（Services）、应用程序接口（APIs）和协议构成，它对开发基于Web的多层、分布式应用提供了功能支持：
（1） 组件/容器技术
如图4所示这种基于组件，具有平台无关性的J2EE 结构使得J2EE 程序的编写十分简单，因为业务逻辑被封装成可复用的组件，并且J2EE 服务器以容器的形式为所有的组件类型提供后台服务。 因为你不用自己开发这种服务, 所以你可以集中精力解决手头的业务问题。

J2EE应用组件可以安装部署到以下几种容器中去:
EJB 容器管理所有J2EE 应用程序中EJB 的执行。EJB和它们的容器运行在J2EE 服务器上。
Web 容器管理所有J2EE 应用程序中JSP页面和Servlet组件的执行。 Web 组件和它们的容器运行在J2EE 服务器上。
应用程序客户端容器管理所有J2EE应用程序中应用程序客户端组件的执行。 应用程序客户端和它们的容器运行在客户端机器上。
Applet 容器是运行在客户端机器上的Web浏览器和 Java 插件的结合。
容器设置定制了J2EE服务器所提供的内在支持，包括安全，事务管理，JNDI(Java Naming and Directory Interface)寻址,远程连接等服务，以下列出最重要的几种服务：
J2EE安全(Security)模型可以让你配置Web 组件或EJB ,这样只有被授权的用户才能访问系统资源。 每一客户属于一个特别的角色，而每个角色只允许激活特定的方法。你应在EJB的布置描述中声明角色和可被激活的方法。由于这种声明性的方法，你不必编写加强安全性的规则。
J2EE 事务管理（Transaction Management）模型让你指定组成一个事务中所有方法间的关系，这样一个事务中的所有方法被当成一个单一的单元。当客户端激活一个EJB中的方法，容器介入一管理事务。因有容器管理事务，在EJB中不必对事务的边界进行编码。要求控制分布式事务的代码会非常复杂。你只需在布置描述文件中声明EJB的事务属性，而不用编写并调试复杂的代码。容器将读此文件并为你处理此EJB的事务。
JNDI 寻址(JNDI Lookup)服务向企业内的多重名字和目录服务提供了一个统一的接口,这样应用程序组件可以访问名字和目录服务。
J2EE远程连接（Remote Client Connectivity）模型管理客户端和EJB间的低层交互。 当一个EJB创建后, 一个客户端可以调用它的方法就象它和客户端位于同一虚拟机上一样。
生存周期管理（Life Cycle Management）模型管理EJB的创建和移除,一个EJB在其生存周期中将会历经几种状态。容器创建EJB，并在可用实例池与活动状态中移动他，而最终将其从容器中移除。即使可以调用EJB的create及remove方法，容器也将会在后台执行这些任务。
数据库连接池（Database Connection Pooling）模型是一个有价值的资源。获取数据库连接是一项耗时的工作，而且连接数非常有限。容器通过管理连接池来缓和这些问题。EJB可从池中迅速获取连接。在EJB释放连接之后可为其他EJB使用。
（2） Servlets和JSP
JSP(Java Server Pages): JSP页面由HTML代码和嵌入其中的Java代码所组成。服务器在页面被客户端所请求以后对这些Java代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。
Java Servlet: Servlet是一种小型的Java程序，它扩展了Web服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI Perl脚本很相似。Servlet提供的功能大多与JSP类似，不过实现的方式不同。JSP通常是大多数HTML代码中嵌入少量的Java代码，而servlets全部由Java写成并且生成HTML。
（3） EJB技术
EJB(Enterprise JavaBean): J2EE技术之所以赢得某体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑，由此很显著地简化了具有可伸缩性和高度复杂的企业级应用的开发。EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务，例如目录服务、事务管理、安全性、资源缓冲池以及容错性。但这里值得注意的是，EJB并不是实现J2EE的唯一途径。正是由于J2EE的开放性，使得有的厂商能够以一种和EJB平行的方式来达到同样的目的。
（4） 数据库访问
JDBC(Java Database Connectivity): JDBC API为访问不同的数据库提供了一种统一的途径，象ODBC一样，JDBC对开发者屏蔽了一些细节问题，另外，JDCB对数据库的访问也具有平台无关性。
（5） 分布式通信技术及分布示应用技术
JNDI(Java Name and Directory Interface): JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP，本地文件系统，或应用服务器中的对象。
RMI(Remote Method Invoke): 正如其名字所表示的那样，RMI协议调用远程对象上方法。它使用了序列化方式在客户端和服务器端传递数据。RMI是一种被EJB使用的更底层的协议。
RMI-IIOP:它在Internet Inter-ORB Protocol（IIOP）之上提供了通常的Java Remote Method Invocation(Java 远程方法调用RMI)API的一种实现。它在RMI和CORBA应用程序之间架起了桥梁。这是在J2EE容器之间使用的一种标准通信协议。
Java IDL/CORBA: 在Java IDL的支持下，开发人员可以将Java和CORBA集成在一起。 他们可以创建Java对象并使之可在CORBA ORB中展开, 或者他们还可以创建Java类并作为和其它ORB一起展开的CORBA对象的客户。后一种方法提供了另外一种途径，通过它Java可以被用于将你的新的应用和旧的系统相集成。
JMS(Java Message Service): JMS是用于和面向消息的中间件相互通信的应用程序接口(API)。它既支持点对点的域，有支持发布/订阅(publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。
JTA(Java Transaction Architecture): JTA定义了一种标准的API，应用系统由此可以访问各种事务监控。
JTS(Java Transaction Service): JTS是CORBA OTS事务监控的基本的实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持Java Transaction API (JTA)规范，并且在较底层实现OMG OTS specification的Java映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。
JavaMail: JavaMail是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器，也支持IMAP服务器。
JAF(JavaBeans Activation Framework): JavaMail利用JAF来处理MIME编码的邮件附件。MIME的字节流可以被转换成Java对象，或者转换自Java对象。大多数应用都可以不需要直接使用JAF。
JAXP(Java API for XML Paring)：这个API为XML解析器和API的转换提供了抽象。JAXP可以帮助把特定的XML解析器、XML Document Object Model（文档对象模式，DOM）实现或者把XSLT转换成API与J2EE 应用程序代码隔离。
JCA(Java Connector Architecture)：这个API最近已经包含在J2EE中，提供了一种把J2EE应用程序组件集成到老式信息系统中的途径。
JAAS（Java Authentication and Authorization Service）：这个API为J2EE应用程序提供了验证和授权机制。
XML(Extensible Markup Language): XML是一种可以用来定义其它标记语言的语言。它被用来在不同的商务过程中共享数据。XML的发展和Java是相互独立的，但是，它和Java具有的相同目标正是平台独立性。通过将Java和XML的组合，您可以得到一个完美的具有平台独立性的解决方案。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 16 Feb 2008 14:01:48 +0800 http://zenggongli.javaeye.com/blog/162634 http://zenggongli.javaeye.com/blog/162634 WebLogic Server 性能调优 marszgl 作者: marszgl  链接：http://zenggongli.javaeye.com/blog/162633  发表时间: 2008年02月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。

性能监控及瓶颈发现

性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分――网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。

WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台提供的性能监控的选项之一。

代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如：Wily Introscope, Jprobe, Optimizelt。

EJB 容器

EJB容器中最昂贵的操作当然是数据库调用――装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样，除非是在特殊情况下，否则在每个bean的每次交易中，至少都得有一次装载操作和一次存储操作。这些特殊情况是：
1． Bean是只读的。此时，bean只需在第一次访问时装载一次，从来不需要存储操作。当然，如果超出参数read-timeout-seconds的设置，bean将被再次装载。

2． Bean 有专门的或积极的并发策略，且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。

3． Bean在交易中未被修改过，此时，容器会将存储操作优化掉。

如果不属于上述任何一种情况，则code path中的每个实体bean在每次交易时，至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销，如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等,其中的某些特征是WebLogic Server 7.0新增的。




高速缓存：实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。

域分组：域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域（比方说，一幅图像）相联系，且很少被访问，则可以定义一个将此域排除在外的域组，该域组与一个查找方法相关联，这样查找时，BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。

并发策略：在WebLogic Server 7.0中，容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施，它的主要目的是确保实体bean所表示的数据的一致性，该一致性由bean的部署器所强制要求。无论如何，某些控制机制使得容器处理请求的速度比其它的要快一些，但这种快速是以牺牲数据的一致性为代价的。
最严格的并发策略是独占式，利用特殊主键对bean的访问是经过系列化的，因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行性。

数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。

积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。 本特征也只对EJB 2.0 适用。

只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载。


紧密关联缓存： 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。

除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。

缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean（SLSB），消息驱动bean（MDB）以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数（事实上，要求比此数要小）。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连（没有主键）。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。

高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。

EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作：传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活（activation）。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活（activation）。

JDBC

对数据库的访问来说，调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小――连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现，则连接数应为执行队列中的线程数，比读取socket的线程（缺省执行队列中用来读取进入请求的线程）数要少。为了避免在运行期间对连接进行创建和删除，可在初始时即将连接池设置为其最大容量。如果可能的话，应确保参数TestConnectionsOnReserve被设置为假（false，这是缺省设置）。如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接。

另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存，大小由JDBC连接池配置时指定。缓存是静态的，时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话，则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能，但也不能盲目使用它。如果数据库的格式有了变化，那么在不重新启动服务器的情况下，无法使缓存中的语句失效或者是用新的进行替换。当然，缓存中的语句会使数据库中的光标得以保留。

对于WebLogic Server 7.0来说，由于jDriver性能的改进已使其速度远远快于Oracle的廋驱动程序，尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明（http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance）。

JMS

JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此，JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”，反过来也不会抢夺其它应用的资源。对JMS来说，大多数的调试参数都是在服务的质量上进行折衷处理。如，利用文件式持续性目的地（file-persistent destnation）禁止同步写操作（通过设置特性： －Dweblogic.JMSFileStore.SynchronousWritesEnabled =false）以后会引起性能急剧提高，但同时也会冒着丢失消息或者重复接收消息的风险。类似地，利用多点传送发送消息会提升性能，同时也会有消息半途丢失的危险。

消息确认间隔不应设置得过短――发送确认的比率越大，处理消息的速度可能会越慢。同时，如果设置得过大，则意味着系统发生故障时，消息会丢失或者被重复发送。

一般说来，应在单个服务器上对多个JMS目的地进行配置，而不是将它们分散在多个JMS服务器，除非不再需要扩展。

关闭消息页面调度（paging）可能会提高性能，但会影响可扩展性。如果打开消息页面调度（paging），则需要额外的I/O操作以便将消息串行化到硬盘，在必要的时候再读进来，但同时也降低了对内存的要求。

一般来说，异步过程比同步过程更好操作，更易于调节。

Web容器

Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据，然后使用servlet和JSP生成动态内容，其中应用层一般由EJB组成。在这种结构中，servlet 和JSP保留对EJB的引用，以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上，则利用JNDI进行查询的费用是很昂贵的。

JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容，对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化，则可以通过将ServletReloadCheckSecs 设置为－1，从而关闭自动装载（auto-reloading）功能。使用这种方法以后，服务器将不再轮询Web层是否有变化，如果JSP和servlet的数量很多，则效果是非常明显的。

这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的，可以考虑使用有状态会话bean来替代。

JVM调试

如今的大多数JVM具有自主调节功能，因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间，按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收（GC）处理。在这种设置环境中，如果堆太大的话，垃圾回收的间隔应设为一分钟或更长。最后，需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考：

http://edocs.bea.com/wls/docs70/perform/JVMTuning.html1104200。

服务器调试

除了由各个子系统提供的调试参数以外，还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效，仅当下列情况成立时再考虑使用这种方法：预定的吞吐量没有达到；等待队列（未开始处理的请求）过长；CPU仍有剩余。当