Dangers of a Domain Model as the Messaging Model

When designing a services layer, we can relate this to an n-tier architecture where the presentation layer exists on a separate server (possibly developed under a different technology). So the services layer will essentially be like the Session Facade down to the integration layer for interactions between databases, file systems, etc. In this design, there is usually a decision as to whether or not the domain models will be exposed out of the business layer, or whether those domain models will be mediated into a different object representation like a DTO (Data Transfer Object). In this discussion, Domain Models represent our persistence representations while the Messaging Model represents our models exposed via a Service Contract.

In the design of the models themselves, the drive is towards creating a Canonical Model as described in XML Standards for Service Modeling. In this specific implementation, the decision was to utilize the Domain Model as the Canonical Model and expose those models via the Service Contract. As different parts of the application architecture evolved, this began to expose itself as being the cause of some issues.

First off, the technology being used in this case is CXF/JAX-WS/Spring/Hibernate/JPA/AOP. The CXF/JAX-WS frameworks/APIs are used for exposing SEIs as web services for invocation. JPA/Hibernate are being used to provide the persistence framework through JPA ORM files and Hibernate as the Provider. Spring is being used to wire together the CXF/JAX-WS endpoints with the business logic and persistence layer, as well as using AOP with JTA to provide transactionality.

One of the first issues to be hit related to the fact that models representing persistence may be over complex for the needs of a UI Framework (which would potentially be more successful with a flattened model). The persistence model however has complex relationships like bidirectional relationships that allow us access to Parent/Child interactions without having to loop through an object model and keep track of them ourselves. The issue this brings to light though is that a bidirectional relationship will many times consist of a Parent with a Collection of Children, where each instance of the Child in the Collection has a reference back to the Parent, which internally has a Collection of Children and on and on and on. So when it comes time for JAXB to marshal the objects into XML to produce the SOAP Response being sent out of the CXF/JAX-WS framework, the process consumes all memory and begins to run out of Memory and the server crashes. This occurs because the recursive nature of a bidirectional relationship and as JAXB walks the object model to persist it, it will start into a recursive loop of serialization as it walks that bidirectional relationship and the callbacks from the Child to the Parent and so on. This issue is discussed in some detail in the following two posts:

JPA Entities to XML – Bidirectional Relationships
JAXB Mapping cyclic references to XML

The Child object will most likely need to have an @XmlTransient annotation on the relationship it has back to the Parent. Therefore when JAXB is marshalling the object model into XML, it will convert the Parent and then Collection of Children, but not the Child’s relationship back to the Parent. The client of the calling service needs to be aware then that the Child does have a Parent (the containing Parent) even though over the wire (with relation to the SOAP message) it appears that the Child does not have a reference back to a Parent. There maybe a need to think through the same sort of concept for the equals/hashCode/compareTo/toString, as to which fields are being used and how much of the object graph is being walked in order to utilize that field.

Another issue is related to what happens within an application with regards to how Hibernate handles relationships. Hibernate helps the initial load and overall performance of an Entity by providing lazy loading features. Hibernate Without a ton of background experience, it was easy to incorrectly configure Hibernate ORM files by trying to make all the Collections eagerly fetched. But when the WAR is deployed and Spring begins to bootstrap the loading of the persistence.xml and orm.xml files, we receive an error related to (Caused by: org.hibernate.HibernateException: cannot simultaneously fetch multiple bags).

Hibernate and Multiple Bags
Hibernate Exception – Simultaneously Fetch Multiple Bags

So we have to correctly label Collections as LAZY, by default they are supposed to be. This seems to fix our issue with the Multiple Bag Exception. The problem is that now our Collections that are not EAGER hold a reference to Hibernate’s PersistentBag (used as a proxy for the lazy loading of the relationship) and the One-to-one Objects that are not EAGER hold a Hibernate Proxy (used as a proxy for the lazy loading of the relationship). This becomes an issue in web applications related to whether or not the session is open so that when those proxies get touched, they can retrieve the subsequent relationship. Otherwise we will receive the Hibernate LazyInitializationException. There are quite a few articles on how to resolve this issue:

