CONCLUSIÓN TRAS LA PRÁCTICA DE DILIGENCIAS.

One task of the package deployer is to modify the files of an application package. Fore- most two files have to be modified: composite and contribution descriptor files. The schema for both of them is described in the SCA specification.

If one possesses the schema of an XML file, it is unhandy to modify the file without utilizing the schema. In the following, three possible ways to modify the files are con- sidered.

JAXP using DOM JAXP (Java API for XML Processing) provides several methods to work with a XML file. A possibility to parse a XML file is provided by the DOM (Document Object Model) interface of JAXP. By the use of this method a complete in memory representation of the document is created. This representation has the form of a DOM-Tree. Its nodes represent the elements and attributes of a XML document. The tree can be traversed and its nodes can be modified. Certainly the DOM representation can be saved back to a XML file.

This method works without the utilization of the schema file. Therefore, it is difficult to obtain dependencies between different elements. For example, when a component name is changed, all appearances of this name in target attributes of references have to be changed as well. To achieve this, complex functions would be necessary. Furthermore changes which may destroy the structure of the document are possible.

Model of the SCA Editor The creators of the SCA Editor which is customized for this diploma thesis have established an EMF model (see 5.2.2.1) of a SCA composite. For being able to modify composite files, awriter is created. It allows to write an EMF representation of a composite to a XML file. For the editor, the model was extended by the pattern attribute. So it could also be used to handle this extension, too.

With this approach it is easy to modify a SCA element. Modifications are forwarded to other elements automatically.

Unfortunately the writer sometimes creates composite files which cannot be used with tuscany. For example the implementation element of some implementation types appears as the last element within the component description. This is not allowed in tuscany and therefore, leads to an error. It could not be assured, that these problems can be solved in this thesis. So the EMF model is not used for the implementation of the package deployer.

Tuscany Assembly Model Tuscany also provides a method to read and write composite files. Therefore, it provides so called processors for all kinds of SCA files. For the implementation of the package deployer the processors for composite and contribution

5 Prototype

descriptor files are used. The composite processor for example, is using a XML stream to create objects and therefore, a data binding for a SCA composite. Like for the EMF approach, changes are forwarded to other elements.

Tuscany uses this way to handle SCA files. So it is most likely that files which were modified like this will work with the tuscany runtime. The only part that is not handled by this approach, is the pattern attribute of the extended SCA components. Here JAXP can be used in addition.

All functions which are required are assembled in one single library file of the tuscany distribution. This file resides in the libs folder and is named tuscany-sca-all.lib.

5.3.3.3. Modifications File

As stated in the requirements, the package deployer must be able to apply amodifications file. It is provided by the customization process. The file contains names of the artifacts within the package which are changed during the configuration. Along with the name, the new content of the respective file is supplied. So the package deployer does not have to cope with the problem, how the configurations can be applied. It just has to replace a number of files. The following listing shows the schema of such amodifications file.

Listing 5.8: Schema for a Modifications file

1 < xsd : s c h e m a x m l n s : xsd =" h t t p :// www . w 3. org / 2 0 0 1 / X M L S c h e m a " > 2 < xsd : e l e m e n t n a m e =" m o d i f i c a t i o n s " t y p e =" M o d i f i c a t i o n T y p e "/ > 3 4 < xsd : c o m p l e x T y p e n a m e =" M o d i f i c a t i o n T y p e " > 5 < xsd : s e q u e n c e > 6 < xsd : e l e m e n t n a m e =" F i l e " t y p e =" F i l e T y p e " m i n O c c u r s = " 0 " m a x O c c u r s =" u n b o u n d e d "/ > 7 </ xsd : s e q u e n c e > 8 </ xsd : c o m p l e x T y p e > 9 10 < xsd : c o m p l e x T y p e n a m e =" F i l e T y p e " > 11 < xsd : s e q u e n c e > 12 < xsd : any m i n O c c u r s = " 0 " n a m e s p a c e = " # # any " p r o c e s s C o n t e n t s =" s k i p "/ > 13 </ xsd : s e q u e n c e > 14 < xsd : a t t r i b u t e n a m e =" f i l e N a m e " t y p e =" xsd : s t r i n g "/ > 15 </ xsd : c o m p l e x T y p e > 16 </ xsd : schema >

The content of a file can be any XML-based content. Non-XML based files are not supported by the package deployer.

5 Prototype

5.3.3.4. Repository

One requirement for the package deployer is to provide a repository. It stores the tem- plate and solution packages. Tuscany is able to read a contribution from a folder on the file system. So it is obvious to use the file system to create a repository.

