2008年3月25日星期二

Seam学习笔记---Seam的组件

Seam组件

无状态Session Bean


无状态Session Bean组件无法在多次调用之间保持状态。因此,它们通常在不同的Seam上下文中,操作其他组件的状态。他们可以作为JSF的action listener,但是不能为JSF组件的显示提供属性。

无状态Session Bean总是生活在无状态上下文中。

无状态Session Bean是Seam组件中最没趣的了。

Seam无状态Session Bean组件可以使用 Component.getInstance() 或者 @In(create=true) 实例化。它们不能直接使用JNDI或者 new 操作实例化。

有状态Session Bean


有状态Session Bean不仅可以在bean的多次调用之间保持状态,而且在多次请求之间也可以保持状态。 不由数据库保存的状态通常应该由有状态Session Bean保持。这是Seam和其他web框架之间的一个显著的不同点。 其他框架把当前会话的信息直接保存在 HttpSession 中,而在Seam中你应该把它们保存在有状态Session Bean的实例中,该实例被绑定到会话上下文。这可以让Seam来替你管理状态的声明周期,并且保证在多个不同的并发会话中没有状态冲突。

有状态Session Bean经常被作为JSF action listener使用,也可以作为JSF显示或者form提交的后台bean,提供属性供组件访问。

默认情况下,有状态Session Bean会被绑定到Conversation Context。它们绝不会绑定到page或stateless context。

对Session范围的有状态Session Bean的并发请求,会被Seam按顺序串行处理。

Seam有状态Session Bean组件可以使用 Component.getInstance() 或者 @In(create=true) 实例化。它们不能直接使用JNDI或者 new 操作实例化。

实体Bean


实体Bean可以被绑定到上下文变量,起到Seam组件的作用。因为Entity除了上下文标识之外,还有持久标识,Entity实体通常明确的由Java Code绑定,而非由Seam隐性初始化。

Entity Bean实体不支持双向注入或者上下文分界。对Entity Bean的调用也不会触发验证。

Entity Bean通常不作为JSF的action listener使用,但经常作为JSF组件用于显示或者form提交的后台bean,提供属性功能。 特别是,当Entity作为后台Bean的时候,它会和一个无状态Session Bean扮演的action listener联用,来实现CRUD之类的功能。

默认情况下,Entity Bean被绑定到Conversation Context。他们永远不能被绑定到无状态Context。

注意,在集群环境中,把Entity Bean直接绑定到Conversation或者Session范围的Seam上下文变量,与在有状态Session Bean中保持一个对Entity Bean的引用相比,性能比较差。因此,并非所有的Seam应用程序都会把Entity Bean定义为Seam组件。

Seam实体Bean组建可以使用 Component.getInstance()@In(create=true) 或者直接使用 new 操作来实例化。

组件名字


所有Seam组件都需要名字。我们可以通过 @Name 注解来命名组件:

@Name("loginAction") @Stateless public class LoginAction implements Login {     ... }

这个名字是 seam component name,和EJB规范定义的任何其他名字都没有关系。 但是,Seam组件名字就作为JSF管理的Bean Name使用,因此,可以理解为这两个概念是等同的。

@Name 不是定义组件名称的唯一方式,但是我们总得要在 某个地方 来指定名字。 否则,Seam 注解的其他部分就无法工作。

就如同在JSF中,Seam组件实例绑定成上下文变量时,其名字通常和组件名相同。 因此,例如我们可以通过 Contexts.getStatelessContext().get("loginAction") 来访问 LoginAction。 特别是,不管Seam自己何时初始化一个组件,它将这个新实例以组件的名字绑定成一个变量。 但是,又和JSF一样,应用程序也可以把组件绑定成其他的上下文变量,只需通过API编程调用。 例如,当前登录的用户(User)可以被绑定成为Session上下文中的 currentUser 变量,而同时,另一个用作某种管理功能的用户则被绑定成对话上下文的 user 变量。

对非常大型的应用程序,经常使用全限定名;内置的Seam组件就是这样。

@Name("com.jboss.myapp.loginAction") @Stateless @Interceptors(SeamInterceptor.class) public class LoginAction implements Login {     ... }

我们可以在Java代码和JSF表达式语言中使用全限定的组件名称。

<h:commandButton type="submit" value="Login"                  action="#{com.jboss.myapp.loginAction.login}"/>

