aspose file tools*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes question on j2ee design pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "question on j2ee design pattern" Watch "question on j2ee design pattern" New topic
Author

question on j2ee design pattern

Minu Jain
Ranch Hand

Joined: Mar 24, 2008
Posts: 74
which one of the two is a characteristic of the Transfer Object design pattern?
a. It increases the complexity of the design due to remote synchronization and version control issues.
b. It increases network performance introducing multiple fine-grained remote requests which return very small amounts of data.

The correct answer is (a) but i think it should be (b).


SCBCD5, SCWCD5, SCJP5
"Even if you're on the right track, you'll get run over if you just sit there."
Vishal Chugh
Ranch Hand

Joined: Oct 27, 2007
Posts: 177
Yes , it should be B
Christian Nicoll
Ranch Hand

Joined: Mar 09, 2008
Posts: 106
Hi,

strange question... I've problems in finding any correct answer, because I don't think that one of the two choices describe a characteristic of the Transfer Object design pattern.

a. It increases the complexity of the design due to remote synchronization and version control issues.

I think one characteristic of this pattern is that the transfer object will be stale and so no remote synchronization is intended. Not to mention about version control issues...

b. It increases network performance introducing multiple fine-grained remote requests which return very small amounts of data.

I agree that this pattern is designed to increases the network performance, but i think that the "how" is wrong. The transfer object doesn't use fine-grained remote requests which return very small amounts of data, because this would produce all lot of communication overhead. The transfer object reduces the network traffic (increase the performance) by reducing the number of remote requests. I think each remote request should give back a bundle of data (objects) and not very small amounts of data.


SCJP 5, SCJD 5, SCWCD 5, SCBCD 5, SCJDWS 5
My SCBCD-Notes - My Hello World Webservice
Bosun Bello
Ranch Hand

Joined: Nov 06, 2000
Posts: 1510
Yes. A tansfer object increases network performance because instead of several remote calls that return small amounts of data, it will return large amount of data with less calls. Of course, one of the side effects is the possibility of stale data.


Bosun (SCJP, SCWCD)
So much trouble in the world -- Bob Marley
Salim Khatib
Greenhorn

Joined: Jan 06, 2009
Posts: 23
Yes. A tansfer object increases network performance because the remote object(eg entity bean) on the server will be sent over network to the cleint end , and then the calls are performed on this new trasfered local object (entity bean) , as the calls are local it will definetly increases the network performance. But sure there is a trade off between the network perform and updated data. You have to choose what is important for you

SCJP 1.4 - 75%
SCWCD 1.5 - 97%
SQL Oracle 9i - 94%
IBM AIX - 93%
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

a. It increases the complexity of the design due to remote synchronization and version control issues.
b. It increases network performance introducing multiple fine-grained remote requests which return very small amounts of data.

A few points:
"It increases the complexity of the design"
This is generally true of all design patterns. This is part of the trade-off you need to consider before choosing any design pattern in your architecture. Don't blindly use a pattern naively thinking it is a best practice for all scenarios. Your application may not have (nor will ever have) a problem that a particular design pattern is meant to solve. It does not make sense to complicate your architecture to solve a problem you don't have.

"remote synchronization and version control issues"
This assumes a remote invocation to the business tier. In other words, your business tier and presentation tier are completely different Java projects. If these two separate projects send Transfer Objects to one another, the Transfer Objects will get serialized/deserialized over the wire. If your code for a Transfer Object changes (let's say a property name changed or a new property was added), you absolutely have to make sure that both of your projects get the new Transfer Object code, otherwise deserialization will fail. This drawback of the TO pattern has likely contributed to the popularity of SOA architectures that pass around XML based data, rather than serialized Java Transfer Objects.

"it increases network performance introducing multiple fine-grained remote requests which return very small amounts of data"
The TO pattern increases network performance but does so doing the opposite of what this statement says. Think of the TO pattern like a bus or a train that can transport many people together - it makes less traffic congestion than if all those people drove cars. Same with data, if many values travelling the network ride together on a TO, less traffic clogs up the network.

Some of what I've said has repeated others on this thread, but I thought I'd give it from my perspective in case it helps anyone.


A good workman is known by his tools.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: question on j2ee design pattern