Hibernate – Lazy Load exception – no session or session was closed
How to solve lazy initialization exception using JPA and Hibernate as provider (with newer ways to solve it).

Even though we are not running in a complete MVC web application, we have the same situation occurring because the models we are exposing through the web service are Domain Models tied to a Hibernate Sessions (because of the EntityManager and ORM files). So like a typical SessionFacade, the service that is exposed as a web service has AOP Pointcuts to add JTA Transactionality. What occurs is that when that WAR receives a web service request, JAX-WS/JAXB/CXF do their work and then hand off the Object to the appropriate SIB (Service Implementation Bean) which has an AOP Pointcut tied to it, so a JTA transaction has been started. All data access that is done within that transaction ties the Hibernate Session (EntityManager) to that transaction, because of:

<entry key="hibernate.current_session_context_class" value="jta"/>

Therefore when all the logic is complete and the service method returns the Object to the calling framework (essentially the business logic is done and now the JAX-WS/JAXB/CXF will take over), the AOP Pointcut is complete and closes the Transaction (and therefore the Hibernate Session). So when the JAXB part of the process marshals the Object into XML and walks the object graph, it will run into the Hibernate Proxies and PersistentBag instances, with no Hibernate Session from which to retrieve the relationship. Therefore the LazyInitializationException occurs.

In some of these examples they talk about the OpenEntityManagerInViewFilter or called the Open Session in View pattern. This is one of the typical ways to solve this issue from within a web application.

This can be done by making the following modifications (as an example)

<entry key="hibernate.current_session_context_class" value="jta"/>

is changed to

<entry key="hibernate.current_session_context_class" value="org.springframework.orm.hibernate3.SpringSessionContext" />

And add the following to the web.xml


This actually can work for us. Another way to do it is to create a CXF Interceptor to start the transaction at a certain point in the Phases of unmarshalling data when the request is received, or closing the transaction when the marshalling process has completed. Since we hadn’t tried the Open Session in View pattern, the resolution that occurred was creating a touch method that would utilize a ReflectionUtils.doWithFields functionality to walk the whole object graph and touch any Hibernate Proxies that were not EAGERLY loaded. This would essentially force selects to occur immediately when the object was retrieved from the database (by adding a step in the framework to perform a touch of an object before it was returned to the calling method).

Another approach was to use the concept in service design where we could use a single fine grained method to produce multiple types of responses based on the data the user wanted. So for instance, if we had a method that was getPerson and retrieved a Person, their family, their addresses, etc, we could change the amount of data returned from that one getPerson method by supply a list of Filters/Scopes for limiting data. This would allow a user to call getPerson with a List of Filter fields like address and family, so that when the getPerson retrieved a Person object, it did not also retrieve the Person’s Address and Family (would be additional select statements to other tables). Therefore, the we could take the fact that Hibernate will not allow more than one Collection to be EAGER as an advantage because time was not wasted pulling in additional resources the user might not want. The Person object would be retrieved and have its Hibernate Proxies (for doing lazy loading of the Collections) and if the List of Filters was populated, the code could determine if one of the Filtered fields was a Hibernate Proxy, then that reference could be set to null (dereferencing that Hibernate Proxy). Therefore when the object was marshaled via JAXB, it would not throw a LazyInitializationException on that field because the reference was null and we did not need that data returned to the user.

This approach actually seemed to produce less selects than by using the Open Session in View pattern. This simplified the architecture by leaving the AOP and JTA Pointcuts as they were originally developed.

Share and Enjoy

XML Standards for Service Modeling

When designing web services, it becomes apparent that it is necessary to lock in standards for designing the service contracts as well as the service models. In an effort to standup the initial phase of the SOA Enterprise, many services begin to expose themselves on the ESB that either are driven by a legacy system (such as a mainframe generated service) or by developer building the models in isolation. Since the goal is to drive towards a common Canonical Model, it is important to define a set of standards around how Schemas are designed and rules that need to be followed when creating them.

