The starting point of our association elimination procedure is an information design model with various kinds of unidirectional and bidirectional associations, such as the model shown in Figure 1.1 above. If the model still contains any non-directed associations, we first have to turn them into directed ones by making a decision on the ownership of their ends, which is typically based on navigability requirements.

Notice that both associations in the Publisher-Book-Author information design model, publisher-publishedBooks and authoredBooks-authors (or Authorship), are bidirectional as indicated by the ownership dots at both association ends. For eliminating all explicit associations from an information design model, we have to perform the following steps:

A unidirectional association connecting a source with a target class is replaced with a corresponding reference property in its source class having the target class as its range. Its multiplicity is the same as the multiplicity of the target association end. Its name is the name of the association end, if there is any, otherwise it is set to the name of the target class (possibly pluralized, if the reference property is multi-valued).

A bidirectional association, such as the authorship association between the classes Book and Author in the model shown in Figure 1.1 above, is replaced with a pair of mutually inverse reference properties, such as Book::authors and Author::authoredBooks. Since both reference properties represent the same information (the same set of binary relationships), it's an option to consider one of them being the "master" and the other one the "slave", which is derived from the master. We discuss the two cases of a one-to-one and a many-to-many association

After replacing both bidirectional associations with reference properties, we obtain the following OO class model:

Figure 1.4. The OO class model

Since books are entities that existentially depend on authors and possibly on publishers, and not the other way around, it's natural to maintain the master references in book objects, and consider the inverse references in publisher and author objects as derived (or slave) data. Therefore, we define publishedBooks and authoredBooks as derived inverse reference properties, which is indicated by their slash prefix in the OO class model.

Compared to the unidirectional association app discussed in a previous tutorial, we have to deal with a number of new technical issues:

These steps are discussed in more detail in the following sections.

In the Publisher class, we add the publishedBooks property and we use the @OneToMany annotation corresponding to @ManyToOne from the Book class, representing the inverse relation:

@Entity
public class Publisher { 
  ...
  @OneToMany( fetch=FetchType.EAGER, mappedBy="publisher")
  private Set<Book> publishedBooks;
  ...
}

The mappedBy parameter of the @OneToMany annotation of the Publisher::publishedBooks property specifies the property that implements the @ManyToOne relation in the Book class:

@Entity
public class Book { 
  ...
  @ManyToOne( fetch=FetchType.EAGER)
  @JoinColumn( name="PUBLISHER_NAME")
  private Publisher publisher;
  ...
}

In the Author class we add the authoredBooks property with the @ManyToMany annotation corresponding to @ManyToMany from the Book class representing the inverse relation:

@Entity
public class Author {
  ...
  @ManyToMany( fetch=FetchType.EAGER, mappedBy="authors")
  private Set<Book> authoredBooks;
  ...
}

The mappedBy property of the @ManyToMany annotation for authoredBooks property of the Author class specifies the property name which implements the @ManyToMany relation in the Book class:

@Entity...
public class Book {
  ...
  @ManyToMany( fetch=FetchType.EAGER)
  @JoinTable( name="books_authors", 
      joinColumns = { @JoinColumn( name="BOOK_ISBN") }, 
      inverseJoinColumns = { @JoinColumn( name="AUTHOR_PERSONID") })
  private Set<Author> authors;
  ...
}

We also use the @JoinTable annotation to specify the join table name for the Many-To-Many relation and the corresponding colum names for the join table, e.g., the table is books_authors and the columns are named BOOK_ISBN and AUTHOR_PERSONID.

Any setter for a reference property that is coupled to a derived inverse reference property (implementing a bidirectional association), now also needs to assign/add/remove inverse references to/from the corresponding value (set) of the inverse property. An example of such a setter is the following setPublisher method:

public class Book {
  ...
  public void setPublisher( Publisher publisher) {
    // remove the book from the publishedBooks 
    // of the old publisher (if not null)
    if ( this.publisher != null) {
      this.publisher.removePublishedBook( this);
    }
    // add the book to publishedBooks 
    // of the new publisher (if not null)
    if ( publisher != null) {
      publisher.addPublishedBook( this);
    }
    this.publisher = publisher;
  }
}

