公告


赛特达开博了,非常高兴这样的季节能够和大家一起分享这样的喜悦。赛特达在获得大家新老朋友的支持的同时也希望能够一起分享最前沿的技术信息。希望各位能够常来坐坐,也常来聊聊!crack

关于我

<2020年6月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

最近来访

留言簿(0)

文章分类

文章档案

相册


最新评论

请问,如果想让DOE中的试验方案在一台机器中实现分布计算,也就是四个核心,每个核心处理一个方案,该怎么做?--【匿名用户】:E-works热心网友 spred
不错!!--卢玉琴
那么请问isight&nbsp;fd能不能进行类似的mdol语言开发呢?有没有相关资料?--【匿名用户】:E-works热心网友
能否较详细介绍一下开发的一个简单实例啊。--【匿名用户】:E-works热心网友
为什么语言介绍并不更新啊?--【匿名用户】:E-works热心网友
博主您好,我初次接触这种抽样法,感觉一头雾水。很幸运看到您的博文,请您能详细介绍一下拉丁超立方抽样好吗?最好举例说明。谢谢!--【匿名用户】:E-works热心网友
我用的是isight8.0可以实现并行计算吗--【匿名用户】:E-works热心网友
太经典了!对于我这样刚刚迈出校园的学生来说,真是醍醐灌顶啊!多谢楼主的教导之言!--【匿名用户】:E-works热心网友
很好的资料
请问你有包含图片的完整文档吗?
可否发一份networm_2005@163.com
谢谢--【匿名用户】:E-works热心网友
logs中写的错误类型是stderr:&nbsp;Estimated&nbsp;disk=1.2MB
stderr:&nbsp;Estimated&nbsp;DOF=80
stderr:&nbsp;Estimated&nbsp;memory=32MB
之类的错误,不知道是什么原因

--【匿名用户】:E-works热心网友
请问一下,做过isight集成nastran的案例吗,我用的是isight-fd版本,集成nastran2007,结果总是出错,不知道什么原因,烦请高手指点一下--【匿名用户】:E-works热心网友
好的&nbsp;谢谢--【匿名用户】:E-works热心网友
说得是没错,但那些政府管员,当管的都拿老百姓的呀,大家一起努力吧,改变中国现在的样子吧,--【匿名用户】:E-works热心网友
好!--【匿名用户】:E-works热心网友
清华大学有N多个大学校长,俺想知道这五句话是哪个校长说的?&nbsp;
--【匿名用户】:E-works热心网友
谢谢答疑解惑
--【匿名用户】:E-works热心网友
--【匿名用户】:E-works热心网友
请问Isight&nbsp;for&nbsp;Abaqus——by&nbsp;hannah在abaqus的哪个版本中有啊?--【匿名用户】:E-works热心网友
Re&nbsp;2楼:
如果想让DOE中的各个实验方案分到不同的机器上并行计算的话,单机版的Isight-FD是不行的,必须在FIPER并行分布环境中才能实现。在这个FIPER环境中,Isight-FD只是它的一个客户端,另外还有一个客户端叫Station,这样一旦Isight-FD把各个方案提交到FIPER环境中后,FIPER环境的服务器端ASCS就会自动的把任务分到各个机器的Station上来并行或分布执行。--赛特达
Isight&nbsp;for&nbsp;Abaqus是我们的另外一个产品,优化方面功能和Isight-FD基本是一样的,只不过这个产品只能集成Abaqus,不能集成其它的软件。

--赛特达

阅读排行榜

评论排行榜

EJB3.0Spring比较

 

(译“POJO Application Frameworks: Spring Vs. EJB 3.0”)

摘要:

 

阅读“POJO Application Frameworks: Spring Vs. EJB 3.0”一文的读书笔记,翻译其中部分,主要分6点讲述两者的差别。

 

0.比较目录

 

1) Vendor Independence

2) Service Integration

3) Flexibility in Service Assembly

4) XML versus Annotation

5) Declarative Services

6) Dependency Injection

 

1. 厂商无关性(Vendor Independence )

 

Java平台最具竞争力的优势是厂商无关,(不依赖某个特别的厂商)。EJB3.0的标准也是开放的,并且继承了这一优势。EJB3.0的规范是由包括几乎所有Java社区内的开源和商业组织定义并支持的。EJB3.0隔绝了开发者和应用服务的具体实现。比如说:JBossEJB3.0是在Hibernate的基础商实现的,而OracleEJB3.0是基于TopLink实现的。但开发者在使用EJB3.0开发企业应用时,即不需要学习Hibernate也不需要学习TopLinkEJB3.0依然能够在JBossOracle上面运行得很好。厂商无关性时EJB3.0框架现在区别于任何其他POJO中间件框架的一大特色。

当然,也有一些EJB3.0的批评者立刻指出,EJB3.0的规范还没有最终定稿,EJB3.0得到业界主要J2EE厂商完全接受还有一到两年的路要走。是的,是这样,但是既便现在企业软件采用的应用服务还不支持EJB3.0,但是,(在将来)仍然能够通过下载安装“可嵌入(embeddable)”EJB3.0产品来获得支持。这方面走在前面的JBoss就已经推出的可嵌入EJB3.0产品,开源并且支持所有兼容J2SE-5.0的环境,现在正处于beta测试阶段。其他厂商也正在迅速跟进,很快会推出他们自己的可嵌入的EJB3.0产品,特别是EJB3.0规范中的“数据持久化”部分。

