请问banq,struct+Hibernate难道不能通过集群提高大访问量吗?

我认为EJB只不过实现了分布式,至于说一个系统的伸缩性,我们都可以通过硬件的集群来满足,请指正.

是的,可以通过硬件甚至操作系统Linux的集群来解决。这种实现方式对于J2EE应用效率如何我自己没有实验过,我个人认为有些牵强,也是可行的。

使用Struts Hibernate,这些都可以嵌入到EJB的Session Bean中实现,Spring也作为Session Bean前台,Hibernate作为Session Bean替代CMP的持久层方案(如果你不嫌麻烦)。

可伸缩性不只是EJB , JMS Jini等都是可伸缩性的方案,特别JMS,其应用范围一点不亚于EJB,可以说,EJB无法应用的领域,基本都可以使用JMS实现,用JMS实现可伸缩的OA系统,工作流 BPML等系统,JMS实现股票等大访问量,安全性高系统等等。JMS开源产品很多,最著名的是法国电信的一个开源产品,当然电信行业的短消息等很多系统都可以用JMS实现。

如果你重视可伸缩性,那么你在系统架构选择时,总是能做到新技术和可伸缩性两者统一,这当然是最好的。


BANQ,很高兴看到你的工作又有了新的进展,

我在开源世界中寻觅了长时间以后,对BANQ的理念有了认同感。
软件应该降低开发成本,有固定的管理流程,这和系统的轻重是两回事
比如EJB系统,看上去重,但管理和周围系统有固定模式。

同时要适应甚至主动感受变化,这是可变性需要决定的。这也是架构的
有用范围。

多谢zingers赞同,我当初有些观点是可能偏激,但是其源发思想是有理而发,不是为了赚取表面上的不同反响。

刚才看了halcyon 关于AOP的跟贴,他的见解也是比较理性,让人受益的。
http://www.jdon.com/jive/thread.jsp?forum=91&thread=11466&message=7373153#7373153

关键,我在这里重复一下我的观点,防止对初学者有误导,目前这样处于可选的状态我认为不错,对于不同用户有不同的选择:

1. 如果你是一个框架设计者,你需要设计自己独立的框架,那么PicoContainer这个真正轻量的容器是个好的选择。

2. 如果你是一个Web网站,非大型企业应用,那么Spring架构可以帮助你们解决不少问题。

3. 如果你要规划一个中大型企业应用,事务回滚机制非常重要,计算性能又相当重要,那么EJb无疑是一个合适的选择。

赞同banq的观点,个人认为什么东西都得放在环境里才能做判断,在没有其它的笔的情况下,如果我们有纸,用一只铅笔来做记录,当然很先进了,现在我们除了有纸,也有电脑,停电比较少,上网又比较方便的情况下,使用电脑来做记录当然比用铅笔做记录要先进了。

虽然目前开源领域还没有支持集群的软件,但是有个家伙使用开源软件Tapestry + Spring + hibernate做了betterpetshop,声称支持集群环境。

我非常感兴趣它的集群技术,结果仔细一看,用了Tangosol,因为用了TangoSol才声称支持集群CLuster,TangoSol这玩艺早在Jive 2.5时就出现,TangoSol号称是纯Web的集群的一个解决方案,因为开源软件多数是Web软件,所以,TangoSol总是出现在开源社区。但是它自己不是开源的。看来以后用了开源社区的Web产品,最后走上集群路线时,向Tangosol交费即可,真是佩服他们的眼光啊。

https://betterpetshop.dev.java.net/

最重要的是,这位johnmammen 在其项目目标Project Mission中提及:
designing Web applications which uses various Opensource frameworks to build a scaleable, efficient and reliable Web application

目标是使用开源的框架建立一个可伸缩的 有效率的 稳定的Web应用系统,他将scaleable可伸缩性作为其追求的目标,看来,可伸缩性是如此重要,这已经形成共识。

关于Spring大体认识见下文:
http://www.jdon.com/AOPdesign/spring.htm

在Spring介绍,包括Rob自己的书中,大肆指责EJB 2.0的问题,但是他的Spring提供的解决方案却并不简单,如果以Spring替代EJB,无疑是按下葫芦瓢起瓢,如果两者混合使用,感觉会给学习使用带来困难。

Spring的事务机制中,指责EJB事务需要使用Facade模式完成,而他自己则不必,那么它的配置则复杂:
首先定义JDBC的datasource:


<bean id="dataSource"
class=
"org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name=
"driverClassName"><value>${jdbc.driverClassName}</value></property>
<property name=
"url"><value>${jdbc.url}</value></property>
<property name=
"username"><value>${jdbc.username}</value></property>
<property name=
"password"><value>${jdbc.password}</value></property>
</bean>


其中jdbc.username值还要在jdbc.properties文件中定义:
jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc:hsqldb:hsql://localhost:9001
jdbc.url=jdbc:mysql://localhost/betterpetshop
jdbc.username=hotornotuser
jdbc.password=asha1234
hibernate.show_sql=true

# Property that determines the Hibernate dialect
# (only applied with "applicationContext-hibernate.xml")
hibernate.dialect=net.sf.hibernate.dialect.HSQLDialect
hibernate.dialect=net.sf.hibernate.dialect.MySQLDialect

# Property that determines the JDBC implementation of Clinic
# (only applied with "applicationContext-jdbc.xml")
petclinic.jdbcImplBeanName=hsqlClinic
petclinic.jdbcImplBeanName=mysqlClinic

