> > > > Second, no, CMR fields require to be on the same jar. I've > raised the > > issue before on the list, as I believe it puts huge > constraints on the > > ability to prepackage reusable components (such as, say, an > Address EB > > that is most common in many systems). > > Here I more or less disagree. Imagine a ClientEJB component. > You might not > want all the information such as home address, delivery > address, phones > etc in the same table. > This is a perfect example of a > reusable component > that may use CMP & CMR.
I fail to see why we disagree ;), but what about other code USING ClientEJB? If I code an Address CMP Bean(that handles many if not all Address use cases), sell it thru FlashLine to be used by Sven in Brazil within a CustomerEB he has to: 1) Loosely couple with Address(store the AddressPK in CustomerEB and get it when necessary, losing all EQL benefits). 2) Open the .jar I provide, extract the classes and add them to his own jar, extract the descriptor, merge it to his own descriptor. If he wishes to make LESS methods available to the Client, he might: 1) Create a fa�ade or wrapper. 2) Change the Remote interface distributed to clients. 3) Others(like role based method access). If you actually think of MORE EJBs, like a component suite, for instance, a Product Catalog/Stock control or your ClientEJB, then the loose coupling yields: a) Unneeded strain on performance. b) Enormous amount of superfluous code to wire to it. Because since the suite is in its own .jar file, it cannot have CMR with other EBs. You have to code lookups, integrate finders into your own, etc. It's a hell of a scenario. Basically, it'll be as expensive to connect to the suite as developing it from scratch, and it will be perform worse. Take a look at VBXtras or other Component Marketplaces, check out MTS enabled components/modules and compare those to Flash Line or similar. There are no commercial domain model solutions available in the J2EE world, only infrastructure ones(there are some non-comercial, but they're OSS; that's the only way to manage this shortcomings so far). The level of coupling/cohesion in DNA/.NET is left to the architect to decide; in J2EE, it's all or nothing. That also explains why many such initiatives, even OSS ones, have been born and silently died in the last 30 months or so. I'd (personally) like the CMR rules to be loosened to the point the 'Application Assembler' figure calls the shots on CMR extra JAR. Otherwise this role and the 'Bean Provider' (defined in J2EE 1.0) are to be one and the same. This is effectively killing the chance of J2EE building a strong component marketplace.(Not to mention that the few suites that were being sold are rendered abstract by the 2.1 spec, like the Timing Services. Flux is no longer needed). What I find disturbing is precisely that all these point in such direction, and I miss the rationale behind it. Hopefully, as promised, the EJB spec will move towards component oriented development soon. The argument I received to counter my position is that third party components are to be loosely coupled. By that definition, the market halves, and the reuse is reduced significantly(especially solution-domain/know-how expertise). I think Cedric was of this opinion, maybe he can add up to this. But, IMHO, the bottom line is that I shouldn't be forced to become a solution-domain expert, for each project. > > I Think it�s bad architecture desisions that drive people to > create one > huge jar containing all entities (250 in tis case...) > I agree. But I think there's a compromise here, between what is clean and needed/desired features. > > I think, in component design, you can couple Entity Beans > using CMR which > makes design and developmente easier. > Only if you plan on putting all of them in the same JAR. And according to you that would be a bad architecture desition ;). ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