这很啰嗦,Seam也提供了把全限定名简写的办法。在 components.xml 文件中加入类似这样的一行:

<factory name="loginAction" scope="STATELESS" value="#{com.jboss.myapp.loginAction}"/>

所有的Seam内置组件都有全限定名,但大多数都在Seam jar文件的 components.xml 中简写为简单的名字。

Seam学习笔记---Seam的上下文

基本的Seam上下文

基本的Seam上下文有:

  • Stateless context

  • Event (or request) context

  • Page context

  • Conversation context

  • Session context

  • Business process context

  • Application context

Stateless context(无状态上下文)


那些确实没有状态的组件(主要是无状态Session Bean)总是运行在无状态上下文中(实际上就是上下文无关)。 无状态组件没什么太大的意思,也有争议认为它们不十分面向对象。但不管怎么样,它们还是很重要,并且通常很有用。

Event context(事件上下文)


事件上下文是“最窄”的有状态上下文,是Web Request 上下文的泛化,用以包含其他种类的事件。 然而,与JSF请求的生命周期相关联的事件上下文是事件上下文最重要的实例,并且也是你最常打交道的。 与事件上下文相关联的组件在请求结束时被销毁,但是它们的状态至少在请求的生命周期中是存在并且是定义良好的。

Page context(页面上下文)


页面上下文允许你将状态与一个渲染页面的实例相关联。 你可以在Event Listener中初始化状态,或者在实际渲染页面的时候初始化状态,任何源于该页面的事件都可以访问到这些状态。 这在支持像可点击列表这种的功能时特别有用,列表的内容通过服务器端的数据变化产生。 实际上状态被序列化到了客户端,因此在多窗口操作或者回退按钮的时候,这种结构是非常健壮的。

Conversation context(业务会话上下文)

业务会话上下文是Seam中最核心的概念conversation(业务会话)是从用户的视角看待的一个工作单元。 它可能跨越与用户交互的多个Servlet、多个请求,和多个数据库事务。但是对用户来说,一个业务会话解决一个单一的问题。 例如说:“预订酒店”,“批准合同”,“创建订单”都是业务会话。 你可以将业务会话理解成对一个“use case(用例)”或“user story(用户故事)”的实现,但这种联系并非是必须的。

业务会话保存关于“在此窗口中,用户正在干什么”的状态。在任何时间,一个用户可能同时位于多个业务会话活动中,一般是在几个不同窗口中。 业务会话上下文让我们可以确保不同业务会话的状态不会互相干扰,不会导致Bug。

你可能要花上一点时间才能习惯以这一业务会话的观点来思考你的应用程序。 但一旦你习惯于它,你会喜欢上这个术语,并且再不会不用业务会话来思考了!

一些业务会话仅存在在一次请求中。跨域多个请求的业务会话必须通过Seam提供的annotation注解来划分。

一些业务会话同时也是tasks(任务)。任务是一种业务会话,它特指一个长时间运行的业务过程,当正确完成后,可能会触发一个业务流程状态的转换。Seam为任务划分提供了专门的annocation注解。

业务对话可以是nested(嵌套)的,一个业务对话嵌套“在”一个更大的业务对话中。这是一项高级特性。

通常,业务对话状态实际上由Seam保存在Servlet Session 中,跨越请求。Seam实现了可配置的 conversation timeout,可以自动销毁不活动的业务会话,这就可以确保,如果用户取消对话,用户的登录Session中保存的状态不会无限增长。

对于在一个长时间运行的业务会话中所产生的并发请求,Seam按顺序执行。

除此之外,Seam也可以配置成把对话状态保存在客户端浏览器中。

Session context(Session上下文)


Session上下文保存与用户登录session相关联的状态。虽然当需要在多个业务会话中交换状态的时候这很有用,但我们一般不建议使用Session 上下文保存组件,除非是保存有关登录用户的全局信息。

在JSR-168 Portal环境下,Session上下文代表Portlet上下文。

Business process context (业务流程上下文)


业务流程上下文保存了长时间运行的业务流程相关的状态。这种状态由BPM引擎(jBPM)管理和持久化。 业务流程跨越多个用户的交互,因此状态在多个用户之间通过良好定义的方式共享。 当前的任务决定当前的业务流程实例,业务流程的生命周期通过外置的 process definition language(流程定义语言) 来定义,因此没有特别的annotation注解用于划分业务流程。

