= 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] {{{ #!html
aritifact 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. * We could call the dao artifact persistence. * In my other project people are complaining about having more artifacts instead of one for the application. Indeed you need a powerfull computer and IDE. Personally I think that the advantages of more artifacts are greater than the disadvantages. For instance Hudson works on artifact level.