The repository consists of two main folders:

• template

• solution

A template package is stored to the template folder by creating a new sub folder. It is named like the application, the template represents. This folder represents the root folder of the SCA contribution, the package consists of.

The solution packages reside in the solution folder. Again for every application a separate folder is created. But in this case, sub folders to store the tenant specific packages are required. A special folder is the fixed-folder. It contains all fixed packages which are required for different tenants.

The following figure shows an example of such a repository.

Figure 5.8.: Assembly of a Repository

The sub folders of afixed-folder are named like the folders of the tenant specific packages. It is incorrect to belief that such a fixed package is only used by a single tenant. In fact it can be used by many tenants. The name belongs to the first tenant, for which the package is needed. It is obvious to use this tenantId, since every single fixed package must have a unique name.

5 Prototype

According to the needs of the package deployer the repository implementation provides the following functions:

• create a new package from a template

• remove a package from the repository

• replace a file within a package by a new one

• delete a file within a package

• create a new file within a package

• get/search files within a package

• get templates, solution, etc.

Repository for Distributed Nodes In the scenario of a distributed execution of the nodes, it is necessary to provide the repository for all nodes at the same time. To achieve this, the repository can be made available by using a web server. Tuscany only accepts to load jar files from a web resource. Therefore, the package deployer allows to create a jar file in addition to the folder that contains the package.

5.3.4. Interface

This section describes the interface which is provided by the package deployer. As described in the architecture overview of the prototype, the package deployer must facil- itate the execution of solution packages in a tuscany distributed domain. To match the requirements, the package deployer provides six different operations. The functionality of the different operations and their parameters are enumerated in the following tables. In section 5.3.5 the implementation of these operations is described.

Create Solution In the first step the create solution operation applies the modifications file for the specific tenant. Afterwards, a tenant specific and if needed, a fixed package is created in the repository.

5 Prototype

Parameter Description

applicationId The applicationIddepicts the template for that the solution is created. Therefore, the applicationId must match the folder name which is used for the tem- plate package.

tenantId The tenantId is a unique identifier of the tenant for that the solution is created. The newly created package will be identified using theapplicationIdto- gether with the tenantId.

modifications A modifications file as described in section 5.3.3.3. This file represents the configurations that must be applied for the particular tenant.

Table 5.4.: Create Solution Operation

Delete Solution The delete solution operation removes a tenant specific package from the repository. If the package is the last one for an application, the fixed packages are deleted, too. They are useless.

Parameter Description

applicationId TheapplicationIdof the tenant specific package that will be deleted.

tenantId ThetenantId of the tenant specific package that will be deleted

Table 5.5.: Delete Solution Operation

Deploy Solution The deploy solution operation establishes a tenant specific package for thetuscany domain manager. Therefore, a node composite is created for every deployable composite in the package. The workspace, domain composite and cloud composite file of the domain are adapted to support the new package. If the package needs a fixed package for its operation which is not already deployed, then a fixed package is deployed, too.

5 Prototype

Parameter Description

applicationId TheapplicationIdof the tenant specific package that will be deployed.

tenantId ThetenantId of the tenant specific package that will be deployed.

nodeURI The URI for the node which will be created to run the first deployable composite of the package. If there is more than one deployable composite, for every new node a unique nodeURI has to be generated. If no nodeURI is supplied, the URI of the node for the first deployable composite is generated, too.

Table 5.6.: Deploy Solution Operation

Undeploy Solution The undeploy solution operation removes a tenant specific package from the tuscany domain. Therefore, the node composite is deleted for every deployable composite of the package. The composite files are also removed from the workspace file, domain composite and cloud composite file. If the package is the last deployed package of the application, all fixed packages are undeployed, too.

Parameter Description

applicationId TheapplicationIdof the tenant specific package that will be undeployed.

tenantId ThetenantId of the tenant specific package that will be undeployed

Table 5.7.: Undeploy Solution Operation

Start The start operation starts all nodes that belong to a tenant specific package. Ev- ery node is started in a separate JVM. To start the nodes, thenodeConfigurationURI which is provided by the domain manager is used. Nodes can either be started locally by the package deployer, or via anexternal node launcher on any other system. The nodes for the fixed package are started, if the tenant specific package needs a fixed package for its operation.

5 Prototype

Parameter Description

applicationId TheapplicationIdof the tenant specific package, for which the nodes will be started.

tenantId ThetenantIdof the tenant specific package, for which the nodes will be started.

domainManagerURI The URI of the domain manager which provides the nodeConfigurationURI.

