"EJB 3.0  simplifies   enterprise bean types"

what is the *possible*  meaning to this wording ? There is not much
relevant context I can give here.

Does that mean it does not have remote and home interface ? or there
is some more meaning attached to this ?

comments please.

On 08-10-2010 00:32, gk wrote:
> "EJB 3.0  simplifies   enterprise bean types"
>
> what is the *possible*  meaning to this wording ? There is not much
> relevant context I can give here.
>
> Does that mean it does not have remote and home interface ? or there
> is some more meaning attached to this ?

It is a very imprecise statement, but I am guessing that they mean:
* annotations instead of XML
* simpler model for interfaces and implementation class

In my opinion the "simplification" is 80% hype and 20% reality,
but ...

Arne

On 10/08/2010 04:50 PM, Arne Vajhøj wrote:
> On 08-10-2010 00:32, gk wrote:
>> "EJB 3.0 simplifies enterprise bean types"
>>
>> what is the *possible* meaning to this wording ? There is not much
>> relevant context I can give here.
>>
>> Does that mean it does not have remote and home interface ? or there
>> is some more meaning attached to this ?

That is what it means, from a programmer's perspective.  It also means that 
there's a lot less boilerplate code in your EJBs.

It doesn't mean that EJBs are now automatically the right thing to use in any 
particular application.

> It is a very imprecise statement, but I am guessing that they mean:
> * annotations instead of XML
> * simpler model for interfaces and implementation class
>
> In my opinion the "simplification" is 80% hype and 20% reality,
> but ...

The simplification is plenty real, just limited in scope.  The coding model is 
much simpler, and eliminates the crazy disconnection between EJBs and the 
interfaces they implement.  Deployment is not simplified.

-- 
Lew

On 08-10-2010 18:22, Lew wrote:
> On 10/08/2010 04:50 PM, Arne Vajhøj wrote:
>> It is a very imprecise statement, but I am guessing that they mean:
>> * annotations instead of XML
>> * simpler model for interfaces and implementation class
>>
>> In my opinion the "simplification" is 80% hype and 20% reality,
>> but ...
>
> The simplification is plenty real, just limited in scope. The coding
> model is much simpler, and eliminates the crazy disconnection between
> EJBs and the interfaces they implement. Deployment is not simplified.

It is simpler, but how much does it really impact the big picture.
I would be surprised if that simplification reduced development
hours with more than 0.5%.

Arne

Arne Vajh�j wrote:
> On 08-10-2010 18:22, Lew wrote:
>> On 10/08/2010 04:50 PM, Arne Vajh�j wrote:
>>> It is a very imprecise statement, but I am guessing that they mean:
>>> * annotations instead of XML
>>> * simpler model for interfaces and implementation class
>>>
>>> In my opinion the "simplification" is 80% hype and 20% reality,
>>> but ...
>>
>> The simplification is plenty real, just limited in scope. The coding
>> model is much simpler, and eliminates the crazy disconnection between
>> EJBs and the interfaces they implement. Deployment is not simplified.
>
> It is simpler, but how much does it really impact the big picture.
> I would be surprised if that simplification reduced development
> hours with more than 0.5%.
>
> Arne

Depends on the size and composition of the project, but you won't be far 
off. Thing is too, even with EJB 1.x once you figured out the techniques for 
one class of beans - CMP entity beans, BMP entity beans, SFSBs, SLSBs, how 
to set them up and code them and call them - it was all boilerplate after, 
and didn't add that much to the effort. For any project that has hundreds 
(or more) EJBs of various types I don't suppose the simplifications matter 
all that much. I'll agree with Lew that the coding model is indisputably 
cleaner, but I doubt we're saving much time because of it.

AHS
-- 
The difference between a moral man and a man of honor is that the
latter regrets a discreditable act, even when it has worked and he has
not been caught. -- H.L. Mencken 

Arved Sandstrom wrote:
> Depends on the size and composition of the project, but you won't be far
> off. Thing is too, even with EJB 1.x once you figured out the techniques for
> one class of beans - CMP entity beans, BMP entity beans, SFSBs, SLSBs, how
> to set them up and code them and call them - it was all boilerplate after,
> and didn't add that much to the effort. For any project that has hundreds
> (or more) EJBs of various types I don't suppose the simplifications matter
> all that much. I'll agree with Lew that the coding model is indisputably
> cleaner, but I doubt we're saving much time because of it.

