Smaller systems often mock out the business objects in a direct one to one relational mapping to a database table. My little site is a good example; a blog is a well know problem domain and the data objects that are presented to the view do not really differ from the rows in a table. As an example, this is the table I store tags in:

class GoopTag(SQLObject):
    class sqlmeta:
        table='goop_tag'
    garticle = ForeignKey('GoopArticle')
    name = StringCol(length=255,notNone=True)
    tag_order = IntCol(default=0)
    created = DateTimeCol(default=datetime.now

There is no need to create a separate data transfer object (DTO) or value object (VO) to support that structure. However with modern ORMs, including Entity Beans, any relation that comes with a table and is saved in the model, if that is propagated to the view, then all the trailing relationships will come with it. For complex schemas an entire domain model can be dragged up through the system and exposed to the view. This is bad, especially when interacting with third parties.

For larger J2EE systems they are often communicating via remote interfaces and webservices. Presenting the Entity beans as the model through those interfaces means that any changes to the schema will break the outward systems. In a changing business model and a corporate environment of constant change this volatility can be minimized by slapping interfaces over the Entity beans, alternatively, better practice is to create a separate set of value objects that are simple POJOs that do nothing but store data in such a way that it can be transferred across webservice and remote interfaces.

Containers that support distributed systems include service buses. This is intended as the place to orchestrate and aggregate the webservice calls in a Service Oriented Architecture. This is useful when hiding the complexity of calls to multiple systems behind the service bus as one call, but for the majority of calls it tends to be pass through as the calling to one system or another is largely clean and does not require aggregation.

The DTOs that come from the service bus are usually defined in XSD as part of the WSDLs that are being exposed from the service bus. Consequently a J2EE system has many levels of DTOs that need to be exposed, defined and delivered at each level where information passes form one non-contiguous interface to the next.

Getting that level of consistency from one tier and each transfer mechanism to another is important if the system is to be protected from being impervious to change. Once the Entity beans get passed around as concrete objects it rapidly becomes a static system that is heavily coupled from front to back.

More Reading on J2ee

• J2EE
• Java
• Software Engineering
• Data Transfer Objects in J2EE Systems
• Data Transfer Objects, Value Objects and Domain Models in J2EE