Menu
▾
▴
Re: [Springframework-developer] Replacing EBJs with Spring suggestions
|
From: Michael E. M. <mm...@re...> - 2005-09-19 18:58:00
|
Scalability and failover is crucial..
Thats why all my business logic is completely stateless, behind network
hardware
that handles that scaling/failover.
I don't like stateless EJBs for many reasons, but mainly because of the
threading model it specifies.. which promotes
the use of code that is not thread safe and hense non-portable outside
oof an EJB container.
The whole thread pooling mechanism in EJB is something we simply don't
need any longer.
There's a section in "Hibernate In Action" that has a teriffic
indictment of entity beans..
CMP was a specification dejour in my opinion. a huge mismatch for OOP/OOD.
maybe CMP 3.0 will help... heh.
1.3.4 Considering EJB entity beans
In recent years, Enterprise JavaBeans (EJBs) have been a recommended way
of persisting data. If you've been working in the field of Java
enterprise applications, you've probably worked with EJBs and entity
beans in particular. If you haven't, don't worry -- entity beans are
rapidly declining in popularity. (Many of the developer concerns will
be addressed in the new EJB 3.0 specification, however.)
Entity beans (in the current EJB 2.1 specification) are interesting
because, in contrast to the other solutions mentioned here, they were
created entirely by committee. The other solutions (the DAO pattern,
serialization, and ORM) were distilled from many years of experience;
they represent approaches that have stood the test of time.
Unsurprisingly, perhaps, EJB 2.1 entity beans have been a disaster in
practice. Design flaws in the EJB specification prevent bean-managed
persistence (BMP) entity beans from performing efficiently. A
marginally more acceptable solution is container-managed persistence
(CMP), at least since some glaring deficiencies of the EJB 1.1
specification were rectified.
Nevertheless, CMP doesn't represent a solution to the object/relational
mismatch. Here are six reasons why:
* CMP beans are defined in one-to-one correspondence to the tables
of the relational model. Thus, they're too coarse grained; they
may not take advantage of Java's rich typing. In a sense, CMP
forces your domain model into the normal form.
* On the other hand, CMP beans are also too fine grained to realize
the stated goal of EJB: the definition of reusable software
components. A reusable component should be a *very*
coarse-grained object, with an external interface that is stable
in the face of small changes to the database schema. (Yes, we
really did just claim that CMP entity beans are both too fine
grained and to coarse grained!)
* Although EJBs may take advantage of implementation inheritance ,
entity beans don't support polymorphic associations and queries,
one of the defining features of "true" ORM.
* Entity beans, despite the stated goal of the EJB specification,
aren't portable in practice. Capabilities of CMP engines vary
wildly between vendors, and the mapping meta-data is
vendor-specific. Some projects have chosen Hibernate for the
simple reason that Hibernate applications are more portable
between application servers.
* Entity beans aren't serializable. We find that we must define
additional data transfer objects (DTOs, also called value objects)
when we need to transport data to a remote client tier. The use
of fine-grained method calls from the client to a remote entity
bean instance is not scalable: DTO's provide a way of batching
remote data access. The DTO pattern results in the growth of
parallel class hierarchies, which each entity of the domain model
is represented as both an entity bean and a DTO.
* EJB is an intrusive model: it mandates an unnatural Java style and
makes reuse of code outside a specific container extremely
difficult. This is a huge barrier to unit test driven development
(TDD). It even causes problems in applications that require batch
processing or other offline functions.
We won't spend more time discussing the pros and cons of EJB 2.1 entity
beans. After looking at their persistence capabilities, we've come to
the conclusion that they aren't suitable for a full object mapping.
We'll see what the new EJB 3.0 specification can improve.
Eugene Kuleshov wrote:
> Michael,
>
> It seems that your position is quite extreme. :-)
>
> I wouldn't say that CMP is a mess. There are use cases for CMP's,
> thet perform quite well and would provide transactionality and caching
> (especially in a clustered environment).
>
> Besides cross-server transactionality, J2EE appservers provide a
> good deal of clustering, connection pooling (JDBC, JMS, JCA),
> security, remoting (RMI-IOOP) and other common services that would be
> just sily to reinvent. I'd say it makes a lot of sense to use those
> services when adding Spring's value into existing J2EE/EJB-based
> applications.
>
> regards,
> Eugene
>
>
> Michael E. Moores wrote:
>
>> Start by reading Rod Johnson's book on J2EE development without EJB.
>> http://www.springframework.org/node/23
>> There are some merits for using EJB, but in almost every single case
>> I have seen, you don't need them.
>>
>> EJB Entity Beans (CMP) is a huge mess; don't use them.
>
>
>> EJB containers provide distributed transaction capability; a business
>> transaction can span
>> multiple servers.. but I would try my very hardest not to introduce
>> that kind of tight coupling.
>>
>> I'm in the process of moving a Weblogic EJB application to
>> Spring/Hibernate.
>> I'm almost done.
>> The new product is less than 1/2 the code size (including config
>> files.. like the entity bean descriptors) and it runs about 40%
>> faster. All business logic is located in classes that depend upon
>> nothing but J2SE.. just
>> plain old java objects.. I can run/test the application stand alone,
>> as a SOAP service, as an RMI service.. all I do is change a property
>> file entry to do the switch. I can emulate dowstream services (stup
>> them out)
>> by swapping in a test stub in the Spring configuration.
>> I can do all my database persistence with a single graph of java
>> objects.
>> Hibernate persists the graph according to my Spring transaction
>> demarcations.
>>
>> Just for the fun of it, I wrapped my business POJOs with Spring's EJB
>> abstraction,
>> and deployed the application on JBoss. NO PROBLEMS!!!
>>
>>
>>
>> Garvey, Paul M (GE Commercial Finance) wrote:
>>
>>>
>>>
>>>
>>> Springers:
>>>
>>> I need your thoughts on an architectual issue. I have
>>> an application running on a websphere app server that uses IIOP to
>>> communicate
>>>
>>> with an EJB application running on another websphere instance on
>>> another websphere app server. I want to replace the 2 application
>>> with Spring.
>>>
>>> Any suggestions on how I can have 2 spring application communicating
>>> with each other? They will remain on 2 separtate websphere instances on
>>>
>>> 2 separate app servers? I am new to Spring so bear with me. I need
>>> to know what features in Spring allows me to replace my controller
>>> application
>>>
>>> to EJB application communication.
>>>
>>>
>>> -Paul
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
