Designing Messages for Service Layer

i am about to develop a small application that should consist of a server and a rich client. so far i will follow the following design guidelines:

• never expose domain objects to the client
• encapsulating service messages to response and request objects
• identify service routines based on use-cases, so that they are always atomic

my real problem (language independent) is that i have no idea what decision to make regarding message design (response and request objects).

should they be based on reusable parts (e.g. data objects like CustomerDTO or CustomerData) or should each message be individual; maybe using nested classes for details and embedded items).

i know that not each use-case will require or even allow all attributes of involved entities to be shown or changed, so that leads to a design where several messages should be an enclosed set of classes.

what would you suggest?

best regards,

agent_harris

EDIT:

to give a more detailed example.

let's say we have the following interface:

interface CustomerService {

    /**
     * this use-case should return all necessary data to
     * edit a customer record, including the associated 
     * invoice/delivery addresses
     */

    CustomerRecordResponse getUserRecord(int userId);

}

now the question is how to compose the CustomerRecordResponse that way, that its components are reusable but without revealing too much information for other use-cases that may not allow to access or change specific properties.

one of my thoughts was to introduce small classes that could be extended if necessary. for example:

class CustomerData {

    private String firstName;
    private String lastName;

    // ...
}

which is basically only a set of attributes (a flat object). now when it comes to edit atomically a complete record including addresses an option could be to extend the CustomerData class (maybe locally as nested class) to:

class CustomerRecordResponse {
    // nested class:
    class ExtendedCustomerData extends CustomerData {
        开发者_开发知识库private AddressCountryData[] addresses;
    }
}

here i would see the advantage that i can reuse the base-type components to feed an already existing UI widget which is maybe part of an UI composition.

otherwise when designing completely separate flat message objects all data would be divergent and a lot of overhead would be necessary - on both sides.

my goal however is to design a client/server app which is in phase 1 definitely implemented in homogeneous technology (.NET Remoting or Java RMI) but with the possibility to easily enable SOAP support.

Define two interfaces: Client and Server, so that the protocol and the medium of communication can vary (this is useful for example to unit test the communication just with an in-memory buffer). The client interface can be very simple ( on_message( MESSAGE_ID , NUM_OPS, OPS) );

For each message you can create or generate (see Google's protocoll buffers) a class. Then create a MAP from Message_ID to the Message Object. The message object will validate the message and execute the relative action.