Session Facade and Data Transfer Object

Question

Multiple fine-grained invocations of Entity Beans add the overhead of network calls, even multiple transaction. In other words, the risk is to have a solution that has a high network overhead, high coupling, poor re-usability and maintainability. We use session facade to encapsulate business-tier components and expose a coarse-grained service to remote clients.
We use Data Transfer Object reduce the number of calls, and that means that you need to transfer more data with each call.
I am wondering on my little knowledge that what makes these two patterns so different. One would be serialization in DTO, but what others?

Answer 1

Although they work well together, these patterns are completely different.

Your description about session facade is good enough:

We use session facade to encapsulate business-tier components and expose a coarse-grained service to remote clients.

However the one about DTO doesn't reflects the pattern motivation and it is probably the source of your doubt.

The DTO pattern is pretty simple. If you have exposed a coarse-grained service (following the idea expresed in the Session facade pattern) it will probably need several input parameteres and it will probably produce a output relatively complex. In order to deal with this client-service data transfering, you can create a serialized object (called in this case DTO) that represent the parameters needed for your service. The same idea applies to the service output, all this information will be encapsulated in a simple java object.

//class that represents the service
public MyCoarseGrainedServiceClass{
public MyServiceOutDTO myCoarseGrainedService(MyServiceInDTO params) {
    MyServiceOutDTO outout;
            //your code goes here
    return output;
}
}

public MyServiceInDTO {
    //a list o different parameters of any type
    private int firstParam;
    private String secondParam;
    .
    .
    .
    //getters and setters
}

public MyServiceOutDTO {
    //this object represents the service output
    private int fistrOutputValue;
    ...
    //getters ans setters
}

Notice that you could have a coarse-grained service that doesn't use any DTO but, a DTO object by itself doesn't implements a coarse-grained service.