Application context(应用上下文)


Application上下文就是Servlet规范中的Servlet上下文。应用程序上下文在保存静态信息方面有用,例如配置数据,引用数据或者元模型。 例如,Seam把自己的配置和元模型保存在应用程序上下文中。

Context variables(上下文变量)


上下文定义了命名空间,一组 context variables(上下文变量)。 这些工作很类似Servlet规范中对Session或Request attributes的定义。 你可以绑定任何你喜欢的值到Context Variable,但通常我们会绑定Seam组件实例到Context Variables。

因此,在上下文中,组件实例是通过上下文变量名字来辨别的(通常是这样,但并非绝对,就和组件名称一样)。 你可以通过程序在特定范围内访问被命名的组件实例,这是通过 Contexts 类进行的,它提供了对 Context 接口的几个线程绑定的实例的访问:

User user = (User) Contexts.getSessionContext().get("user");

你也可以通过名字来设置或修改变量值:

Contexts.getSessionContext().set("user", user);

但通常,我们通过注射(injection)来从上下文中获得组件,并且通过反向注射(outjection)把组件实例返回上下文。

2008年3月21日星期五

有意思(答案见中缝)

据说能答对5道题的人是天才,答对4道的是帅才,答对3道的是将才,答对2道的是奇才,答对1道的是人才,1道都想不出来的是X才

1、一个数字,去掉前面一个数字后,是13。去掉最后一个数字后,是40。这个数字是什么?

2、这一等式很奇怪,0比2大,2比5大,5比0大。为什么?

3、只字加一笔,会是什么字?

4、人加一笔,除了大/个,还有什么字?

5、桌子上有2、1、6三张卡片,请问摆成一个什么数字可以让43整除?
四十三,剪刀石头布,冲,及,129

2008年3月20日星期四

免得老是忘记-toString

为了方便Log4J等方式的调试,显示一个类的实例,通常需要做如下方式的输出:
log.trace(myClassInstance);
此时需要MyClass实现重载 toString()方法,利用Jakarta Common Lang可以很容易实现toString方法,由ToStringBuilder类完成对一个类的细节的显示,参考toString方法的实现如下:

import org.apache.commons.lang.builder.ToStringBuilder;

public String toString() { return ToStringBuilder.reflectionToString(this); }relectionToString()

将利用Java Refelection机制显示类实例的所有属性的信息.

2008年3月17日星期一

看什么呢?老婆

2008年3月12日星期三

Cognos入门指南

2008-01-08至2008-03-12的工作成果

2008年3月10日星期一

Cognos报表展示的参数传递

如何调用已发布到Enterprise server的ppx报表(参数传递)

Cognos的内容一般作为网页中某一特定的帧来展现。我们可以在外部统一的用户交互界面中收集用户递交的查询条件(一般用JSP实现),在检查完用户输入的有效性之后,把这些参数按照Cognos约定的标准,以POST的方式传到某一帧中的Cognos的网管。Cognos网管就会把用户查询的结果返回到该帧中。

下面是一个接口调用的实例:
假设服务器名称为:servername
ppx报表发布到enterprise server之后在enterprise server的根目录下,名称为:testreport
如果我们要对这个报表进行访问,可通过如下url对报表进行调用:http://test/cognos/ cgi-bin/ppdscgi.exe?DC=R&E=%2Ftestreport
如果用户要求访问的是一个可动态分析的cube,那么相应的url为
http://test/cognos/ cgi-bin/ppdscgi.exe?DC=Q&E=%2Fcubename

其中:%2F是一个URL使用的转意符,它的原型是符号“\”。

如果报表或Cube是发布于一个文件夹test中的,那么相应的url为:

http://test/cognos/ cgi-bin/ppdscgi.exe?DC=R&E=%2Ftest%2Ftestreport



通过以上的接口可以访问到任意发布到Powerplay Enterprise Server的报表或Cube。如果要向报表或Cube传递过滤条件,可采用下面的调用标准。

例如在Enterprise Server发布有报表ICBC,该报表开放了四个传参接口(Years,Products,Locations,Channles)。用户可以选择向其中的某几个接口传参。

如果选择“Products”为“Outdoor Products”则调用

http://test/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc&DM=Products&FC=0%09Outdoor%20Products&ZZ=X

