Sorry to chime in so late, but I have a few comments... Firstly, from Rickard.
> I intend to write a whitey on it some day too, but basically it goes > something like this: > * Meta-programming is good, but not inherent to EJB > * The EJB programming model in general is flawed. (See EJB-INTEREST for > lots of conflicting answers to common questions. If experts can't figure > it out, how are mortals supposed to?!) Every programming model is flawed. The same thing is happening to EJB as did CORBA as it matures. These so-called "experts" you talk about get in there and beef up a rather simple specification to support all of their esoteric use cases. What these experts end up doing making these specifications more resitant to change and the industry ends up having to think of another programming model. I saw this crap when I was in the CORBA world. I agree with Marc. These experts are "donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses".(Thanks for the humor Marc, I really needed it.) Nextly.... > > |Because..? > > |1) Bean A uses bean B. B dies, but C that implements the same interface > > |is still alive. Now what's A supposed to do? How will it be notified > > |that B is dead, and how is it supposed to find C? (with > hardcoding these > > |dependencies in of course) > > > > Rickard you are talking of dependencies. The EJB spec defines > dependencies > > in XML (soft) the proxies can implement failover, if you need > notification > > (say to restart) you can be notified through many other > frameworks including > > JMX and jini. > > > Well, EJB's can't use Jini (can't hold on to a ServiceDiscoveryManager > for example). If you want the proxies to do the failover, which would be > entirely possible, you need to be able to let them point to many various > instances of possibly different implementations. I guess the EJB > interface/spec in itself would allow for this, but it would require > quite a lof of the EJB container, as opposed to a rather simple hack in > JMX/Jini. > Actually, it would not require a lot of the container. Sacha Labourey and I have developed a pretty simple framework to provide fail-over and load-balancing for EJBs. Basically, we've integrated JavaGroups into this framework and will eventually see if JINI/JavaSpaces can fit in as well. > Alright, you may have a point, but it's not really valid until it gets > implemented *well*. > Well, it is implemented. Go check it out. It's probably "flawed", but it will do the job for now. > > > |2) Bean A stores files in a particular directory. The name of the > > |directory changes. A needs to be alerted of this. How? Change the XML > > |file with environment settings and redeploy? Gee.. great... > > > > A notification of state change can be achieved by other means. A simple > > reset of context in most cases would do that. Rickard these > are truly minor > > points that can be solved for the price of a callback on the > bean. They are > > by no means "show stoppers" that invalidate the model (which > really doesn't > > worry itself with these). We can do it simply in JBoss by > offering an MBean > > in the EJB, you can certainly push for it in spec commitee (if > you are in > > the commitee). Heck! require an MBean for the properties > (pointers and what > > not), and you are done. > > > So you'd need to go outside EJB for such a common requirement as runtime > reconfiguration? Is that good? > > Sorry, but it's still bad. However, one of the key reasons why I don't > like EJB, is because it's overused. People use it for things they > shouldn't use it for, especially for web applications where the web > client and EJB's are in the same JVM. And you still need to go through > the remote interface, thus introducing a whole bunch of heavyweight > patterns such as Data Transfer Objects. > Why do people think that EJB's only purpose is for remoting? I think its great for defining transaction and security boundaries between interfaces and hiding the implementation of this from the programmer. The real power of EJB is in the packaging and deployment. Bill _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
