Incremental/Layered SOA deployments

In a large project composed by multiple modules developed by different teams, in general a single SDM model wouldn't be manageable. A way to produce multiple SDM models is needed, one for each layer or for each business application, containing only pertinent resources. This section fo the documentation shows how to use Maven dependencies and the maven-sonicesb-plugin to produce multiple SDM projects mapping different layers and applications of a SOA stack.

Maven dependencies

Maven defines different kinds of dependencies (dependency scope in Maven terminology):

Dependency scope Meaning
compile (default) Compile dependencies are available in all classpaths (compile, test and runtime classpaths). Furthermore, those dependencies are propagated to dependent projects.
provided This is much like compile, but indicates you expect the JDK or a container to provide it at runtime. It is only available on the compilation and test classpath, and is not transitive.
runtime This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
test This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
system This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.

These scopes are thought with Java in mind, but the semantic can be generalized to other domains. In the following discussion we will only consider compile and provided scopes. compile means that in order to build a project P it needs a supplier projects S and the result will contain both P's and S's stuffs. If the S projects needs in turn another project T to compile (with a dependency with scope compile), also stuffs from T will be contained in the P result. Compiling ESB projects, this means that the resulting SDM model will contains definition from P, S and T. provided means that in order to build a project P it need a supplier project S, but the result will contains only the P's stuffs. P result will not contains stuffs from S and S's suppliers. Compiling ESB projects, this means that the resulting SDM model will contains only definitions and xar files from P not from S and S's suppliers. In a Dependency graph (a graph showing dependencies between projects) in general there are both compile and provided dependencies. Following pom file snippets shows how to define a dependencies with compile and provided scopes. Following is a compile dependency (compile is the defauly scope, note that the scope tag is missing): 

<pom>
   ...
   <dependencies>
     ...
     <dependency>
       <groupId>com.progress.training</groupId>
       <artifactId>instances12</artifactId>
       <version>1.0-SNAPSHOT</version>
       <type>zip</type>
     </dependency>
     ...
   <dependencies>
   ...
</pom>

Following is a compile dependency (explicitly specified with the scope tag): 

<pom>
   ...
   <dependencies>
     ...
     <dependency>
       <groupId>com.progress.training</groupId>
       <artifactId>instances12</artifactId>
       <version>1.0-SNAPSHOT</version>
       <type>zip</type>
       <scope>compile</scope>
     </dependency>
     ...
   <dependencies>
   ...
</pom>

Following is a provided dependency (note the scope tag): 

<pom>
   ...
   <dependencies>
     ...
     <dependency>
       <groupId>com.progress.training</groupId>
       <artifactId>instances12</artifactId>
       <version>1.0-SNAPSHOT</version>
       <type>zip</type>
       <scope>provided</scope>
     </dependency>
     ...
   <dependencies>
   ... 
</pom>

Mapping the SDM with the SOA stack

All compile dependencies

Figure "SDM mapped to the SOA - 1" shows how the training project used in the Expert Path Program maps to the SOA stack (here we use a maturity level of a SOA, that is not exactly a functional stack of a SOA, however it is still meaningful for the example):

To better explain concepts, the figure shows two kinds of mapping:

  • Logical mapping

    This mapping is what the developer/designer has in its mind: the projects maps to different layers of the SOA.

  • Pysical mapping

    This is the result of the build of the SDM project (app12): the SDM model will contains all produced artifacts from all supplier projects. The resulting SDM model maps all layers of the SOA. This physical mapping is obtained defining all dependencies with compile scope.

Using provided dependencies

In a large project it would be desirable to have a physical mapping for each layer, and, moreover, for the last layer, the business layer, a SDM model for each business application in order to have a different life cycle for each business application. Using provided dependencies it is possible to define cut points in the dependency graph and limit the contents of the generated SDM model. Now in order to define all the SOA stack a single SDM model is not enough and a model for each layer is needed. These concepts are shown by the figure "SDM mapped to the SOA - 2".

Note the dependencies between process12 and resubmit-process12 projects and resubmit-process12 and instances12 projects: they are provided dependencies. In such way the app12 projects will contain only the business process and its on-ramp process, not stuffs already contained in lower layers. Now in order to define lower levels we need more SDM projects (baseline12 and architected-svcs12 projects). Note the dependencies: baseline12 will produce a SDM model containing all libraries, service types, instances from projects SonicServicebase, TextService12 and instances12. architected-svcs12 will produce a SDM model containing only artifacts from resubmit-process12 project. Figure "SDM mapped to the SOA - 3" shows how the higher level (the business level) can be defined by multiple SDM models: one for business application. In this way it is possible to have different life cycles for the different business applications.