= 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]
{{{
#!html
<table style="text-align: left; width: 100%;" border="1"
 cellpadding="2" cellspacing="2">
  <tbody>
    <tr>
      <td style="height: 26px; font-weight: bold; width: 190px;">artifact
name</td>
      <td style="height: 26px; font-weight: bold; width: 777px;">responsibililty</td>
    </tr>
    <tr>
      <td style="height: 33px; width: 190px;">
geonetwork-domain-ebrim
      </td>
      <td style="height: 33px; width: 777px;">Represents
the domain model of the ebrim function.</td>
    </tr>
    <tr>
      <td style="height: 31px; width: 190px;">geonetwork-persistence-ebrim</td>
      <td style="height: 31px; width: 777px;">Provides the
dao layer for the function. A Dao can be used to do CRUD operations on
domain objects towards the DB.&nbsp;</td>
    </tr>
    <tr>
      <td style="width: 190px;">geonetwork-services-ebrim <span
 style="font-weight: bold;">*)</span><br>
      <span style="font-weight: bold;"></span></td>
      <td style="width: 777px;">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.&nbsp;</td>
    </tr>
    <tr>
      <td style="height: 40px; width: 190px;">geonetwork-web-ebrim</td>
      <td style="height: 40px; width: 777px;">Provides the
application layer of the application. <br>
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.&nbsp;</td>
    </tr>
  </tbody>
</table>
<span style="font-weight: bold;">*) not implemented
yet.&nbsp;</span><br>
<br>
}}}

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.