Sample project architecture... Project approch is different from project architecure. Sorry here i can't insert my own project architecure diagram. Client tier: • ie browser (default) from which the end user will access the application • the request from the browser will be submitted to the application server using http protocol. • the response from the presentation layer (struts framework) will be interpreted into html pages to view on the browsers. • presentation tier: struts framework with tiles • on request from the browser, the appropriate action class handles the user request. The action class then connects to the business tier via service business delegate. • tiles have been used to create a set of pages with a consistent user interface (e.g.: the same navigation bar, header, footer, etc.). • taglibs are used for displaying tabular data (e.g. Search results) in a consistent fashion, with pagination. Business delegate layer • enable the struts action classes to be unaware of underlying session beans • encapsulates the invocation of service locator to locate them. Advantages of struts ‘centralized file-based configuration’, i.e. Rather than hard-coding information into java programs, many struts values are represented in xml or property files. This loose coupling means that many changes can be made without modifying or recompiling java code. Validation of the user entry fields in the jsps to be handled by entries in the validation.xml and defining validation rules in validator-rules.xml. Internationalization of the static components of the screen as field and button labels, titles, error messages etc. This approach also lets java and web developers to focus on their specific tasks (like implementing business logic, presenting certain values to clients.) without needing to know about the overall system layout. Business tier • the business delegate identifies the business service class (the session ejbs) and delegates client request to the ejbs. Internally, the session beans are shallow, and delegate all business logic requests to business logic pojos, which in turn implement the actual functionality. • the business logic pojos encapsulate the server side business logic. They do not use hibernate directly, but instead call upon data access objects (dao) to work with the model. Parameters and return values are modeled as data transfer objects (dto), and hence no hibernate model classes will ever leave the dao layer. The business logic is made available in the business service class, which increases maintainability and easy debugging, if necessary. Hibernate/db tier the daos encapsulates the database access. For all practical purposes, we are using hibernate (v 2.1) as the or mapping layer. This saves development time to write sqls for executing insert and update statements, find by primary key etc. For each value object that directly or compositely represent a table in the database, we have hibernate mapping files. For some complex data retrieval, however we will be using raw sqls (independent of database) from the daos and populate the value object pojos. In those specific cases, the daos will be having direct access to the databases using the available connection. The connection properties of the ‘db manager’, holding the data sources, direct the request to the appropriate database. Issues that may rise of hibernate • hibernate no longer supports dynamic proxies • the hibernate has issues using microsoft's driver especially when using sqlserver2000. It appears that the failures are due to some strange handling of dates. • hibernate has issues with informix databases due to the way jdbc implementation is done in informix.