If it’s likely that a business service might be asked to send or receive all or most of its data in a big, coarse-grained message, it’s common for that service to provide that feature in its API. Commonly, the business service creates a serializable Java object that contains lots of instance variables. Sun calls this object a Transfer Object. Outside of Sun there is a pattern called Data Transfer Object. Guess what? They’re the same thing. (Yeah, we feel the same way about that.)
The client’s perspective, inside the Business Delegate:
That’s it. Under the covers, the Transfer Object is serialized, shipped, and deserialized on to the client’s local JVM heap. At that point, it is just like any other local bean.
The data in a Transfer Object grows stale!
Once it’s shipped across the network, the Transfer Object is completely out of touch with its source, and begins to fall out of sync with the state of the data in the underlying database. You’ll have to decide for each use case whether data integrity/synchronization is worth the performance hits.
Listen in as our two black-belts debate which pattern is better—Service Locator or Business Delegate.
Service Locator is the superior pattern. First ...