Design guidelines/patterns/ideas for multiple J2EE client types


General J2EE: Design guidelines/patterns/ideas for multiple J2EE client types

  1. I am trying to gather as much information relating to the design aspects concerning the development of multiple client types in a J2EE environment. These clients may include Swing, Browser and integration (eg using Web Services) clients.

    I am familiar with the different considerations given to the Business Delegate (Sun), Session Facade (Sun), Service Layer (Fowler) and Remote Facade (Fowler) all located in the Business Tier to provide a uniform access point for all types of clients - local and remote.

    I have also read much regarding the different J2EE patterns relating to Presentation Tier, however most examples seem to be focused on pure HTML clients and give little or no context to alternative types of clients. A review of the Struts architecture has given me a solid understanding of the values of these patterns applied to HTML clients.

    It is still however not clear to me how one should address the design of a presentation tier which supports a variety of client types. I imagine that there will be common code shared amongst the different graphical presentation "gateways", however an integration "gateway" may offer an entirely independent implementation again.

    Perhaps functionality that is supported by a Swing client is different to that of an HTML client, therefore the presentation models may be different. Each "gateway" will finally have it's own method of communication with the client (eg HTTP, JMS, Socket) and therefore will have some protocol dependent model representation.

    I would appreciate if someone could point me towards some patterns, discussions or examples of how such a presentation tier can be modeled.
  2. Using MVC would certainly help.

    Struts for HTML and WML in the presentation tier would work.

    All Swing components are desinged using MVC also.

    You can even apply MVC with web services. Have a look at

    The design of your model classes is important so you can use them for all the clients.

    Hope this helps.