IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New IDE Generating boilerplate
violates Blanchard's law.

Anyhow, if its boilerplate, then it could be assumed, right?

So why have it?

J2EE remains a (very popular) joke.


The tree of research must from time to time be refreshed with the blood of bean counters.
     -- Alan Kay
New Can someone give a good explanation of Home, Remote, etc?
Why does J2EE actually need all these? For some reason it is fuzzy to me at the moment. I seem to recall it has something to do with the fact that Java is statically typed and we want to work with proxy objects.

As I mentioned, I worked with Gemstone almost 10 years ago, and it was a dream to work with. J2EE is still nowhere near where Gemstone was then.
New It *doesn't* need them.
That's the frustrating part. The separate interfaces, linked only with a separate config file, are the crazed concoction of some idiot at Sun. Try making inherited EJBs sometime... great fun.*

This could all be accomplished with reflection much more easily.





* In the same way that peeling strips of flesh off your arm with a rusty fishhook is fun for people with self-destructive tendencies...
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New I think EJB's came from IBM
New Theoretical distributability
Home is the creator/manager of instances. In Smalltalk this role is accomplished by the Class. Because Java lacks class objects, the Home was created to fulfill this role. Home is an interface - an implementation may create a local object or a proxy to a remote object. IOW, there are typically two implementations of Home and its job is to be a factory of instances.

The actual object is also defined as an interface where each method claims it could throw RemoteException (which is useless if you are using local ejb). The tools generate two implementations of this interface - one is a proxy, the other an empty implementation that you fill in with your object's actual implementation.


Now you can theoretically locate your objects anywhere you like - in your process or another one using remote calls. The theory is you don't care, split your processing any way you like.

The reality is there are huge performance impacts when locating objects outside the local process - factor of 1000 slowdowns are not uncommon.

The whole thing is of dubious value - for performance you want to do as much in your vm as possible (integrate vertically) and distribute horizontally (lots of vms all alike, each with everything) vs lots of vms doing specific tasks cooperating in a big system.

The former scales quite well, the latter tends to spend most cycles in marshalling/networking/unmarshalling work.



The tree of research must from time to time be refreshed with the blood of bean counters.
     -- Alan Kay
     Are EJBs really this painful? - (ben_tilly) - (15)
         AdminiScott's dislike of them seems rather reasonable. -NT - (CRConrad)
         Yes ... - (bluke) - (5)
             IDE Generating boilerplate - (tuberculosis) - (4)
                 Can someone give a good explanation of Home, Remote, etc? - (bluke) - (3)
                     It *doesn't* need them. - (admin) - (1)
                         I think EJB's came from IBM -NT - (bluke)
                     Theoretical distributability - (tuberculosis)
         Yes. -NT - (admin)
         It's worse - (ChrisR)
         They purposely F'd it up to make OO look bad -NT - (tablizer) - (4)
             Actually EJB's have little to do with OO - (bluke) - (3)
                 So bad that no paradigm wants to claim it? - (tablizer) - (2)
                     Huh? Are you making up stuff as you go along, again? - (CRConrad) - (1)
                         Old school usenet style. -NT - (jake123)
         OK, I get it! - (jb4)

That money came from someplace.
75 ms