Browse Prior Art Database

Code Generated for Supporting Associations between EJBs at EJB Creation Time

IP.com Disclosure Number: IPCOM000013758D
Original Publication Date: 2000-Jan-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 55K

Publishing Venue

IBM

Abstract

In the Unified Modeling Language (UML), associations represent relationships that relate two or more classes (Enterprise JavaBeans (EJB) classes in this case) where the relationships have common characteristics or features. One such common characteristic is multiplicity between the classes. Multiplicity specifies how many objects of a class are associated with a single object of the other class in the association. If an object of a class can be associated with only a single object of the other class, it is a 1:1 relationship. It is a 1:m relationship if the object of a class can be associated with multiple objects of the other class.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 3

Code Generated for Supporting Associations between EJBs at EJB Creation Time

     In the Unified Modeling Language (UML), associations represent relationships that relate two or more classes (Enterprise JavaBeans (EJB) classes in this case) where the relationships have common characteristics or features. One such common characteristic is multiplicity between the classes. Multiplicity specifies how many objects of a class are associated with a single object of the other class in the association. If an object of a class can be associated with only a single object of the other class, it is a 1:1 relationship. It is a 1:m relationship if the object of a class can be associated with multiple objects of the other class.

The concept of associations has not been introduced into Sun Microsystems, Inc.'s EJB specification. Accordingly, EJB tooling may be provided that introduces associations as a way to allow Java bean developers to define relationships among EJB components and to drive the relevant generated code into the enterprise bean class and interfaces to support the associations. For example, there typically is a 1:m relationship between EJB components that represent an employee (Employee) and a department (Department), i.e., each employee belongs to a department and a department may have many employees. To define such an association, the bean developer needs to specify the participating EJB components (i.e., Department and Employee), and the multiplicity and navigability of each end of the association. When an association is defined, proper methods and fields will be added to the enterprise bean class and interfaces of the participating EJB components to provide the users of these EJB components the functionality specified by the association. For example, users may get the Department EJB object to which an Employee EJB object belongs or all the Employee EJB objects associated with a Department EJB object, depending on the navigability.

In a typical implementation of associations in EJB development tools, the code generated for association support can be divided into two parts. First, the methods and fields code is generated into the enterprise bean class and remote and home interfaces of the associated EJB components when the associations are defined at the creation time of those components. Second, implementation and persister classes are generated at deployment time to persist the association and support the navigability.

This disclosure only addresses the first part - code generated for association support at creation time of the associated EJB components. A fundamental design consideration and objective was to provide a code pattern to support associations at the creation time of the associated EJB components such that the bean class for those components is fully specified at creation time, and not changed at all during deployment. Without the code pattern described herein, the enterprise bean class or remote and home interfaces...