Before anyone gets too excited, let me explain.
Savara 1 recently introduced the concept of the Testable Architecture Project (TAP). This is an XML representation of (as the name suggests) a testable architecture project, defining the different artifacts associated with the stages of the software development lifecycle, and the dependencies between them.
Savara 1 has been primarily focused on the Eclipse environment, and therefore a mechanism was needed to define the artifact dependencies, so that the static validation between various artifacts could be triggered when a change occurred.
However we always had an eye on the future, and that Savara 1 should ideally be working with an SOA repository, and that Savara 2 would be more web centric than Eclipse based. So the problem the TAP was attempting to address was to enable dependencies to be represented when no repository was available.
The problem it introduced was how the dependencies in the TAP would be synchronized with the dependencies that may be defined when those artifacts were also stored in a repository. This was one of the main objections raised to the use of the TAP on the Savara forums, but at the time it was difficult to see how dependency information could be managed without being fully dependent upon the artifacts being stored in the repository - i.e. static validation would only occur when changes were made and committed back to the repository.
However now there may be light at the end of the tunnel. There have been discussions about the creation of a general purpose repository project, with profiles suitable for specific domains (e.g. rules and SOA). There is potential for the Savara project to feed in its requirements, and help contribute to this repository project, to find a solution that would work with and without a repository being available (i.e. online).
Watch this space ........
Friday, 11 February 2011
Subscribe to:
Posts (Atom)