z*******3
发帖数: 13709 | 1 抛砖引玉
吃饱了看文茜世界财经周报，看得昏昏的想睡，睡觉前赶紧写，写完睡觉去了
这样，先不从dto说起了，说tiers
一个j2ee经典的tiers最早提出来的时候，是三层，所谓的三层说的是sever side三层
不包括client side和database
三层里面分别有一层专门跟以上两个东西打交道
一个是presentation tier，这个跟client side打交道
一个是persistent tier，这个专门跟database打交道
中间还剩下一个叫做business tier，这么三层，这都很熟悉了
那么当初提出这个构想的时候
是基于以下一个方式
client side是applet＋browser
presentation tier是servlet+jsp，servlet是controller，jsp是viewer
model需要你自己去提取，去包装
business tier则是ejb，尤其是session bean，stateful和stateless
persistent tier也是ejb，是entity bean
database用jdbc连接
这五个... 阅读全帖 |
|
z*******3
发帖数: 13709 | 2 spring的普通bean，尤其是无状态的bean
什么controller, service, repository, component啊
scope无非两种，singleton和prototype
ejb有三种，singleton, stateless, stateful
这里，singleton是spring和ejb都有
ptototype和stateful是差不多的
但是不是一个东西
spring的singleton和ejb的singleton都是无节制的访问方法
任何线程可以在任何时间访问这个类的方法
同时因为这个类只有一个在内存中，所以不允许其保存任何状态
所谓状态就是private variable
否则这个状态会引发并发的异常
同时spring的prototype和ejb的stateful
都确保在访问这些bean的时候，新生一个bean
所以每一个线程拿到的都是新的bean
所以保证了线程与线程之间的独立，所以可以寄存状态
比如在线商店的购物车
所不同的是，ejb的stateful还提供了一个ejbPassive和ejbActive方法
当这个购物车滞留时间太久的时... 阅读全帖 |
|
t********k
发帖数: 808 | 3 开发EJB有下面二种方法
1.访问数据库放在EJB里面，包括SQL语言都放在里面
2.SQL语句放在一个JavaBean里，在此JavaBean里调用EJB，
把SQL语句作为参数传给EJB
方法1好处是如果团队开发，其它人或其它应该系统要访问EJB时很方便，
不用熟悉相关的数据库细节，我只要提供他们一个JavaBean接口就行了。
但此方法有一点不是很好，业务有变化时就要修改EJB。
方法2很灵活，万一业务有所变化，部署在服务器里的EJB不用变化，
只要修改客户端的JavaBean就行了，这样不用重启服务系统。但此方法
如果别人要访问EJB时很不方便，而且要熟悉数据库结构。
我记的用EJB就是为了能让其它系统访问本系统的资源更方便，那就要用方法1吧？
别人告诉我方法2，我觉的也不错，如果系统小而且没有向其它系统提供资源的需要时
大家能不能讨论一下这二方法？给些建议，谢谢！！！ |
|
z*******3
发帖数: 13709 | 4 其实一直以来，我觉得很多人，对于business tier这一层有很大误解
很多人至今还认为，这一层要么是presentation tier也就是web层的依附
要么是integration tier也就是跟db打交道那一层的依附
这是绝对错误的，从我学习j2ee的那一天起，我就坚持认为
business tier才是真正的核心，既不是web也不是db层的依附
所以每当看到别人说，ejb是web或者是db相关，我就觉得有点问题
因为web和db都有专门独立的tier与之配套并封装起来
而只有business tier这一层，无论是spring core也好，ejb的session bean也罢
都是不依附与其他外界的东西的存在，唯一需要的就是下面需要支撑的平台
也就是os和jvm，除此以外，他们是可以独立存在的核心
因为最早j2ee理论提出来的时候，就假设，现有的业务逻辑
是非常复杂的，也就是说定义了input/ouput之后
中间那一个，是假设是可以写很多很多的
所以以ejb为核心，定义其他的组件，所有组件以ejb为核心，围绕着ejb服务
而ejb本身可以打包成jar包，然后在不同的... 阅读全帖 |
|
w**********k
发帖数: 1135 | 5 摘译自：The Developer's Guide to Understainding
EJB 1.1 Applications.
EJB server是一个高层的进程或程序，管理EJB containers.
同时提供访问系统服务的方法。
EJB server也可以提供厂商特定的一些功能，如优化数据库访问、
提供其它服务，如CORBA services、SSL 3.0，等等。
一个EJB server要求提供JNDI(Java Naming and Directory Interface)
服务与事务(transaction)服务。
EJB server可以是：
.database servers
.application servers
.middleware servers |
|
m******t
发帖数: 2416 | 6 Why do we *have to* have a major
technical breakthrough on EJB? IMHO, the major issue of EJB after 2.0
is finalized is nothing but marketing. What is the advantage of
EJB vs. the classic servlet framework (there are still servlets
in the EJB architecture, but EJBs play bigger roles as far as
the business/data tiers are concerned)? Why would we
want to trade significance performance loss for EJB? Without
satisfactory answers to these questions, most of the world
will continue to stay with ser |
|
i****k
发帖数: 804 | 7 In general, use pure Java (POJO) vs. EJB as much as possible.
Architecturally speaking, once you start using EJB, your web services has a
dependency on a specific implementation technology - EJB. This brings a whole
bunch of issues. First, your MTR now includes an EJB container. Second, EJB
itself is a controversial technology. Some published J2EE experts have been
evangelizing J2EE architectures without EJBs, or only stateless session beans.
Third, your collegues will laugh at your design. :-) |
|
z*******3
发帖数: 13709 | 8 stateful在调用的thread结束之后，就可以被gc了
你说得没有错，无论是spring还是ejb
对于stateful和prototype都是不推荐使用的
在web层，也就是presentation层，推荐你使用HttpSession
google session tracking
然后在business层，无论是spring还是ejb
都推荐你使用无状态的singleton和stateless
当然stateless不是无状态，但是理论上最好不要加入如何状态的寄存
然后ejb推荐使用stateless，因为ejb认为singleton这种方式
是有一定风险的，尤其是当@Lock(write)的时候，会瞬间变为瓶颈
更有意思的是，这个@Lock(write)居然是缺省设置，所以当你使用singleton的时候
一定记住加上@Lock(read)，否则就是真的一个线程访问的单子
同时还有一种可能就是当这个bean坏掉了，怎么办？会同时导致其他线程受阻
所以一般来说，用ejb的人还是习惯使用stateless session bean
而ejb容器对于stateless sessi... 阅读全帖 |
|
z****e
发帖数: 54598 | 9 我个人觉得
tier划分清晰
对于整个系统的扩展以及将来跟其它系统做集成
有很重要的关系
所以强调web service
因为基于web service
发展出了很多理论，或者说构架
比如esb，比如bpel
这都是基于web service的实现
当然也支持有其它技术，但是相对少
所以层次之间的通信协议，是一个大topic
不同层次，用什么通信都有可能，但是趋势是xml的大统一
也就是将来不管跟什么系统搞，对方极有可能要求你发xml
同时会给你发一个xml文档
xml之后发明的绝大部分协议，都是xml的扩展
所以应该主动拥抱xml，拥抱web service
的确，这种tier通过这种方式连接，是一种比较松散的连接
但是松散的连接正是我所期望的，我认为一个好的分布式操作系统
就应该实现这种像组件一样，少了谁，系统一样转
同时来者不拒，只要愿意加入，系统就能接纳
这样才是一个健康或者说健壮的系统
比如说，我要设计一个系统
我还是首选用ejb做核心，提供主要的web service
剥离database上所有的业务逻辑要求，因为db本身负担已经很重了
随着系统规模的增加，db里面数据量一... 阅读全帖 |
|
z*******3
发帖数: 13709 | 10 business logic理论上是无状态的
换句话说，business这一层做的事情
一不碰web，二不碰persistence
只处理逻辑，最理想的business bean理论上都应该是无状态的
我们举个例子
比如有一个阿三，从web上发了一个request过来
那么如何handle这个request是web层的事
最基础的就是servlet了，然后是spring mvc，或者是struts，或者jsf etc.
然后这一层的这些东东把request里面的变量给取出来
包装成一个pojo，就是一个实体，set/get这些东西
然后把这个pojo留住，这是第一步
这一层是web层，spring里面叫做controller
或者是struts里面的action这些东西，这些都是controller
mvc里面其它的m就是刚才做的那个pojo
v就是jsp这些东西
然后第二步，用hibernate，ibatis等jpa实现包装db
封装所有的db操作，这是persistence层
一般来说你会写出一堆的dao类去封装各种db的操作
比如增删改查等等
spring里面叫做reposito... 阅读全帖 |
|
w**********k
发帖数: 1135 | 11 EJB components are server-side components written entirely in the
Java programming language
EJB components contain business logic only - no System-level
programming
System-level services (i.e. "plumbing") such as transactions, security,
Life-cycle, threading, persistence, etc. are automatically managed for
the EJB component by the EJB server
EJB architecture in inherently transactional, distributed, portable,
multi-tier, scalable and secure
Components are declaratively customized at deployment t |
|
w**********k
发帖数: 1135 | 12 EJB technology benefits a number of audiences:
Enterprise customers that build and/or deploy EJB-based applications
- gain development productivity, can choose from a wide selection of
EJB servers, create business logic that runs everywhere and is
architecture independent, all this while protecting their existing IT
investment!
ISVs and SIs that develop EJB components or applications based on
EJB components - Invest in business logic that is widely deployable,
across any OS and middleware, don't |
|
c***c
发帖数: 6234 | 13 I am using
1. JBoss 4.0 for EJB
2. Axis For Web Services
3. Eclipse as IDE
I generated a EJB called TestBean.java in package test/ejb.
The Xdoclet generated ejb-jar.xml, Test.java and TestHome.java for me in
package test/interfaces
compile passed
The deploy.wsdd is
http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
|
|
r***l
发帖数: 67 | 14 Guess you do not know web service very well. There's no EJB web service per
se.
Web service has nothing to do with platform and a specific technology, e.g.
EJB.
Web service comes with two flavor (style) - RPC or Document.
In Java world, you can wrap a EJB with a web service. Then, your EJB will be
invoked from other language/platform, e.g. .NET. The web service on top of EJB
can be either RPC style or Document style.
So, you question itself is kind of wrong already. Web service looks simple,
but |
|
c***c
发帖数: 6234 | 15 Yes I am new in Web Services. My boss just gave me a concept and I have to
figure out everything
In wsdd file, there is either provider="RPC" or provider="EJB". If I am using
EJB in web services, I have toconvert java code to EJB, generate local and
remote interfaces and create ejb-jar.xml. If I do not use EJB, I can keep old
java code as business methods and simply wirte deploy.wsdd file to deploy the
web services. So I think "RPC" is much simplier.
Thank you very much. I will read more to dige |
|
S*********t
发帖数: 78 | 16 EJB 3.1 Early Draft Now Available
I'm happy to announce that the Enterprise JavaBeansTM (EJB) 3.1 Early Draft
is now available.
The Expert Group has been working hard since we launched JSR 318 last August
and we're looking forward to your feedback. Please send comments to jsr-318
-*******[email protected]
The EJB 3.1 Specification has two main goals. The first is a continued focus
on ease-of-use. The EJB 3.0 Specification made a huge improvement in this
area with the introduction of the EJB Simplified A |
|
z*******3
发帖数: 13709 | 17 http://en.wikipedia.org/wiki/Enterprise_JavaBeans
ejb应该做的是跟spring core差不多的事
spring本来就是打算做一个轻量级的ejb
是business logic层
hibernate是jpa的实现
是persistence层
不是一层，以前ejb还包括entity bean
那entity bean是做跟hibernate一样的事
后来被hibernate干掉了，ejb3就取消了entity bean
这样ejb就再也不跟hibernate是类似的东西了
另外ejb还包括message driven bean
也就是jms机制，这个是spring所没有的
jms什么都是用来跟其它系统集成的 |
|
z*******3
发帖数: 13709 | 18 我换一种方式解释
java是这么一种东西
当你打算用java去写系统的时候
你面对的是一堆乱七八糟的软件
这就包括web服务器，数据库，操作系统等等
那么你打算让这些东东合作
好在呢，这些东东跟java都有自己的一套接口
坏处呢，这些接口都十分原始
也就是基本上都只能做到通过接口传递原始数据类型的地步
不是int就是string这些东西，比如web，基本上就只有string
而且更不妙的是，往往有私货，比如sql就是专门针对db而言的
除此之外，你还有自己需要实现的一套逻辑
因为这个系统肯定不是说把数据从web中拔出来
直接插进到数据库中去，或者从db中拔出来，直接扔给浏览器就ok了的
一般来说，你都需要在这中间再倒腾倒腾
那怎么办？
所以建议就是
你针对你需要与之合作的那个软件，单独写一层，用来封装这个软件产品
所以就用struts/spring mvc这些来封装web服务器
用hibernate/ibatis这些来封装db
保证最后通过这些接口进出的数据都是pojo，也就是java beans
然后你再用spring core或者ejb来处理这写pojo之间的关系
所以spring... 阅读全帖 |
|
z*******3
发帖数: 13709 | 19 突然明白为什么楼主会以为ejb跟hibernate一样了
看到wikipedias上的这个例子
@Stateless
public class CustomerService {
@PersistenceContext
private EntityManager entityManager;
public void addCustomer(Customer customer) {
entityManager.persist(customer);
}
}
这里面有persist操作，让楼主以为是跟hibernate一样的
其实这是不对的，这里的entityManager就是hibernate里面的sessionfactory和
session
简化了操作，但是并不代表ejb就是hibernate
而wikipedia里面的命名也遵守了传统的命名方式
你看是*Service，说明这是一个service
也就对应了spring里面的@Service注释
说明是business层的bean，不是persistence的bean
当然ejb容器都默认实现了jpa，所以不需... 阅读全帖 |
|
z*******3
发帖数: 13709 | 20 wikipedia上的例子很好，所以调用ejb的就是web层了
如果是persistence层的话，那应该有一层business层
Such an EJB can be used by a class in e.g. the web layer as follows:
@Named
@RequestScoped
public class CustomerBacking {
@EJB
private CustomerService customerService;
public String addCustomer() {
customerService.addCustomer(customer);
context.addMessage(...); // abbreviated for brevity
return "customer_overview";
}
}
越往后面变化越小
ejb干脆就干掉了hibernate之类的
直接变成api了
如果自己倒腾hibernate
还要搞定sessionfactory和session，... 阅读全帖 |
|
z*******3
发帖数: 13709 | 21 以后会剥离出ejb
Enterprise JavaBeans
The EJB 3.0 specification (itself part of the Java EE 5 platform) included a
definition of the Java Persistence API. However, end-users do not need an
EJB container or a Java EE application server in order to run applications
that use this persistence API.[1] Future versions of the Java Persistence
API will be defined in a separate JSR and specification rather than in the
EJB JSR/specification.
The Java Persistence API replaces the persistence solution of EJB 2.0 C... 阅读全帖 |
|
w**********k
发帖数: 1135 | 22 The EJB specification mandates that you must use the RMI interfaces to
communicate with an EJB component. The EJB specification does not
mandate which wire protocol (like CORBAs IIOP) to use. If you were to
build an EJB server on top of CORBA, using RMI/IIOP would be a natural
fit. |
|
n*****a
发帖数: 4 | 23
seems WebLogic is very popular now, u can download it.
I think EJB is just as other Java programs, you do not need
special tool for it. EJB only contains your business logic.
You can find tutorial about EJB at Javasoft, I download it
before, you shld also download J2EE to run examples.
Did your sevlet and JDBC guarantee transaction, multi-user
safe and scalability? That's the most important issues in
business world. EJB automatically guarantee it and you just
need to concentrate on business log |
|
n**s
发帖数: 3 | 24 About returning a collection of resultSet:
Actually EJB can do it elegantly by calling Finder methods.
What wildwest said is probably
true. If you want millions of records from your database,
the performance will be
terrible. But I guess that should rarely happen. If you
want to find a collection
of reasonable number of records, say 1000, it is actually
not that bad in EJB.
Actually EJB container will not generate 1000 bean
instances, it only generate 1000
primary keys and propably 1000 EJB o |
|
W******c
发帖数: 23 | 25 What is the main stream then?
There are interesting discussion there.
From theserverside.com:
"According to a recent survey of 150 CIOs, only 9% of them
have
adopted EJB as a solution, with 14% using EJB partially and
16% still
evaluating it. This supports my theory that EJB is still in
a fast
growing market and that the true large-scale adoption of EJB
is at the
tail-end of the Geoffrey Moore's scale, to which we are
slowly but
surely moving towards. " |
|
v******e
发帖数: 63 | 26 I guess you are using Axis soap implementation. EJB means you have to deploy
a EJB somewhere, and aixs dispatch engine will call that ejb. If you don't
have a EJB server (weblogic or websphere), you cannot use this option at all.
using
old
the
per
e.g.
be
simple,
about
by |
|
z*******3
发帖数: 13709 | 27 你们才是大牛，我是凑热闹的
我觉得thin client说的是html的那个browser
thick client是游戏客户端这种
当然ejb本身也可以作为ejb的client
这也不稀奇，只要对方有jvm，就可以被调用
rmi是底层的java实现，只要有java的地方，就可以实现rmi
但是rmi不好用，ejb的remote接口在rmi-iiop上实现了一层封装
好很多了
同时从另外一个角度说，web service虽然最早源起于web
但是应用在web server和app server的通信上也不是不可以
而且理论上效率不应该太差
因为rest是在tcp之上用http实现request,用xml封装response
而传统的rmi是在tcp之上用iiop实现request和response
再用serializable实现不同jvm上的类重现
唯一的区别就在于，rest需要用xml解码，把类里面的value给提取出来
其实这两个都是用tcp协议，实际传送的都是io stream
然后再从stream到具体的class，不应该有太大差距
所以只要这个网络条件相同，rmi，ejb的... 阅读全帖 |
|
z*******3
发帖数: 13709 | 28 最近倒腾了一下guice，觉得蛮有趣，这三个东西的差异还是挺明显的
对于stateless ejb来说
每一个bean同时只能被一个thread访问
对于多个thread的并发，ejb通过pooling来解决
所以当thread多的时候，ejb数量也会增加
一般来说10个ejb可以应付60个甚至更多的threads的访问
对于spring来说
每一个bean缺省设置可以同时被无数个thread同时访问
缺省设置为singleton
所以建议把所有spring管理的bean设置为无状态的bean
否则并发访问这些状态会出问题
同时启动比较慢
因为它在启动时候会实例化几乎所有的singleton
对于guice来说
每一个bean缺省设置是new一个新对象给申请的thread
缺省设置是prototype
这样做的好处就是内存动态变化，启动快
只有在需要时候才会实例化对象
但是这种无穷尽地new对象会导致gc负担加重
动不动就要gc一下，不是很适合大型的项目
所以建议有经验的程序猿
参考spring的做法，尽可能多地.in(Singleton.class)
以达到复用bean的目的，因为对... 阅读全帖 |
|
w**********k
发帖数: 1135 | 29 No. In fact, EJB technology complements CORBA quite nicely. CORBA
provides a great Standards-based infrastructure on which to build EJB
servers. EJB technology makes it easier to build application on top of a
CORBA infrastructure. |
|
w**********k
发帖数: 1135 | 30 摘译自：The Developer's Guide to Understainding
EJB 1.1 Applications.
EJB container管理EJB 类(classes)和/或实例(instances).
它负责为bean提供诸如事务控制(transaction control)、
生命期管理(lifecycle management)和安全性。
container对于客户端与bean来说是不可见的。但事实上，
所有bean的方法调用都被container载获，这样container
可以透明地提供bean各种它所需要的服务。 |
|
w**********k
发帖数: 1135 | 31 Bean Provider
相当于控件提供商
Application Assembler
相当于应用开发商
EJB Deployer
相当于系统管理员
EJB Container Vendor
EJB Server Vendor |
|
z****u
发帖数: 15 | 32 EJB and Corba are merging together. It was described as a "shotgun marriage".
Both EJB and Corba are now supported in major application servers.
I don't remember what exactly happens but EJB is using Corba IIOP (RMI over
IIOP) as its communication protocol and Corba also benefits from some features
in Java. |
|
c*****a
发帖数: 15 | 33 The EJB is not only about data persistence, it is also a framework to help you
to handle security, threading, transaction management etc.
The choice 2 is actually putting DAOs in front of EJBs. The reccmmended
practice is placing them behind EJBs. The db structure still can be
encapsulated in those DAOs, not really pollutes the presentation layer.
It is a little trick to avoid restarting of application server when you change
SQLs. However I do not understand why the restarting of application ser |
|
c***c
发帖数: 6234 | 34 I was using EJB web services. Now I found that RPC web services is much
simpler. It also has OUT, INOUT parameter. RPC web serivces can be used by
.NET
I have to modify EJB web services to RPC web services.
What is advantage of EJB web services? Thanks |
|
c*****s
发帖数: 214 | 35 任何web service都有输入输出参数，都和语言无关，都可以用在.NET上，都是一种RPC的
机制
你所谓的EJB webservice应该是一些能从现成EJB产生webservice的wsdl，例子客户端程
序等文件的工具吧。如果是这样，好处当然是和EJB结合紧密，开发方便了。 |
|
A**o
发帖数: 1550 | 36 you need implementation of EJB container to run your EJBs. something like
sun's glassfish, apache's geronimo, or red hat's jboss, etc... then you '
deploy' your ejb jar file into those servers. |
|
t*******e
发帖数: 684 | 37 Stateful session beans are designed to be used within a session scope,
meaning, different bean instances of the same bean class are instantiated to
maintain client-specific data. If you make a SFSB application scope --
shared by all client sessions, EJB containers are supposed to raise a
concurrent access exception according to the EJB specification. In WebLogic,
you may specify "allow-concurrent-calls" to be true in weblogic-ejb-jar.xml
file to override the default behavior. However, it is stil |
|
e*****t
发帖数: 1005 | 38 这篇是好文，讲的历史沿革,还有层次都很清晰。
吹毛求疵一点点：
1. ejb刚出来的时候，persistence tier主流不是hibernate，应该是jdbc,至于ORM，
应该最热的是iBais。当然hibernate是在ejb2年代热起来的，所以ejb3搞jpa就直接弄
来Gavin King，照搬了hibernate
2. Spring当初是lightweight,现在整个spring一点也不light，应该是比javaEE整个标
准加起来都庞大，只不过大家平日只是用到其中一部分而已：Spring core, Spring
security, Spring MVC, and etc...
3. Entity bean还是JavaEE的概念，Spring那帮人就是不好那个，所以搞POJO.所以提
到data object时，对于spring,还是说pojo来的比较好。
4. Hibernate是red hat的,jboss也是red hat的。不过hibernate至少现在不是jboss的。
5. Spring最初也不过是从POJO, IoC，和transaction搞起来的... 阅读全帖 |
|
z****e
发帖数: 54598 | 39 那是容器用的方法
一般不需要override
就是ejbpassive和ejbactive，都可以不要override
提供给你，唯一的目的就是问问用户
你有没有额外需要寄存或者销毁的东西，比如在构造器里面打开一个jdbc连接并寄存为
状态
在remove的时候，最好关闭连接，因为有些时候
用户会主动申请关闭不了的资源，尤其是涉及到io的时候
但是这个都是不提倡的，一般没人这么用，这种容器用的方法，大多数时候不推荐
override
如果是以前版本，就是有home接口的话，override后方法体留空就可以了
如果没有什么需要关闭的话
用ejb最好的地方就是容器托管，如果连销毁ejb都要自己手动编码
那不成写core java了
随手google的，参考
Re: Should i call EJB′s remove?[ GO TO TOP ]
POSTED BY: Jeryl Cook POSTED ON: June 22 2007 10:56 EDT in response to sawan
parihar
Never used it..in most cases u don't n... 阅读全帖 |
|
s******e
发帖数: 493 | 40 as said before, spring started eying ejb, but later it evolves to an
application framework. Comparing ejb to spring is just like comparing ejb
container to application server, for example, comparing tomcat to full scale
application servers such as glassfish, weblogic, websphere, or even jboss. |
|
z****e
发帖数: 54598 | 41 这个很难理解吗？
因为ejb是标准化的组件，从诞生的那一天起，所有的规范都需要讨论后投票表决
而spring是私人的产品，现在是一家公司的产品，只要是公司的产品
说变就变，这是它的权力，就跟.net是微软的东西一样
ejb本身并不是impl，而是一个interface，就跟其他所有的j2ee组件一样
都不过是一个标准，你愿意你也可以自己去实现你的ejb容器
就跟jboss一样，而spring本身并不是一个标准，是一个产品的名字
就跟.net没有太大区别，只不过它更兼容其他标准化的组件
所谓的依赖就是要摆脱某一家公司的产品，就是换其他家公司的东西
照用不误，这才叫不依赖，不兼容标准的产品很多，但是你有选择标准的权力
你完全也有不选择标准的权力，我就是要跟定spring了，这也是你的权力
但是这就是依赖，就这么简单的一个定义，有什么很难理解的么？
不要以为开源了之后就万事大吉了，mysql也是开源的
现在在oracle的胯下呻吟，只要有大公司愿意，收购spring不过是钱的问题
事实上spring早已经被收购了，这跟apache是完全不同
apache是非赢利组织，而springsourc... 阅读全帖 |
|
a****i
发帖数: 1182 | 42 重点根本不在于有几家做j2ee
我提M$只是说所有公司和M$都没什么区别，他们能独占市场加自己的料的时候，绝对不
会手软
什么标准不标准？他们就是要搞自己的一套，让你用了他们的东西就只能一直用下去
把别的那些标准公司都搞死才好
spring，如果把自己搞死了，起码我有它没死时候的代码，可以自己弄
这就是控制力
jcp对ejb有控制力，跟你有什么关系？
你对ejb还是一点控制力也没有
再说，jcp要是把ejb搞死了呢？
你觉得投票就不会搞死了？ |
|
g*****g
发帖数: 34805 | 43 Regarding vendor lock-in. Spring has two advantages.
1. It's Apache license, so someone can branch it if there's no continued
support. Think of how Amazon takes on Google's Android code.
2. Spring is an embedded container, which makes it more flexible than
standalone ejb container. Say if Spring becomes legacy code and everybody is
using ejb, you can put that piece of legacy code in your ejb 10.0 container
. You can't do it the other way around. i.e. Spring has less dependency. It'
s like compar... 阅读全帖 |
|
z*******3
发帖数: 13709 | 44 我估计也是
这种legacy code
要想一下子理解，不是那么容易
毕竟不规范
你这种问题问一下其他老员工
也就是一分钟的事
远比你自己在这里问然后找要容易得多
j2ee就是这样，层与层之间的关联
没有你想得那么容易
往往这些关联是用框架来实现
也就是你光看代码，你是找不到的
你得去看配置文件，所以就很不直观
所以这就是为什么我长期强调规范代码
因为规范的代码查起来有官方文档的帮忙
不规范的代码，除了公司自己的人知道，就没有人知道了
不过你这个还好，图画出来我大概明白了
层次是这样
jsp->servlet(封装pojo，也就是实体，set/get方法)->ejb->bo?->*dao(这里应该是用
上了虚拟类的继承)->db
够原始的系统，ejb1.x版本时候的事，struts什么都没用上
好处是对你基础的提高很有帮助
你断掉的那个逻辑是在servlet到ejb之间
看ejb的配置文件，还有就是这个servlet应该有一个总的dispatcher
就是总的派发servlet的类，找找这个类，大概读一读代码
也许能够领悟，不过这非常不容易，我一般遇到这种就直接问了
问同事会快很多，没... 阅读全帖 |
|
n******1
发帖数: 3756 | 45 最近在看struts,spring这些东西，也有很多demo可以run，其实这些东西用起来不难，
而且一般在tomcat下就可以
我想至少从EJB2开始学习比较好，因为不知道什么是heavy，就比较难理解lightweight
，但苦于EJB确实有点heavy，部署EJB还需要EJB容器，然后不同厂家的部署也不一样？
EJB2和EJB3有没有比较好的入门tutorial？ 可以自己做些配置，run一下，理解会容易
一点 |
|
w**********k
发帖数: 1135 | 46 We've gotten a lot of great feedback from partners and the industry as a
whole since we released Enterprise JavaBeans technology on March 23,
1998. In response to this feedback, we're pleased to announce the following
roadmap for Enterprise JavaBeans Technology.
In order to effectively manage the orderly development of EJB technology,
we've mapped out 3 releases for EJB specification.
Release Name: Moscone
Features: Tightening of spec requirements for compatibility, XML
technology deployment inf |
|
w**********k
发帖数: 1135 | 47 The EJB 1.0 specification calls for dependencies on JNDI for finding EJB
components, and the Java Transaction API (JTA) for programmatically
starting and stopping transactions. |
|
w**********k
发帖数: 1135 | 48 EJB is an architecture. MTS is a product. EJB allows for choice. MTS
allows only one choice, Microsoft's. |
|
w**********k
发帖数: 1135 | 49 EJB Server
EJB Container
Home
create()
remove()
EJBObject
Remote
Client business methods Bean
EJBObject
Remote
business methods Bean
Services
|
|
|