另一方面,Spring是一个非基于标准的技术解决方案,并且在将来很长一段时间也将继续维持这样的状况。你可以在任何应用服务上使用Spring框架,但同时意味着你的应用已经和Spring以及Spring所选用的应用服务套牢了。

  • Spring框架是一个开源项目(而不是标准),自己定义了一套XML配置文件大纲以及程序接口。几乎所以的开源项目都是这样。从长远考虑,使用Spring框架的企业应用恐怕得更关注Spring项目的运作情况(以及Interface21 Inc. ――大部分Spring的核心开发人员都来自于Interface21 Inc.)。另外,如果企业应用中采用了Spring专用服务(Spring-specific services),比如Spring事务管理或Spring MVC,事实上这个企业应用已经和Spring牢牢绑死了。
  • Spring没有实现和最终服务提供者的隔离。比如,现在在选择数据持久化服务时,Spring框架使用不同的DAOHelper类以利用JDBCHibernateiBatisJDO。所以,如果你打算改变数据持久化方式,比如从JDBC改为Hibernate,你就需要重构你的应用代码了,新的Helper类编写也是不可避免的。

2.服务集成 (Service Integration)

 

Spring框架站在一个高于应用服务和服务相关类库的层次上。服务集成代码(如:数据访问和Helper类等)位于框架中,并直接暴露给应用开发者。EJB3.0则相反,EJB3.0框架牢牢的集成到应用服务中,所有的服务集成代码都被封装到标准接口下面。

这样的设计使得EJB3.0的厂商可以集中优化总体性能,优化开发者体验。例如:在JBoss EJB3.0实现中,当你使用EntityManager持久化一个实体Bean POJO时,底层的Hibernate会话事务被自动的指派调用JTA事务的方法,并在JTA事务提交时被提交。使用一个简单的注释(annotation@PersistenceContext,就可以将EntityManager和底层的Hibernate事务绑定到一个有状态的会话Bean中应用事务中。应用事务在一个会话中跨越多线程,这在Web应用的事务处理中非常有用,比如一个包含多页面的购物车功能。这样的简单性和接口集成都得益于EJB3.0HibernateJBoss中的Tomcate的紧密集成。在Oracle EJB3.0框架中的情况是一致的,只不过Hibernate换成了TopLink而已。

EJB3.0服务集成的另一个例子是集群支持。如果你将一个EJB3.0应用部署到一个服务集群中,所有的负载均衡、分布缓存、状态复制等全都自动的生效了。底层的集群服务隐藏在EJB3.0编程接口后面,屏蔽了所有的复杂性。

Spring这边,优化框架和服务之间的交互要困难得多。比如,如果要使用Spring的声明式事务服务来管理Hibernate事务,必须手工显式的在XML配置文件中配置SpringTransactionManagerHibernateSessionFactory对象。Spring应用的开发者必须显式的管理那些跨越多个HTTP请求的事务。另外,Spring没有简单的利用集群的方法。

3. 服务装配灵活性 (Flexibility in Service Assembly)

 

因为Spring中的服务集成代码是以编程接口的形式发布的,所以应用开发者在装配服务时可以获得极大的灵活性。这使得开发者可以装备自己的轻量级的应用服务。Spring 的一个最普遍的应用就时粘合TomcatHibernate来支撑简单的数据库驱动应用。在这种情况下,Spring提供事务服务,Hibernate提供持久化服务,这样的配置构成了一个迷你型的应用。

EJB3.0应用服务没有给你这类可以选择的灵活性。在大多数情况下,你将得到一套已经打包好得特性,尽管其中有些你根本就用不着。当然,如果应用服务内部是模块化设计,比如JBoss,你可以剥离这些你不用得部分。这样得定制对一个成熟得应用服务是非常有价值的。

当然,如果应用发生伸缩,范围超出了单一服务节点,你就应该在应用服务中加入其他服务,如:资源池、消息队列、集群等。当加入这些后,Spring的解决方案已经和EJB3.0 一样重量级了。

使用Spring,服务装配的灵活性使得利用模拟对象(mock object)非常容易。模拟对象可以在单元测试中代替真实的服务对象,从而使得容器外测试得以成为可能。EJB3.0应用中,大部分组件都是简单的POJO,也很容易在容器外进行测试。但是,那些牵涉到容器对象的测试(如:EntityManager),容器内测试才是最佳选择,比使用模拟对象测试更简单、更健壮、更准确。

4. XML v.s 属性注释(XML Versus Annotation)

 

再应用开发者看来,Spring的编程接口主要是基于XML配置文件的基础上,而EJB3.0则大量使用Java注释。XML文件可以表达复杂的(从属)关系,但是也非常冗长而且不够健壮。注释则比较简单,但却很难表达复杂关系和子属结构。

SpringEJB3.0分别对XML配置文件和Java注释的选择是由两种框架背后的构架设计所决定的。因为注释只能容纳非常少量的配置信息,所以只有预集成的框架(大多少工作已经在框架内部完成)可以大量使用注释作为其配置解决方案。正如同我们已经讨论的那样,EJB3.0符合这种要求,而Spring,作为一种DI框架,就不能这么做。

当然,EJB3.0Spring都在发展中都相互借鉴了对方的长处,都在不同的程度上支持XML配置或Java注释配置。XML配置文件在EJB3.0中也被用来配置注释的缺省行为。而在Spring中,注释也用来配置Spring服务。

发表于: 2008-06-01 20:22 赛特达 阅读(2687) 评论(0) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册