Introduction to Composite Applications
- Former user (Deleted)
A Composite Application (C-App) is a collection of artifacts deployable on a WSO2 product instance. C-App files have CAR extensions and can be deployed to different runtimes. Each runtime will only deploy the artifacts which match with the role that the runtime is playing (e.g., ESB runtime will not deploy a data service in the CAR file, unless the default configuration is altered). These artifacts are usually JAVA-based or XML configurations, designed differently for each product in the WSO2 Carbon platform. You can deploy these artifacts to generate services.
A single WSO2 product can have numerous artifacts such as Axis2 services, dataservices, synapse configurations, endpoints, proxy services, mediators, registry resources, BPEL workflows etc. Usually, these artifacts are created in a development environment and then moved one by one into staging/production environments. Manually configuring artifacts to build up the entire solution this way is a time-consuming task. Instead, you can bundle configuration files and artifacts in a C-App and port Web service based solutions across environments more easily. C-Apps allow you to export your entire solution as a single archive file.
A single C-App can consist of artifacts that are deployable in various different products. Therefore, when you deploy a C-App in a particular WSO2 product, all its artifacts might not be deployed in that particular product instance. To sort out which can be deployed in which, the ServerRole property is used.
Structure of a C-App
The structure of a typical C-App, contains individual directories of the artifacts and a file named artifacts.xml, which contains the metadata about the artifact content listed inside the C-App. The following code illustrates a sample artifacts.xml file which provides in-depth details about the sample C-App and its content. This file contains the name of the C-App (in this case sampleCApp ), its version and the type of the artifact. The relevant deployer for the artifact is identified using the artifact type; for C-Apps this is "carbon/application". In addition, the artifacts.xml file also contains details about its content artifacts such as its name, version and server role of the artifact. The server role will be considered to recognize whether the given artifact is relevant to that running server. If the serverRole is matched with the WSO2 product that the C-App was deployed for, then those artifacts will be deployed using the CappDeployer ; however, if the serverRole is not matched the artifact will be ignored.
Sample artifacts.xml file
The relevant deployable artifact (e.g., if its an Axis2 service the file extension used is .aar and if it is a webapp the file extension used is .war) and other relevant files needed for that specific artifact are found inside the artifact directory. This also contains an XML file named artifact.xml that contains the meta-data information about that artifact. This contains the artifact name, version, type of the artifact, server role and the name of the artifact file. For example if its an Axis2 service the type will be “service/axis2” and for webapps the type will either be “web/application” or “webapp/jaxws” based on the type of the webapp.
Sample artifact.xml files
