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 'decided' not to tie the service and the dao layer. Are we going to make a geonetwork-services-ebxml as a seperate artifact (jar) or will it just a package within the geonetwork-web-ebxml 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 ebxml 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.