nodeLauncherURI The request to start the node is redirected to a node launcher, if anodeLauncherURI is specified. Table 5.8.: Start Solution Operation

Stop The stop operation stops all nodes that belong to a tenant specific package. The process of the respective JVM is destroyed. The stop request is redirected to a launcher, if an external launcher was used to start the node. If the nodes for the last tenant specific package are stopped, the nodes of the fixed packages are stopped as well.

Parameter Description

applicationId The applicationIdof the tenant specific package for which the nodes will be stopped.

tenantId ThetenantIdof the tenant specific package for which the nodes will be stopped.

Table 5.9.: Stop Solution Operation

5.3.5. Implementation Details

This section describes the implementation of the different operations. For every opera- tion, the preconditions are enumerated. Afterwards a process is displayed. It represents the activities that are required to achieve the intended result. Every activity is described in detail.

5.3.5.1. Create Solution Preconditions

5 Prototype

• No tenant with the specified tenantIdalready exists.

• The supplied modifications change the package only in a correct way. This means, the package must still represent a complete SCA contribution. Otherwise errors will occur during the creation of the tenant specific and fixed package.

Creation of a Tenant Specific Package

As stated in 4.3, for every tenant, a tenant specific package has to be created. This package contains all artifacts needed to run the components, tagged with the multiple instances pattern. It also has to contain the component description of single configurable instance components. The following figure shows the process, passed for the creation of a tenant specific package. Below every step is described in detail.

Figure 5.9.: Tenant Specific Package Creation

Create a new Package from the Template As a first step, a folder for the new package is created in the repository. The content of the chosen template is copied to this location. Therefore, the new package equals the template package, at the beginning.

Apply the Modifications File The modifications file is applied for the newly created package. Therefore, the content of all files, listed in the modifications file, is replaced by the according modified content.

Read Deployable Composites A list of all deployable composites is created. The deployable composites are read from the contribution descriptor. If no contribution descriptor exists, all composites in the package are treated as deployable composites. This list is important for the further process.

5 Prototype

Read Pattern Attributes of all Components A map of all component names and their according multi-tenancy patterns is created. Only the components of the deployable composites are considered. To read the patterns JAXP is used. This is necessary because the pattern attribute does not exist in thetuscany assembly model.

Modify the Deployable Composite Files The following modification steps are executed in order to adapt the deployable composite files for a tenant specific package. In general the steps described in section 4.3.1 are performed. So, at the end of this step all multiple instances components will have a unique name. They will not interfere with components of other tenants. To modify the composite files, they are loaded into atuscany assembly model representation as described in 5.3.3.2. After the modification they are saved back to the same composite file. The following modification steps are performed:

• All components tagged with the single instance pattern are removed. These com- ponents reside in a fixed package. They can therefore be removed from the tenant specific package.

• All promoted references and services of the components that are removed in the first step, are removed too. These elements also reside in a fixed package.

• All wires that have a source and target outside the composite are removed.

• The property type and constraining type definitions are removed.

• The names of all components are modified by adding the tenantId to the name attribute. With this name change the URI of the component’s service binding changes, too. So the requirement, that every multiple instances component must have a unique endpoint, is met.

• To obtain the wiring, the target attributes of all references need to be renamed to match the component names that emerged from the last step.

• The name of the composite is modified by adding thetenantId. This is necessary, since all tenant packages are deployed to the same domain. All composites within a domain are required to have different names.

Check if a Composite File is Empty After the modification of the composite files, it can be possible, that a composite file does not contain any components. This happens for example, if all components are tagged with the single instance pattern. Such an empty composite file is without any function, if it is deployed. To avoid useless composites, these files are deleted and removed from the deployable composites list of the contribution descriptor. If all composite files of a package are deleted this way, then the package is

5 Prototype

without any function after its deployment. But to avoid confusion, such a package is not deleted automatically.

Apply the Implementation Mapping As stated in 4.3.4.2, the implementation map- ping file represents a list of components and implementation files which are required to run a particular component. Depending on the multi-tenancy pattern of a component, an action is performed.

Single Instance The implementation files can be deleted if they are not needed for other components. Because the according component descriptions reside in a fixed package, the files are not required in a tenant specific package. To make them available in other packages, an import statement is added to the contribution descriptor of the package.

Multiple Instances The implementation files are needed in the tenant specific pack- age. Therefore, no actions are performed.

Single Configurable Instance The implementation files are deleted in the tenant specific package, if they are not needed for multiple instances components. The files reside in a fixed package, because all tenants that utilize a single configurable instance component