It's been bugging me since EJBs came out - when is it worthwhile to use 'em?

Many developers I knew were gun-shy of EJBs, having used them.  I've used them 
on jobs - unwieldy sometimes, but always a few folks in the shop understand 
them well.  Heck, I've written and debugged them, too, but the rationale for 
their existence never seemed much beyond, "The architect said to put 'em 
here."  Excuse me, "The Architect said ..."

One alternative is POJOs; repeat for each web app.  It's not too hard to write 
the same component many times (copy-and-paste helps, natch).  True, there are 
fragilities in the build-from-common-skeleton approach.  Are they worse than 
the difficulties with EJBs?  Holistically, you must consider both coding and 
operational effort.

Maybe it's the way people used them that's soured me.  Maybe I just haven't 
seen well-rationalized EJBs in practice.

I'm playing with Glassfish now, and portal, seeking the Renaissance ideal of 
rapid development AND deployment.  Facility with the tools should yield 
insight into their proper niche.

One place I see the call for EJBs is Transaction World.  and the work world 
abounds with demands for multiple access points to common application 
services.  (Example: Separate GUI, custom XML and SOAP web service endpoint 
access to an online shopping site.)

The mentality of the "new" EJB appeals to the way I think.  Instead of 
thinking about "Home" and "Remote" interfaces and keeping them straight from 
the Java keyword sense, I'm thinking about business logic and message flow 
with hooks into the enterprise framework.  It's more like aspect-oriented 
programming - the EJB-ness offers hatchways into shared context.

It is possible to deploy EJBs now, and JPA stuff, with relatively light 
reliance on orthogonal XML deployment descriptors.  Too many deployment 
environments I've seen have put the "ugh" in "spaghetti".  At least with the 
3.0 way that is not required.

What is the true power of EJBs?
What is the right way to use them?

-- 
Lew
You are in a maze of twisty little passages, all alike.
- Crowther and Woods

On 11-10-2010 23:14, Lew wrote:
> It's been bugging me since EJBs came out - when is it worthwhile to use
> 'em?
>
> Many developers I knew were gun-shy of EJBs, having used them. I've used
> them on jobs - unwieldy sometimes, but always a few folks in the shop
> understand them well. Heck, I've written and debugged them, too, but the
> rationale for their existence never seemed much beyond, "The architect
> said to put 'em here." Excuse me, "The Architect said ..."
>
> One alternative is POJOs; repeat for each web app. It's not too hard to
> write the same component many times (copy-and-paste helps, natch). True,
> there are fragilities in the build-from-common-skeleton approach. Are
> they worse than the difficulties with EJBs? Holistically, you must
> consider both coding and operational effort.
>
> Maybe it's the way people used them that's soured me. Maybe I just
> haven't seen well-rationalized EJBs in practice.

> One place I see the call for EJBs is Transaction World. and the work
> world abounds with demands for multiple access points to common
> application services. (Example: Separate GUI, custom XML and SOAP web
> service endpoint access to an online shopping site.)
>
> The mentality of the "new" EJB appeals to the way I think. Instead of
> thinking about "Home" and "Remote" interfaces and keeping them straight
> from the Java keyword sense, I'm thinking about business logic and
> message flow with hooks into the enterprise framework. It's more like
> aspect-oriented programming - the EJB-ness offers hatchways into shared
> context.

> What is the true power of EJBs?
> What is the right way to use them?

If you have some business logic where you can use one or more of:
- container managed transactions
- container managed thread pool
- container managed security
- strong rules about what Java features are not allowed
then using EJB's is simpler than creating custom solutions
achieving the same.

SLSB's and MDB's are quite nice. And even SFSB's can be useful.

(EB's were a great solution for a non-existing problem)

10 years ago they looked very complex, but today they look very simple.

A little bit because EJB 3.x simplified some things and a lot because
other frameworks has become much more complex.

 > It is possible to deploy EJBs now, and JPA stuff, with relatively light
 > reliance on orthogonal XML deployment descriptors. Too many deployment
 > environments I've seen have put the "ugh" in "spaghetti". At least with
 > the 3.0 way that is not required.

I have never seen the big benefits of having deployment information
spread out in dozens of source files instead of a central deployment
descriptor.

Arne