其中&DM=Products //表示要过滤维度Products

&FC=0%09Outdoor%20Products //表示维度Products的过滤值



如果是过滤两个维度,例如过滤“Products”和“Locations”则调用

http://info/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc&DM=Products%09Locations&FC=0%09Outdoor%20Products%091%09Europe&ZZ=X

其中&DM=Products%09Locations //维度间用%09分开

&FC=0%09Outdoor%20Products%091%09Europe //维度值从0开始标号



如果是过滤三个维度,例如过滤“Products”和“Locations”及“Channels”则调用

http://info/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc2&DM=Products%09Locations%09Channels&FC=0%09Environmental%20Line%091%09Europe%092%09Independent&ZZ=X

其中&DM=Products%09Locations%09Channels //维度间用%09分开

&FC=0%09Outdoor%20Products%091%09Europe%092%09Independent

//维度值从0开始标号



在每条Url后添加&ZZ=X,表示参数传递结束。



注意:维度过滤值必须用该维度节点的code

2008年3月7日星期五

真假猴王

  千年以前
  你匍匐地下
  明知生死未来痛苦欢乐
  但
  你无须说破
  生命历程里的漫漫长路
  说与不说
  对任何人
  都是轮回的花开花落
  
  千年以前
  你伏在地下
  明知是非真假
  但
  你不能说破
  那两个惊天动地的神猴
  说出来
  对天对地
  都是难躲的祸
  
  千年以后
  你伏在我心中
  明知爱与不爱
  但
  你无法说破
  那深深寂寞里的烟花
  说出来
  对你对我
  都是遗憾三生的错

2008年3月5日星期三

Operational Data Storage

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合,用于支持企业对于即时性的、操作性的、集成的全体信息的需 求。常常被作为数据仓库的过渡,也是数据仓库项目的可选项之一。

根据Bill.Inmon的定义,“数据仓库是面向主题的、集成的、稳定的、随时间变化的,主要用于决策支持的数据库系统”

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合,用于支持企业对于即时性的、操作性的、集成的全体信息的需 求。常常被作为数据仓库的过渡,也是数据仓库项目的可选项之一。

在Kimball的<<数据仓库生命周期工具集The Data WareHouse Liftcycle Toolkit>>,他是这样定义的

1. 是操作型系统中的集成,用于当前,历史以及其它细节查询(业务系统的一部分)

2. 为决策支持提供当前细节数据(数据仓库的一部分)

因此操作数据存储(ODS) 是用于支持企业日常的全局应用的数据集合,ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。同样也可以看出ODS是介于DB和DW 之间的一种数据存储技术,和原来面向应用的分散的DB相比,ODS中的数据组织方式和数据仓库(DW)一样也是面向主题的和集成的,所以对进入ODS的数 据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据,如果需要的话还可以对ODS中的数据进行增、删和更新等操 作,虽然DW中的数据也是面向主题和集成的,但这些数据一般不进行修改,所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。

由于ODS仍然存储在普通的关系数据库中,出于性能、存储和备份恢复等数据库的角度以及对源数据库的性能影响角度,个人不建议ODS保存相当长周期的数据,同样ODS中的数据也尽量不做转换,而是原封不动地与业务数据库保持一致。即ODS只是业务数据库的一个备份或者映像,目的是为了使数据仓库的处理和决策支持要求与OLTP系统相隔离,减少决策支持要求对OLTP系统的影响。

为什么需要有一个ODS系统呢?一般在带有ODS的系统体系结构中,ODS都具备如下几个作用:

1) 在业务系统和数据仓库之间形成一个隔离层。

一 般的数据仓库应用系统都具有非常复杂的数据来源,这些数据存放在不同的地理位置、不同的数据库、不同的应用之中,从这些业务系统对数据进行抽取并不是一件 容易的事。因此,ODS用于存放从业务系统直接抽取出来的数据,这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致,因此在抽取过程中极 大降低了数据转化的复杂性,而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

2) 转移一部分业务系统细节查询的功能

在 数据仓库建立之前,大量的报表、分析是由业务系统直接支持的,在一些比较复杂的报表生成过程中,对业务系统的运行产生相当大的压力。ODS的数据从粒度、 组织方式等各个方面都保持了与业务系统的一致,那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行,从而降低业务系统的查询压力。

