> Alvaro, first, resources ARE available in South America. I started > leading projects in Argentina and Chile with J2EE in early 2000. I > worked for Neoris(formerly Amtec.net) at the time.
Agree with you here Juan. I�ve been working with J2EE projects since 2000, right here in Brazil. > > 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 Think it�s bad architecture desisions that drive people to create one huge jar containing all entities (250 in tis case...) > > The only way out(if it even applies) is to make some logical divisions > in your design, and couple EBs loosely(managing the relationships > yourself). I think, in component design, you can couple Entity Beans using CMR which makes design and developmente easier. > > Juan Pablo Lorandi > Chief Software Architect > Code Foundry Ltd. > [EMAIL PROTECTED] > > Barberstown, Straffan, Co. Kildare, Ireland. > Tel: +353-1-6012050 Fax: +353-1-6012051 > Mobile: +353-86-2157900 > www.codefoundry.com > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]] On Behalf Of Alvaro Mota > > Sent: Wednesday, October 09, 2002 6:28 PM > > To: [EMAIL PROTECTED] > > Subject: Multiple Appications > > > > > > Hi guys > > > > We are currently developing a large enterprise application started 10 > > months ago,over WebLogic > > 6.1/7.0. The architecture we are using is fully based on EJB�s 2.0 > > specification > > (local interfaces, CMRs, ...), with MCV structure and all web > > interfaces. There aren�t many people developing application > > using these J2EE specifications in Brazil right now, so it > > has been hard for us to find specialized technical assitance > > over here. We have done all our architecture decisions based > > on material we bought and found in the web; > > > > > > > > Among them, many of "theserverside" articles and others about J2EE > > technologies, > > design patterns and design tips. > > > > Based on the "EJB Design Pattern - Floyd Marinescu", page 200. > > -"Entity beans were meant to model the "entities" or domain > > objects in > > an application > > with the coming of EJB 2.0 CMP enhancements, including local > > interface, > > entity beans can now > > be used to model the domain objects in your designs as finely > > grained as > > you like." > > We have modeled a diagram class based on EJB entities. > > > > Because of the size of our application, we have over 250 > > deployed entity > > beans. > > We have a unique ejb-jar file that contains all our entities. > > > > In especification > > "10.3.2 The entity bean provider s view of persistent relationships > > > > ...Container-managed relationships can exist only among entity beans > > within the same local > > relationship scope, as defined by the relationships element in the > > deployment descriptor. > > Container-managed relationships are defined in terms of the local > > interfaces of the related beans. > > Relationships may be either bidirectional or unidirectional. If a > > relationship is bidirectional, > > it can be navigated in both directions, whereas a unidirectional > > relationship can be navigated in one direction only. > > " > > > > > > Following the new features brought by the EJB 2.0 > > specification as CMR, > > we have > > implemented all our entities with bidirectional relations > > managed by the > > container > > in one application. > > > > > > > > Right now, we are facing a list of problems: > > - Not being able to split our application in several modules, > > due to the > > the fact that > > all our classes are connected. > > - The EJBC and deployment time are too high, as a consequence of the > > huge number of > > entities. > > > > We want split the system in multiple applications so that we > > can deploy in the same domain. However, we don't know how to > > proceed causing the > > minimum impact. > > Has someone any hint or suggestion? > > Alvaro > > -- > > "Se um homem nao sabe a que porto se dirige, nenhum vento lhe sera > > favoravel !" > > > > ========================= > > 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". > > > > 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". ==========================================================================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".
