Application Architecture

Possible layers:

• ui
• services
• dao
• domain

Artifacts

In SVN I have now created artifacts for the ebxml function. The following naming convention is used: [software name] - [architecture level name] - [function name]

artifact name	responsibililty
geonetwork-domain-ebxml	Represents the domain model of the ebxml function.
geonetwork-dao-ebxml	Provides the dao layer for the function. A Dao can be used to do CRUD operations on domain objects towards the DB.
geonetwork-services-ebxml *)	Provides the service layer for the function. On this level everything is a offical transaction. This layer can also be exposed to any other technical protocol like Webservices, JMS, SMTP and so on. Fits well in a SOA architecture. Every service call will probably use one or more Dao's and will use heavily the domain.
geonetwork-web-ebxml	Provides the application layer of the application. The application layer interacts with the users of the webapplication. A user can be a browser or a machine. It parses the http request into a service call. The service call goes to the service layer.

*) not implemented yet. 

Considerations

• We could combine services and dao into one artifact named geonetwork-services-ebxml.

heikki: -1. The dao layer will be used by the domain layer, and although the services layer uses the domain layer, I'd prefer not to tie them in the opposite direction as well.

• We could call the dao artifact persistence.

heikki: hmm. I'm in favor of a layer called 'persistence' and it should sync both the database and the Lucene index. It's not yet clear to me how this relates to the existing codebase, that uses the same database and Lucene index.

• In my other project people are complaining about having more artifacts instead of one for the application. Indeed you need a powerful computer and IDE. Personally I think that the advantages of more artifacts are greater than the disadvantages. For instance Hudson works on artifact level.

heikki: +1. For example our domain layer should be a library (JAR) that can be plugged in to any other application, with no dependencies in the code on our other layers. We may produce an application artifact in the form of a WAR or EAR as well though, for ease of installation and distribution. What are we going to do about the current way of creating an "installer" rather than a WAR or EAR ?