For any multi-valued reference property that is coupled to a derived inverse reference property, both the add and the remove method also have to assign/add/remove corresponding references to/from (the value set of) the inverse property.

For instance, for the multi-valued reference property Book::authors that is coupled to the derived inverse reference property Author:authoredBooks for implementing the bidirectional authorship association between Book and Author, the addAuthor method is coded in the following way:

public class Book {
  ...
  public void addAuthor( Author author) {
    if ( this.authors == null) {
      this.authors = new HashSet<Author>();
    }
    if ( !this.authors.contains( author)) {
      // add the new author reference
      this.authors.add( author);
      // add the derived inverse reference
      author.addAuthoredBook( this);
    }
  }
}

For the remove operation removeAuthor we obtain the following code:

public class Book {
  ...
  public void removeAuthor( Author author) {
    if ( this.authors != null && author != null && this.authors.contains( author)) {
      // delete the author reference
      this.authors.remove( author);
      // delete the derived inverse reference 
      author.removeAuthoredBook( this);
    }
  }
}

Remember, for a Java Collection, such as Set or List, the contains method compares two objects by using the equals method of the objects. For example, for using the contains method over a Set<Authors>, such as publishedBooks, in the Author class we implement the following equals method (two authors are equal if their personId property values are equal):

public class Author {
  ...
  @Override
  public boolean equals( Object obj) {
    if (obj instanceof Author) {
      Author author = (Author) obj;
      return ( this.personId.equals( author.personId));
    } else return false;
  }
  ...
}

When a Book instance b, with a single reference b.publisher to a Publisher instance p and multiple references b.authors to Author instances, is destroyed, the derived inverse references have to be removed first (e.g., by removing b from p.publishedBooks). This is accomplished by calling the set methods for the single and multi-valued properties with a null parameter, e.g., b.setPublisher(null) and b.setAuthors(null) within the Book.destroy method:

public class Book {
  ...
  public static void destroy( EntityManager em, UserTransaction ut, String isbn) throws Exception {
    ut.begin();
    Book b = em.find( Book.class, isbn);
    b.setPublisher( null);
    b.setAuthors( null);
    em.remove( b);
    ut.commit();  
  }
}

In the same way, we have to take care of deleting the references with the Book when deleting a Publisher or an Author instance:

public class Author {
  ...
  public static void destroy( EntityManager em, UserTransaction ut, Integer personId) throws Exception {
    ut.begin();
    Author a = em.find( Author.class, personId);
    a.setAuthoredBooks( null);
    em.remove( a);
    ut.commit();
  }
}

public class Publisher { 
  public static void destroy( EntityManager em, UserTransaction ut, String name) throws Exception {
    ut.begin();
    Publisher p = em.find( Publisher.class, name);
    p.setPublishedBooks( null);
    em.remove( p);
    ut.commit();
  }
}

Unfortunately, JPA does not provide automatic maintenance of derived inverse references. According to the Java Persistence Wiki, we have to implement the (direct and inverse) relations management within set/add/remove methods: A common problem with bidirectional relationships is the application updates one side of the relationship, but the other side does not get updated, and becomes out of sync. In JPA, as in Java in general, it is the responsibility of the application or the object model to maintain relationships. If your application adds to one side of a relationship, then it must add to the other side. This is commonly resolved through add or set methods in the object model that handle both sides of the relationships, so the application code does not need to worry about it. There are two ways to go about this: you can either add the relationship maintenance code to only one side of the relationship, and only use the setter from that side (such as making the other side protected), or add it to both sides and ensure you avoid an infinite loop.

We have used for each controller class an entity manager. Every entity manager maintains a set of cached entities which can be "shared" with other entity managers by using the merge method. In our example code, as part of the create and update static methods of each model class, we have to merge the updated entities which belongs to another entity manager. For example, for the in the case of Book.create method, we need to merge the publisher (managed by the entity manager used by the PublisherController class) and all the authors (managed by the entity manager used by the AuthorController class) which were referenced in the new Book instance:

