Composite entity pattern

Last updated

Composite entity is a Java EE Software design pattern and it is used to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity beans, and also a composite entity bean represents a graph of objects. [1]

Contents

Structure

There are a number of strategies to implement composite entity pattern. This pattern mainly composites of composite entity, coarse-grained object, and dependent objects. [1]

Composite entity pattern class diagram Composte entity pattern class diagram.png
Composite entity pattern class diagram


Composite entity component

Composite entity is the coarse-grained entity bean which may be the coarse-grained object, or may contain a reference to the coarse-grained object. [1]

Coarse-grained object

A coarse-grained object is an object with its own life cycle manages its own relationships to other objects. It can be an object contained in the composite entity, or, composite entity itself can be the coarse-grained object which holds dependent objects. [1]

Dependent objects

It is an object, which can contain other dependent objects (there may be a tree of objects within the composite entity), that depends on the coarse-grained object and has its life cycle managed by the coarse-grained object. [1]

Consequences

According to Oracle description of the pattern, consequences include eliminating inter-entity relationships, improving manageability by reducing entity beans, improving network performance, reducing database schema dependency, increasing object granularity, facilitating composite transfer object creation and overhead of multi-level dependent object graphs. [1]

Drawbacks

The fatal drawback is the requirement of bean-managed persistent (BMP) bean. This involves more work for developers, and create some problems as follows:

Composite entity pattern can only be implemented using BMP or by adding more hand-coded persistence logic to container managed persistence (CMP) beans. These both approaches reduce the maintainability. [2]

Sample code

Sample code for a Professional Service Automation application (PSA) in which the resource object is implemented via composite entity pattern, may look like as follows (entity implements coarse-grained object):

