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.
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). 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). 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".