public class Book {
  public static void create( EntityManager em, UserTransaction ut, 
                          String isbn, String title, Integer year, 
                          Publisher publisher, Set<Author> authors) 
                     throws Exception {
    ut.begin();
    Book book = new Book( isbn, title, year, publisher, authors);
    em.persist( book);
    if ( publisher != null) {
      em.merge( publisher);
    }
    if ( authors != null)
      for ( Author a : authors) {
        em.merge( a);
      }
    }
    ut.commit();
  }
}

Without using merge, the publisher as well as all author instances from the authors list, does not represents references to the originally cached entities, and are not going to retain our changes, e.g., when needs to be reused later with other Book instances. For more details, please check the Java Persistence Documentation related to this matter.

It is also possible to disable the JPA caching, so the entities are reloaded from database for every new instance, e.g., when EntityManager.find method is called. This can be achieved by adding the following line in the persistence.xml file:

<property name = "eclipselink.cache.shared.default" value = "false"/>

The above configuration works for eclipselink impelementation and it may be different for other API implementations. Notice that disabling entity caching is not recommended without a serious reason, while it comes with performance loss and may produce unpredicted behavior in some cases, such as using @SessionScoped managed entities.

For showing information about published books in the list publishers use case, we can now exploit the derived inverse reference property publishedBooks:

<ui:composition template="/WEB-INF/templates/page.xhtml">
  <ui:define name="content">
    <h:dataTable value="#{publisherController.publishers}" var="p">
      ...
      <h:column>
        <f:facet name="header">Published books</f:facet>
        <h:outputText value="#{p.publishedBooks}" escape="false" converter="pl.m.converter.BookListConverter"/>
      </h:column>
    </h:dataTable>
    <h:button value="Back" outcome="index" />
  </ui:define>
</ui:composition>

In the case of unidirectional associations, for the case of list books use case, we have used a method in the Book model class, i.e., getAuthorNames(), which returns a text containing the comma separed author names of the book:

public class Book {
  ...
  public String getAuthorNames() {
    String result = "";
    int i = 0, n = 0;
    if ( this.authors != null) {
      n = this.authors.size();
      for ( Author author : this.authors) {
        result += author.getName();
        if ( i < n - 1) {
          result += ", ";
        }
        i++;
      }
    }
    return result;
  } 
}

This makes sense in the case of a book, since the number of authors is in general limited to a small number. However, a Publisher may have a large number of published books. As a better alternative to our string serialization, we can use a JSF converter class which allows us to present the list of authors in a custom way. In our case, we choose to present it as list of names, where every name is presented on a separat line. For this, we implement the pl.m.converter.BookListConverter class and we annotate it with @FacesConverter as follows:

@FacesConverter( value = "pl.m.converter.BookListConverter")
public class BookListConverter implements Converter {
  @Override
  public Object getAsObject( FacesContext context, UIComponent component, String value) {
    // no need for mapping to object...
    return null;
  }
  @Override
  public String getAsString( FacesContext context, UIComponent component, Object value) {
    String result = "";
    int i = 0, n = 0;
    if ( value == null) {
      return null;
    } else if ( value instanceof Set<?>) {
      n = ((Set<Book>) value).size();
      for ( Book b : (Set<Book>) value) {
        result += b.getTitle();
        if ( i < n - 1) {
          result += "<br />";
        }
        i++;
      }
      return result;
    }
    return null;
  }
}

Then, we use the converter attribute in the facelet to specify that our converter class, e.g., pl.m.converter.BookListConverter, has to be used when the respective view component needs to be rendered:

<h:column>
  <f:facet name="header">Published books</f:facet>
  <h:outputText value="#{p.publishedBooks}" escape="false" converter="pl.m.converter.BookListConverter"/>
</h:column>

Since the serialization text contains HTML elements, i.e., <br /> to produce HTML new lines, we have to specify the @escape = "false" attribute, otherwise < and > will be replaced with the corresponding < and > entities.

The main advantage of using JSF converters is that we do not mix model code with view specific code, so our model classes remains clean and later, if we like to replace JSF with other framework, then our model class reamins unchanged, and we just need to take care of a corresponding converter for the new framework.