Chapter 5. Model-driven development solution life cycle
5.4 Model-driven development and artifact management
in an MDD project. These assets may be as simple as text files containing configuration properties and documentation, or as complex as project archives containing executable code and deployment descriptors.
According to Rational Unified Process (RUP), an
artifact
is “a work product of the process: roles use artifacts to perform activities, and produce artifacts in the course of performing activities”. The artifacts that we are considering are all examples of artifacts in the RUP sense. For this chapter, we limit ourselves to software assets that contribute to the solution as part of the model or the executable services.5.4.1 Reuse model artifacts
The success of an MDD project depends on the successful reuse of model artifacts. With this in mind, it is worth analyzing the value and contribution of an artifact to determine whether it should be generated.
For instance, patterns and transformations provide value through reuse, while a configuration script may only be used once but contributes greatly. As such, while reuse is a major factor in determining whether it is worth going through the expense of generating an artifact, there are other considerations based on context and value. Reuse in MDD covers the reuse of patterns, models, transformations and to a lesser extent the code. The management of these artifacts, their related descriptions (probably captured in templates), and the maintenance of the repositories become increasingly important.
The management of artifacts includes, but is not limited to, the following issues:
Successfully identifying and retrieving an artifact for reuse
Ensuring that the appropriate artifact is retrieved for the version of the target runtime
Checking the integrity of an artifact and verifying whether it is this the latest or appropriate version of the artifact
Checking the certification of an artifact, and whether it is certified to run in this environment
Perhaps it is only for test environments or restricted through license conditions, only to run in particular environments.
When determining the methods and tools to use for artifact management, there are a set of factors that must be considered, including integrity management services and deployment support.
5.4.2 Integrity management services
There is a need to determine the reliability of the model and solution artifacts in order to maintain the integrity of the system. As such, we recommend that a mechanism to certify that the service meets standards (set by governance), is adopted. This
Certification of Service
practice should be applied to all artifacts in a graded way. For instance, the artifact may be certified as ready for deployment to the test environment only, or to the production environment, or it may be certified as deprecated and not to be used by new applications.You must analyze the certification practices early because it may influence the choice of repositories to use (for example, a repository may provide features that support some of the requirements).
The early consideration of artifact management helps determine how much, if any, information needs to be added to the generated artifacts to enable their certification, and the subsequent query/retrieval of the required artifacts for a particular context. For instance, in our service-oriented integration (SOI)
scenario, the stored artifacts are tagged with enough information to be searched for reuse by the following items:
Service type (IB, PF): See 2.2.1, “ESB structure” on page 21
Stage (beta, deployment ready, deprecated)
Protocol (SOAP/HTTP, SOAP/JMS, JMS)
Some of this information is captured in the RAS templates that describe the artifacts, and others are derived from the content of the artifact.
5.4.3 Deployment support
We are interested in the ease with which the assets are retrieved and deployed. The structure of the repository must take into consideration the versioning policies and the certification policies, to enable the effective maintenance of the service repository and assets.
The definition of the asset types is also important for supporting deployment (might be easier to deploy a pre-packaged EAR file than an EJB), a set of Java classes, and some data schemas. In most cases, the asset types to be stored are determined by the solution type and the deployment policy. Compare these two cases:
A rapid deploy scenario where deployment may be automated with the newly created and certified services are hot-deployed
In this case, the packaging of artifacts is normally part of the generation step to maximize the effectiveness of the rapid deploy.
A scenario where there could be established packaging scripts and release to production practices.
For this scenario, the repository may hold a simpler type of asset. A packaging application is applied to these artifacts, and the results are subsequently deployed.
The adoption of technologies and methods for artifact and configuration management, to a large extent, depend on the type and size of project and the type and size of artifacts. The certification policy, deployment policy, and so on, not only influence the technology and product to be adopted for artifact
management but also inform the decision to divide the features provided by the tool and those to be built into the artifacts. The handover of artifacts through the stages are to a large extent dependent on these policies and must be analyzed as part of the lifecycle discussions early on.