3) 完成数据仓库中不能完成的一些功能。

一 般来说,带有ODS的数据仓库体系结构中,DW层所存储的数据都是进行汇总过的数据和运营指标,并不存储每笔交易产生的细节数据,但是在某些特殊的应用中,可能需要 对交易细节数据进行查询,这时就需要把细节数据查询的功能转移到ODS来完成,而且ODS的数据模型按照面向主题的方式进行存储,可以方便地支持多维分析 等查询功能。即数据仓库从宏观角度满足企业的决策支持要求,而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

在一个没有ODS层的数据仓库应用系统体系结构中,数据仓库中存储的数据粒度是根据需要而确定的,但一般来说,最为细节的业务数据也是需要保留的,实际上 也就相当于ODS,但与ODS所不同的是,这时的细节数据不是“当前、不断变化的”数据,而是“历史的,不再变化的”数据。这样的数据仓库的存储压力和性能压力都是比较大的,因此对数据仓库的物理设计和逻辑设计提出了更高的要求。

房价上涨的原因

以前,有个地主有很多地,找了很多长工干活,地主给长工们盖了一批团结楼住着,一天,地主的谋士对地主说:东家,长工们这几年手上有点钱了,他们住你的房子,每月交租子,不划算,反正他们永远住下去,你干脆把房子卖给他们起个名堂叫做-----公房出售!告诉他们房子永远归他们了,可以把他们这几年攒的钱收回来,地主说:不错,那租金怎么办?谋士说:照收不误,起个日本名儿,叫物业费!地主很快实行了,赚了好多钱,长工们那个高兴啊!
  过了几年,地主的村子发展成城镇了,有钱人越来越多,没地方住,谋士对地主说:东家,长工们这几年手上又有钱了,咱们给他们盖新房子,起个名堂叫做旧城改造,他们把手上的钱给我们,我们拆了房子盖新的,叫他们再买回去,可以多盖一些卖给别人,地主又实行了,这次,有些长工们不高兴了,地主的家丁派上用途了,长工们打掉牙只好往肚子里咽,地主又赚了好多钱。
  又过了几年,地主的村子发展成大城市了,有钱人更多了,地主的土地更值钱了,谋士对地主说:东家,咱们把这些长工的房子拆了,在这个地方建别墅,拆出来的地盖好房子卖给那些有钱的大款还能赚一笔,地主说:长工们不干怎么办?谋士说:咱给他们钱多点儿,起个名堂叫货币化安置,咱再到咱们的猪圈旁边建房子,起个名堂叫经济适用房,给他们修个马车道让他们到那边买房住,地主说:他们钱不够怎么办?谋士说:从咱家的钱庄借前给他们,一年6分利,咱这钱还能生钱崽,又没风险,地主又实行了,长工们拿到钱,地主的经济适用房到现在才建了一间,长工们只好排队等房子,直到现在,还等着呢——
  于是,长工们开始闹事了,地主有点慌,忙问谋士怎么办?谋士说:赶紧通知长工们,房子要跌价了,别买了,租房住吧,正好把我们的猪圈租给他们,结果,这么多年后,长工们的钱全没了,还在租房住,直到永远 。

2008年3月4日星期二

鱼我所欲也

鱼,我所欲也,熊掌,亦我所欲也,二者不可得兼,舍鱼而取熊掌者也。生,亦我所欲也,义,亦我所欲也,二者不可得兼,舍生而取义者也。生亦我所欲,所欲有甚于生者,故不为苟得也。死亦我所恶,所恶有甚于死者,故患有所不避也。如使人之所欲莫甚于生,则凡可以得生者何不用也?使人之所恶莫甚于死者,则凡可以避患者何不为也?由是则生而有不用也;由是则可以避患而有不为也。是故所欲有甚于生者,所恶有甚于死者。非独贤者有是心也,人皆有之,贤者能勿丧耳。

一箪食,一豆羹,得之则生,弗得则死。呼尔而与之,行道之人弗受;蹴尔而与之,乞人不屑也。

万钟则不辨礼义而受之,万钟于我何加焉!为宫室之美,妻妾之奉,所识穷乏者得我欤?向为身死而不受,今为宫室之美为之;向为身死而不受,今为妻妾之奉为之;向为身死而不受,今为所识穷乏者得我而为之:是亦不可以已乎?此之谓失其本心。