Using CMP2 and XML to process dynamic numeric objects

The entity EJB is typically used for model coarse-grained domain objects before EJB 2.0 local references and container-managed relationships occur. This is mainly due to the overhead associated with remote communications and the blocking of fine-grained access to the enterprise tier of client-tier objects. The performance of coarse-grained design facilitates improvement by implementing numeric objects, compressing all data, which means passing data between the customer layer and the enterprise layer. Using a complex system with a large number of domain objects, even if it provides a first-class and highly performing design, this design causes too many numeric objects to appear in the system. This also creates a tight connection between the enterprise layer and the customer layer. Similarly, in the presence of EJBS, the bean provider has to explicitly provide programs to maintain joins between domain objects. In a situation where there is a complex relationship between domain objects, the design of numeric objects becomes complex. In the process of developing enterprise applications using EJBS, the emergence of container-managed relationships and local references opens up exciting new avenues. In this article, I'll take you through the powerful approach of EJB 2.0 with bean components and JAXP to create dynamic, xml-based XML that delivers information between your enterprise and presentation tiers.

Using XML in the process of passing data from the enterprise layer to the customer tier can help you with many loose connections in your current application; However, when you add a new domain object to the entity type, you may need to add the class to create the new DOM schema to add the entity. In this article, we will develop a framework to dynamically traverse container-managed domains related to a given local EJB, and create an XML piece that can be passed between multiple tiers of the application. This approach will have the following advantages:

Facilitate easy connections between the enterprise layer and the customer tier.

Facilitates the management of relationships between domain objects.

To remove a complex numeric object from the system because XML is generated by dynamically traversing the CMP and CMR domains, the bean provider does not have to create new object classes to create a new DOM schema when they add new objects to the domain model.

EJB 2.0 local references facilitate access to the bean component, and a bean component combined with a local reference can be included in the relationship with other container-managed beans. For example, in a Help system, USEREJB can have one to many two-way relationships with SERVICEREQUESTEJB and one to one one-way contact with PRODUCTEJB as well as a two-way relationship with SERVICEREQUESTHISTORYEJB. USEREJB can have a two-way relationship with PHONEEJB one to many at the same time. Thus, using EJB 2.0 local references and container-managed relationships, you can design a complex set of related bodies. Container management persistence and relational domains are legal by using abstract accessor procedures in the Bean class. Accessor methods for relational domains either return a collection or return the native interface of the bean that defines the system, depending on the capacity of the set of relationships. These accessor methods are displayed through the native interface of the bean component. An in-depth study of EJB 2.0 is beyond the scope of this article, see the specification for EJB 2.0.

An efficient design pattern should show the use case of your application through the appearance component and no direct access to entity components from the client tier. Back to our Help system example, one of the use cases is to get detailed information for a given user. The external component can look for the required user entity components and obtain the required data from the container management persistence and relational domain and return it to the presentation layer.

An obvious choice for a data transfer object is a simple Java bean. Userbean may have properties that represent persistence and relational fields. This relational domain is either java.util.Collection or other bean components that depend on the relationship. Userbean may have Servicerequestbean and Phonebean sets. Servicerequestbean may have a productbean and many servicerequesthistory bean components. In addition, these bean components may also have a simple string or performance container to manage the basic properties of the persistence domain. The main downside of this choice is to make your entity model more complex, make your data-Transfer object Bean level more complex, and create a tight connection between your service (enterprise) layer and the consumer (presentation) layer. To study the complex layers of this relationship, a better option is to use XML DOM objects as data transfer objects. Your component will produce Oeg.w3c.dom.Document object types and your performance component uses XML JSP custom tags and XSLT files to "consume" them.

Now, the next question is: How do you create an XML file from a CMP local bean reference? We can use a factory based on methods for creating different types of DOM components, however, this will create too many "workshop" components and you may need to add new "workshop" components as your entity model extensions. What we need is a common program that can use entity local objects, boot containers to manage relationships, and create dynamic DOM schemas. This utility will be responsible for circular references in two-way relationships to avoid infinite loops and deep navigation of relational elements.