Application Architecture

Possible layers:

• ui
• services
• dao
• domain

Artifacts

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

artifact name	responsibility
geonetwork-domain-ebrim	Represents the domain model of the ebrim function.
geonetwork-persistence-ebrim	Provides the persistence layer for the ebrim function. The persistence layer consists of a set of Dao's.  A Dao can be used to do CRUD operations on domain objects towards the DB.
geonetwork-services-ebrim	Provides the service layer for the function. On this level everything is a official transaction. Every service call will probably use one or more Dao's This layer can also be exposed to any other technical protocol like Webservices, JMS, SMTP and so on. Fits well in a SOA architecture. Currently this layer will be exposed as webserives in the layer below, geonetwork-web-ebrim.
geonetwork-web-ebrim	Provides the application layer of the application. The application layer interacts with the users of the web application. 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.

Considerations

• We 'decided' not to tie the service and the dao layer. Are we going to make a geonetwork-services-ebrim as a seperate artifact (jar) or will it just a package within the geonetwork-web-ebrim artifact (war)?

• 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 ? erik: Question is this: will the ebrim application part of a default GN installation? I do not know much about the current installer. I suppose that a new installer can take the artifacts from the maven repo and then builds an installer which is capable of installing java, jetty with the application.