Same interface for all tiers

I am working on a system with one master and multiple clients that communicate using JMS.

The server is a three tier application written in Java. In the server's data access layer, I am sending out JMS messages with tasks on one queue and I am receiving task status messages from the clients on another JMS queue. From those status messages I basically only extract Strings.

I have chosen a three tier architecture because I also need to access databases and do other business related computations before I can send a task to the clients.

I want the Strings of the status messages to be handed through all layers to the GUI where they are displayed.

I had the idead to use the same interface for all layer classes where the Strings go through, to enforce that they all have the same methods for receiving the data.

The alternative would be having separate interfaces for the layer classes, but those would then be 开发者_StackOverflow社区essentially the same, except having a different class name.

Which alternative would be the proper way to ensure clean communication between the layers?

---

I presume what you call "strings going through layers" are some sort of human-readable, meaningful messages, if it makes sense to you to display it in the GUI.

Making a simple value object around these strings is what I would certainly recommend, i.e.

public interface StatusMessage {
    String getContent();
    void setContent(String content);
    // ...
}

public class StatusMessageImpl implements StatusMessage { ... }

instead of passing raw strings around. Raw strings would mean each layer having to know how to handle them, if ever needed; a value object hides the complexity. Such value objects can live in all layers, in a similar way JPA entities can.

If you need to, you can manage the lifecycle of StatusMessage by deciding it can be created only by the DA layer our of your JMS message and making it immutable, so that you're sure it travels unchanged through the layers. You can also divide functions related to the StatusMessage among the layers:

• DAL knows how to create StatusMessage from JMS, or how to pack it back,
• BL has routines (business objects?) working on StatusMessage,
• GUI groups formatting and displaying functions.

Hope I interpreted your intentions correctly.

---

I am assuming that this is a psuedo-synchronous response (You have somehow co-related request/response from different queues OR used some polling mechanism on response queue to tie things together). Otherwise I don't understand how response can flow backwards from a JMS queue to the UI layer.

To your actual question, if list of possible status messages (Strings) is known upfront, why don't you convert String message recieved from queue to a Status enumeration. This could be passed as response to the other layers (may be wrapped within a Value Object). This would give you better control on what you wish to show on UI as well as help you manage related business logic better (e.g. say you want to provide different business treatment based on Status recieved).

---

One should always program keeping in mind changes down the line. If you keep one interface for all three layers, what happens if one or the two of the layer needs to change for some reason. You end up changing classes at all three layers. Imagine what happens if you impose a limit on number of characters to be displayed on the UI? or change encoding on the UI?

Minimizing change and its impact is the ultimate goal of all designs.

---

The scenario you explained is insufficient to decide about the interface design of your project. The indiscriminate use of repetitive interfaces, with little or no behavior in classes that implement them, is not good design.

Is there really a need for a strict separation of layers?

You want to have different GUIs accessing your business layer?

The operations are all read-only?

How big is your system?

Finally, "clean communication" is very vague to make critical architectural decisions. When in doubt keep the solution as simple as possible and refactor if necessary.

---

Not quite understood what your problem is because of a lack of information on it, but just in case if it helps, look for java.lang.reflect.Proxy.getProxyClass().

Why it is decided to break application onto 3 tiers, which will just route calls upside and down the tier hierrachy? If your goal is to separate view from jms source, I think it would be better to create a factory of JMS implementations, whose interfaces will be used in view tier. I don't see any reason for adding business layer in the situation you described.