If we do a little googling, you might land on the Oasis XML Coverpages website, which is a great resource for XML based standards groups. The XML Coverpages site has a landing page for Naming and Design Rules. One of the resources made available in the table listing of this page is the “UN/CEFACT XML Naming and Design Rules”, which has two great resources.

UN/CEFACT 8 XML Naming and Design Rules Technical Specification 9 Version 3.0
UN/CEFACT/UBL XML Naming and Design Rules Analysis

The “UN/CEFACT/UBL XML Naming and Design Rules Analysis” is a spreadsheet that can be downloaded in DOC format. It refers to another document called Universal Business Language (UBL)
Naming and Design Rules
. These documents provide some very detailed discussions around the standard uses of XML Schemas and the implementation of the XML Schema to create Models. This might be as detailed as to the types of names of elements, what attributes are expected, and whether or not features in the XML Schema Specification can be used at all (like xs:all).

Another one of the interesting examples is the Department of the Navy
XML Naming and Design Rules
because of the great detail an explanation of all the different types of rules and usage standards.

In reading these documents, it becomes quite apparent how difficult it can be to produce the ideal environment for Service Modeling, let alone the complexities/capabilities in utilizing the XML Schema Specification. These concepts are very important in a SOA that pushes a Contract-First methodology, where the WSDLs and Schemas will be designed and developed first. One of the books for Java web service development talks about a bridged approach between the Contract-First and Code-First called Code-First/Contract-Aware.

Here is the book

This is really about taking advantage of the great annotation support in JAX-WS and JAXB to replicate the standards for Service Modeling within the annotations themselves. While you have more power in developing the XML Schemas directly, the simplicity that is provided through the JAXB annotations cannot be understated. Even with the power of JAXB annotations, standards will be necessary for the names/features that are used with the framework, along with defining how to implement complex JAXB representations such as Maps/Enums/Collections.

For some businesses, these documents and their detail maybe overkill, but there is probably some value at least in having some generalized rules for XML naming and design (such as not having verbs in the Schema names except for the introduction of operations within the WSDL, or the names of elements and what detail they are, etc). Having a set of some core rules and definitions will ease the integration of development teams into the enterprise SOA.

Share and Enjoy

Service Layer and Model Design

When designing services, it is important to create categories that the different types of service requirements fall into. This allows us to establish standards, best practices, and reference implementations for those types of services. Also, we can better understand the problem domain by understanding the service requirement and then being able to apply a solution for all services within that service layer.

Two of the better books for service layers and models are:

These books refer to concepts (such as Thomas Erl talks about at http://serviceorientation.com), three types of service layers called task service layer, entity service layer, utility service layer. You can find an explanation for these at the following site:

ServiceOrientation.com – Service Layers

We can see a similar concept when reading the Oracle SOA Reference Architecture, the following diagram is a representation of that from a technical article. It classifies different service layers and the types of services that exist.

A Guide to Ensuring the Success of Your SOA Governance

There is also a similar reference or description within the Oracle AIA (Application Integration Architecture) documentation:

Understanding the Oracle AIA Reference Architecture

The interesting thing about reading through the materials, is that the concept of designing services or web services is no different from designing proper APIs. The issue is that as teams are new to the concept of designing services, the concept seems foreign and therefore is treated totally different from API design (which is probably a reflection of sloppy API design). So taking these suggested categories, and the concepts for strategies that are used for Java Application development we can define some generic service types.

The following are the types and these services are based on a functional role, some standards that help drive how they are developed, what dependencies they have, and what standards are applied to them.

  1. Access Service
  2. Utility Service
  3. Data Service
  4. Search Service
  5. Messaging Service
  6. Subscribe Service
  7. Business Service

This blog is a work in progress and I will continue to update with additional information.

Share and Enjoy