Connection Pooling
hibernate.c3p0.minPoolSize=5
hibernate.c3p0.maxPoolSize=20
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statement=50
这配置文件不是XML的,因此容易出错,而且一个JDBC两个配置文件,在EJB中,只要在配置容器的mysql-ds.xml一个文件即可,而且很容易配置多种数据库。

为了使用JTA,还必需在dataAccessContext-jta.xml 中配置:


<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name=
"jndiName"><value>jdbc/jpetstore</value></property>
</bean>

<bean id=
"transactionManager"
class=
"org.springframework.transaction.jta.JtaTransactionManager"/>



如果使用Hibernate的事务机制:

<bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
<property name=
"dataSource"><ref local="dataSource"/></property>
<property name=
"mappingResources">
<value>org/springframework/samples/petclinic/hibernate/petclinic.hbm.xml</value>
</property>
<property name=
"hibernateProperties">
<props>
<prop key=
"hibernate.dialect">${hibernate.dialect}</prop>
</props>
</property>
</bean>

<bean id=
"transactionManager"
class=
"org.springframework.orm.hibernate.HibernateTransactionManager">
<property name=
"sessionFactory"><ref local="sessionFactory"/></property>
</bean>

然后,你还要去配置petclinic.hbm.xml这个文件,这个文件类似EJB中CMP的jbosscmp-jdbc.xml文件。

至此,为了在Spring中使用事务机制,你需要配置至少三个以上的配置文件,你的WEB-INF下都是配置文件,这给组件重用带来困难,因为一旦某个配置与WEB-INF联系紧密,形成中间件的可能性就不大,难于在多个Web-INF的Web应用中实现重用。

在EJB中,缺省情况下:无需有关事务的任何配置,当然ACID根据数据库配置,只要遵循facade模式编写程序即可获得事务支持,在这点上是非常方便的,如果这点规则都不愿意遵循,那么天马行空带来的是混乱,正Spring的事务使用一样。


我们再看看Spring骄傲的事务配置声明:



<bean id="petStore"
class=
"org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name=
"transactionManager"><ref bean="transactionManager"/></property>
<property name=
"target"><ref bean="petStoreTarget"/></property>
<property name=
"transactionAttributes">
<props>
<prop key=
"insert*">PROPAGATION_REQUIRED,-MyCheckedException</prop>
<prop key=
"update*">PROPAGATION_REQUIRED</prop>
<prop key=
"*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>

这非常类似EJB的CMT配置吗?如何使用PROPAGATION_REQUIRED等,也需要你详细了解其中规则。我真是服了Spring这些人:他们创造了多样的Java世界。

Spring真正的精华是它的Ioc模式实现的BeanFactory和AOP,它自己在这个基础上延伸的功能有些画蛇添足。

它与Picocontainer一致的是:
在第三方处,实现被调用者的实例化,也就是Ioc模式实现。

不同之处:
1. pico是使用代码实现Ioc,这点我比较喜欢,我以前说过,XML配置一旦复杂,不是一件轻松的事情。
2. spring使用配置文件使用实例化,你的所有JavaBeans都需要通过配置实现,然后你使用factory.getbeans("beanId")获得实例。所以对于你,有小事情需要你关注一下:XML配置文件要写正确,如果频繁更改类,要注意频繁更改配置文件,当然有可视化工具帮助你就好。

可以使用Spring实现自己的拦截器,或者做一个神气的mixin(迷信?),如果只是这个用处,dyncAOp或性能最优的http://aspectwerkz.codehaus.org/可能更好一点。

在实际应用中,要切实考虑好,你到底需要什么?如果你需要的只是某一点,那么有更专业的框架可以供选择,如果你喜欢选择一个流行的、可以炫耀的外表,那么Spring这样混合体可能适合你,还有,如果你不嫌重而且累赘的话。

深刻掌握Spring之前,先掌握Gof23种设计模式还有JDK的动态代理API,否则可能被SPring复杂吓倒哦。

Spring+EJB/SLSB架构虽然使得你的系统具有可伸缩性,但是还是要注意一个粗粒度的事务问题:
这类似petstore实现Command模式调用EJB的粗粒度事务,在spring+ ejb中也存在,在spring手册中,他推荐使用EJB,可继承他的AbstractStatelssEJBXXX,然后将SLSB中方法全部委托给POJO做,例如:

ejb方法:
public void updateUser(){
service.updateUser();
}

service的方法:
public void updateUser(){
updateTabel1();
updateTable2();
}

当updateTable2()抛出异常,updateTable1()是不回滚的。
而只有这么做,才全部回滚:
ejb方法:
public void updateUser(){
updateTabel1();
updateTable2();
}
所以,纯POJO只是一只看上去很美的花,适合无事务的网站开发。同样,虽然可以采用Spring+EJB,但是本质上Spring是与EJB相竞争的,有其野心的,虽然他自己声称自己是个礼貌的绅士框架(无侵范性),但是温柔表面隐藏阴谋,表里不一的人或物我是避之。

看看下面所谓流行架构:
Tapestry/Struts/JsF + Spring + Hibernate;缺乏可伸缩性,只能做单台服务器的网站。无可视化开发工具,面向XML编程,原始社会。

Tapestry/Struts/JsF + EJB/SLSB;配合JBuilder等可视化开发工具,工业社会的开发效率。同时配以容器级别的角色权限控制,无需自己编写编码,图形界面配置,效率不要太高。

世上人何时不再跟风,跟风容易中圈套,20年前的已经证明。


此人已疯,大家别管他