packagecorepatterns.apps.psa.ejb;importcorepatterns.apps.psa.core.*;importcorepatterns.apps.psa.dao.*;importjava.sql.*;importjavax.sql.*;importjava.util.*;importjavax.ejb.*;importjavax.naming.*;publicclassResourceEntityimplementsEntityBean{publicStringemployeeId;publicStringlastName;publicStringfirstName;publicStringdepartmentId;publicStringpracticeGroup;publicStringtitle;publicStringgrade;publicStringemail;publicStringphone;publicStringcell;publicStringpager;publicStringmanagerId;// Collection of BlockOutTime Dependent objectspublicCollectionblockoutTimes;// Collection of SkillSet Dependent objectspublicCollectionskillSets;...privateEntityContextcontext;// Entity Bean methods implementationpublicStringejbCreate(ResourceTOresource)throwsCreateException{try{this.employeeId=resource.employeeId;setResourceData(resource);getResourceDAO().create(resource);}catch(Exceptionex){thrownewEJBException("Reason:"+...);}returnthis.employeeId;}publicStringejbFindByPrimaryKey(StringprimaryKey)throwsFinderException{booleanresult;try{ResourceDAOresourceDAO=getResourceDAO();result=resourceDAO.selectByPrimaryKey(primaryKey);}catch(Exceptionex){thrownewEJBException("Reason:"+...);}if(result){returnprimaryKey;}else{thrownewObjectNotFoundException(...);}}publicvoidejbRemove(){try{// Remove dependent objectsif(this.skillSets!=null){SkillSetDAOskillSetDAO=getSkillSetDAO();skillSetDAO.setResourceID(employeeId);skillSetDAO.deleteAll();skillSets=null;}if(this.blockoutTime!=null){BlockOutTimeDAOblockouttimeDAO=getBlockOutTimeDAO();blockouttimeDAO.setResourceID(employeeId);blockouttimeDAO.deleteAll();blockOutTimes=null;}// Remove the resource from the persistent storeResourceDAOresourceDAO=newResourceDAO(employeeId);resourceDAO.delete();}catch(ResourceExceptionex){thrownewEJBException("Reason:"+...);}catch(BlockOutTimeExceptionex){thrownewEJBException("Reason:"+...);}catch(Exceptionexception){...}}publicvoidsetEntityContext(EntityContextcontext){this.context=context;}publicvoidunsetEntityContext(){context=null;}publicvoidejbActivate(){employeeId=(String)context.getPrimaryKey();}publicvoidejbPassivate(){employeeId=null;}publicvoidejbLoad(){try{// load the resource info fromResourceDAOresourceDAO=getResourceDAO();setResourceData((ResourceTO)resourceDAO.load(employeeId));// Load other dependent objects, if necessary...}catch(Exceptionex){thrownewEJBException("Reason:"+...);}}publicvoidejbStore(){try{// Store resource informationgetResourceDAO().update(getResourceData());// Store dependent objects as needed...}catch(SkillSetExceptionex){thrownewEJBException("Reason:"+...);}catch(BlockOutTimeExceptionex){thrownewEJBException("Reason:"+...);}...}publicvoidejbPostCreate(ResourceTOresource){}// Method to Get Resource Transfer ObjectpublicResourceTOgetResourceTO(){// create a new Resource Transfer ObjectResourceTOresourceTO=newResourceTO(employeeId);// copy all values resourceTO.lastName=lastName;resourceTO.firstName=firstName;resourceTO.departmentId=departmentId;...returnresourceTO;}publicvoidsetResourceData(ResourceTOresourceTO){// copy values from Transfer Object into entity beanemployeeId=resourceTO.employeeId;lastName=resourceTO.lastName;...}// Method to get dependent Transfer ObjectspublicCollectiongetSkillSetsData(){// If skillSets is not loaded, load it first.// See Lazy Load strategy implementation.returnskillSets;}...// other get and set methods as needed...// Entity bean business methodspublicvoidaddBlockOutTimes(CollectionmoreBOTs)throwsBlockOutTimeException{// Note: moreBOTs is a collection of // BlockOutTimeTO objectstry{IteratormoreIter=moreBOTs.iterator();while(moreIter.hasNext()){BlockOutTimeTObotTO=(BlockOutTimeTO)moreIter.next();if(!(blockOutTimeExists(botTO))){// add BlockOutTimeTO to collectionbotTO.setNew();blockOutTime.add(botTO);}else{// BlockOutTimeTO already exists, cannot addthrownewBlockOutTimeException(...);}}}catch(Exceptionexception){thrownewEJBException(...);}}publicvoidaddSkillSet(CollectionmoreSkills)throwsSkillSetException{// similar to addBlockOutTime() implementation...}...publicvoidupdateBlockOutTime(CollectionupdBOTs)throwsBlockOutTimeException{try{IteratorbotIter=blockOutTimes.iterator();IteratorupdIter=updBOTs.iterator();while(updIter.hasNext()){BlockOutTimeTObotTO=(BlockOutTimeTO)updIter.next();while(botIter.hasNext()){BlockOutTimeTOexistingBOT=(BlockOutTimeTO)botIter.next();// compare key values to locate BlockOutTimeif(existingBOT.equals(botTO)){// Found BlockOutTime in collection// replace old BlockOutTimeTO with new onebotTO.setDirty();//modified old dependentbotTO.resetNew();//not a new dependentexistingBOT=botTO;}}}}catch(Exceptionexc){thrownewEJBException(...);}}publicvoidupdateSkillSet(CollectionupdSkills)throwsCommitmentException{// similar to updateBlockOutTime......}...}

[1]

See also

Related Research Articles

Jakarta Enterprise Beans is one of several Java APIs for modular construction of enterprise software. EJB is a server-side software component that encapsulates business logic of an application. An EJB web container provides a runtime environment for web related software components, including computer security, Java servlet lifecycle management, transaction processing, and other web services. The EJB specification is a subset of the Java EE specification.

The Jakarta Transactions, one of the Jakarta EE APIs, enables distributed transactions to be done across multiple X/Open XA resources in a Java environment. JTA was a specification developed under the Java Community Process as JSR 907. JTA provides for:

Jakarta EE

Jakarta EE, formerly Java Platform, Enterprise Edition and Java 2 Platform, Enterprise Edition (J2EE) is a set of specifications, extending Java SE 8 with specifications for enterprise features such as distributed computing and web services. Jakarta EE applications are run on reference runtimes, that can be microservices or application servers, which handle transactions, security, scalability, concurrency and management of the components it is deploying.

In object-oriented programming, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the container's elements. The iterator pattern decouples algorithms from containers; in some cases, algorithms are necessarily container-specific and thus cannot be decoupled.

In software engineering, the mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior.

In computer programming, run-time type information or run-time type identification (RTTI) is a feature of the C++ programming language that exposes information about an object's data type at runtime. Run-time type information can apply to simple data types, such as integers and characters, or to generic types. This is a C++ specialization of a more general concept called type introspection. Similar mechanisms are also known in other programming languages, such as Object Pascal (Delphi).

Java syntax

The syntax of Java refers to the set of rules defining how a Java program is written and interpreted.

In computing based on the Java Platform, JavaBeans are classes that encapsulate many objects into a single object. They are serializable, have a zero-argument constructor, and allow access to properties using getter and setter methods. The name "Bean" was given to encompass this standard, which aims to create reusable software components for Java.

In software engineering, dependency injection is a technique in which an object receives other objects that it depends on. These other objects are called dependencies. In the typical "using" relationship the receiving object is called a client and the passed object is called a service. The code that passes the service to the client can be many kinds of things and is called the injector. Instead of the client specifying which service it will use, the injector tells the client what service to use. The "injection" refers to the passing of a dependency into the object that would use it.

In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any special restriction. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:

"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."

The object pool pattern is a software creational design pattern that uses a set of initialized objects kept ready to use – a "pool" – rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object to the pool rather than destroying it; this can be done manually or automatically.

Exception handling syntax is the set of keywords and/or structures provided by a computer programming language to allow exception handling, which separates the handling of errors that arise during a program's operation from its ordinary processes. Syntax for exception handling varies between programming languages, partly to cover semantic differences but largely to fit into each language's overall syntactic structure. Some languages do not call the relevant concept "exception handling"; others may not have direct facilities for it, but can still provide means to implement it.

In the Java computer programming language, an annotation is a form of syntactic metadata that can be added to Java source code. Classes, methods, variables, parameters and Java packages may be annotated. Like Javadoc tags, Java annotations can be read from source files. Unlike Javadoc tags, Java annotations can also be embedded in and read from Java class files generated by the Java compiler. This allows annotations to be retained by the Java virtual machine at run-time and read via reflection. It is possible to create meta-annotations out of the existing ones in Java.

Jakarta Persistence is a Jakarta EE application programming interface specification that describes the management of relational data in enterprise Java applications.

In software engineering, a fluent interface is an object-oriented API whose design relies extensively on method chaining. Its goal is to increase code legibility by creating a domain-specific language (DSL). The term was coined in 2005 by Eric Evans and Martin Fowler.

This article describes the syntax of the C# programming language. The features described are compatible with .NET Framework and Mono.

In the Java programming language, heap pollution is a situation that arises when a variable of a parameterized type refers to an object that is not of that parameterized type. This situation is normally detected during compilation and indicated with an unchecked warning. Later, during runtime heap pollution will often cause a ClassCastException.

The Brutos Application Framework is MVC controller written in Java. Designed to reduce the complexity of web development, with configurable mapping, view resolution as well as support for uploading and downloading files. Can be configured using XML, annotations and CoC.

Castor is a data binding framework for Java with some features like Java to Java-to-XML binding, Java-to-SQL persistence, paths between Java objects, XML documents, relational tables, etc. Castor is one of the oldest data binding projects.

Business delegate is a Java EE design pattern. This pattern is directing to reduce the coupling in between business services and the connected presentation tier, and to hide the implementation details of services. Business delegates acts as an adaptor to invoke business objects from the presentation tier.

References

  1. 1 2 3 4 5 6 7 "Core J2EE Patterns - Composite Entity". Oracle. Oracle. Retrieved 6 February 2016.
  2. Johnson, R. (2003). Expert One-on-One J2EE Design and Development. Indianapolis: Wiley Publishing, Inc. p. 290.