PLAZOS Y PRÓRROGAS DE LAS DILIGENCIAS DE INVESTIGACIÓN.

Tuscany [8] is the most accepted SCA engine at the time this thesis is created. It also comes in handy, that tuscany is an open source project. So the code can be used to improve the comprehension of a SCA runtime. Although tuscany is under agile development, some features of SCA are not completely implemented yet.

For the execution of different component implementations, tuscany utilizes other apache projects. To execute a BPEL process for example, the apache ODE engine [6] is used. Web services are realized via apache tomcat and axis.

Tuscany implements the SCA specification in the version 1.0. It is a very lightweight engine, so it can be easily distributed along with a SCA application. Two different implementations exist. One implementation is written in Java, the other uses C++ as programming language. The C++ implementation is also referred to as native.

For this diploma thesis solely the Java implementation was used. This implementation provides two different kinds of SCA domains. A domain which runs on a single JVM (Java Virtual Machine). And a domain, that is distributed over several JVMs. These two options to create a domain using tuscany, are described in the following.

Tuscany Node In order to understand the assembly of a SCA domain in tuscany, the concept of a node has to be understood. In tuscany, the runtime which allows to run a SCA application, is always wrapped up in a node. A node therefore contains all func- tions that are needed to run a SCA composite. These functions are provided by the files in the libs and modules folders of a tuscany distribution.

5 Prototype

In tuscany a node always runs a single composite which runs in a single JVM. A JVM on the other hand, can host multiple nodes.

So a tuscany node represents a self-contained application which can be started indepen- dently from other nodes. This concept gets more comprehensible, by understanding, how it is used in a standalone and a distributed domain.

Standalone Domain To realize a standalone domain, only one node is used. This node executes the most outer composite of an application. Figure 5.5 illustrates the assembly of a standalone domain. The picture shows a calculator application which is distributed as a sample with every tuscany distribution. Each operator of the calculator is managed by a separate component.

To start the standalone domain, commonly a Java client program is used. The following listing shows a short Java code snippet which is used to start a domain.

Listing 5.2: Client to start a SCA Domain

1 i m p o r t org . a p a c h e . t u s c a n y . sca . h o s t . e m b e d d e d . S C A D o m a i n ; 2 3 p u b l i c c l a s s C l i e n t { 4 p u b l i c s t a t i c v o i d m a i n ( S t r i n g [] a r g s ) t h r o w s E x c e p t i o n { 5 6 // s t a r t the d o m a i n 7 S C A D o m a i n s c a D o m a i n = S C A D o m a i n . n e w I n s t a n c e (" S a m p l e . c o m p o s i t e ") ; 8 9 / / . . . use the a p p l i c a t i o n 10 S a m p l e S e r v i c e s a m p l e S e r v i c e = 11 s c a D o m a i n . g e t S e r v i c e ( s a m p l e S e r v i c e . class , " S a m p l e S e r v i c e C o m p o n e n t ") ; 12 13 s a m p l e S e r v i c e . e x e c u t e () ; 14 15 // s t o p the d o m a i n 16 s c a D o m a i n . c l o s e () ; 17 } 18 }

In this code snippet, a number of functions that use the newly started SCA application are called, after the domain is started. At the end the domain is stopped.

Certainly it is possible to run a standalone domain without having to stop it instantly. Furthermore not every service is needed to be called from a Java program, like in this example. For instance, one can think of a service that provides a web interface which is called using a web browser.

Another method to start a standalone domain, is to create a web application for apache tomcat that runs a tuscany node.

5 Prototype

In summary a standalone domain uses the same concept of a node that is used for the distributed domain. But in this special case, the node is not connected to any other node and therefore represents the whole application.

Figure 5.5.: Example of a Standalone Domain [8]

Distributed Domain The SCA specification does not provide a detailed description on the way, SCA applications can be distributed over several hosts. Therefore, the distributed domain is a tuscany specific function. Nevertheless it was chosen to be used for this prototype. The advantage of this approach is, that the execution of the application packages which are created by the package deployer, can be distributed to several hosts (see 5.5).

In a distributed domain, not only one node is used. In fact several nodes build the domain, where each node again runs a single composite.

These composites are not needed to be complete. The application is build up by the domain composite which includes all the composites that make up the application. In the

5 Prototype

case of the tuscany distributed domain, the domain composite is not a virtual composite, but is stored in a concrete composite file.

For the administration and the interconnection of the nodes, a domain manager is used. So a distributed domain enables the distribution on the level of components by portioning them to several composites.

Figure 5.6 shows the same application as the picture for the standalone domain. In this case the add and subtract operator are distributed to separate nodes.

Figure 5.6.: Example of a Distributed Domain [8]

Domain Manager In order to understand the assembly of a distributed domain, it is necessary to understand the domain manager. It is used to start and interconnect the single nodes.

The information needed by the domain manager is stored in two main composite files. The domain composite which includes all composite files that make up the applications and a cloud composite which is used to interconnect the different nodes. To be included to the cloud composite, a node has to be described by a special node composite file. To locate the files of a contribution, a workspace file is used.

5 Prototype

To ease the comprehension, listings of the different files are presented in the following. These files are used to run the calculator application which is shown in figure 5.6.

Domain Composite

The domain composite includes all composite files that make up the application. It represents the virtual domain composite, described in the SCA specification.

Listing 5.3: Domain Composite File

1 < c o m p o s i t e n a m e =" d o m a i n . c o m p o s i t e " t a r g e t N a m e s p a c e =" h t t p :// t u s c a n y . a p a c h e . org / x m l n s / sca /1.0" > 2 < i n c l u d e n a m e =" ns 2: C a l c u l a t o r A " uri =" n o d e A "/ > 3 < i n c l u d e n a m e =" ns 2: C a l c u l a t o r B " uri =" n o d e B "/ > 4 < i n c l u d e n a m e =" ns 2: C a l c u l a t o r C " uri =" n o d e C "/ > 5 </ c o m p o s i t e > Node Composite

Every node composite file contains exactly one component that uses a special node im- plementation type. For this implementation type the composite file which has to be executed by the node must be specified. For every node a separate URI has to be as- signed. This URI overwrites the base system URIs (see 2.3.6) of all binding URIs. To facilitate this, thenodeURI is specified for every binding type of the node implemen- tation component. The listing shows the composite file for the node which contains the add operation.

Listing 5.4: Node Composite File

1 < c o m p o s i t e x m l n s =" h t t p :// www . o s o a . org / x m l n s / sca / 1 . 0 " 2 x m l n s : t =" h t t p :// t u s c a n y . a p a c h e . org / x m l n s / sca / 1 . 0 " 3 t a r g e t N a m e s p a c e =" h t t p :// s a m p l e / c l o u d " 4 x m l n s : s =" h t t p :// s a m p l e " 5 n a m e =" N o d e A " > 6 7 < c o m p o n e n t n a m e =" N o d e A " > 8 < t : i m p l e m e n t a t i o n . n o d e uri =" n o d e A " c o m p o s i t e =" s : C a l c u l a t o r A "/ > 9 < s e r v i c e n a m e =" N o d e " > 10 < b i n d i n g . sca uri =" h t t p :// l o c a l h o s t : 8 1 0 0 " / > 11 </ service > 12 </ c o m p o n e n t > 13 14 </ c o m p o s i t e > 56

5 Prototype

The service of the AddServiceComponent has the following URI:

http://localhost:8100/AssServiceComponent/AddService

Cloud Composite

The cloud composite file includes all node composites. It is used to connect the different nodes that make up an application. Nodes that are not enlisted in the cloud composite, are not accessible from other nodes.

Listing 5.5: Cloud Composite File

1 < c o m p o s i t e n a m e =" c l o u d . c o m p o s i t e " t a r g e t N a m e s p a c e =" h t t p :// t u s c a n y . a p a c h e . org / x m l n s / sca /1.0" > 2 < i n c l u d e n a m e =" ns 2: N o d e A " uri =" h t t p :// t u s c a n y . a p a c h e . org / c l o u d "/ > 3 < i n c l u d e n a m e =" ns 2: N o d e B " uri =" h t t p :// t u s c a n y . a p a c h e . org / c l o u d "/ > 4 < i n c l u d e n a m e =" ns 2: N o d e C " uri =" h t t p :// t u s c a n y . a p a c h e . org / c l o u d "/ > 5 </ c o m p o s i t e > Workspace

Certainly the domain manager needs to have the information, where the contributions are stored. They contain the composite and the according implementation files. Therefore, all contributions must be listed in a workspace file. The following snippet shows the workspace file for the calculator application.

Listing 5.6: Workspace File

1 < w o r k s p a c e x m l n s =" h t t p :// t u s c a n y . a p a c h e . org / x m l n s / sca / 1 . 0 " x m l n s : ns 1=" h t t p :// t u s c a n y . a p a c h e . org / x m l n s / sca /1.0" > 2 < c o n t r i b u t i o n l o c a t i o n =" f i l e :./ src / m a i n / r e s o u r c e s / n o d e A " uri =" n o d e A "/ > 3 < c o n t r i b u t i o n l o c a t i o n =" f i l e :./ src / m a i n / r e s o u r c e s / n o d e B " uri =" n o d e B "/ > 4 < c o n t r i b u t i o n l o c a t i o n =" f i l e :./ src / m a i n / r e s o u r c e s / n o d e C " uri =" n o d e C "/ > 5 < c o n t r i b u t i o n l o c a t i o n =" f i l e :./ src / m a i n / r e s o u r c e s / c l o u d " uri =" h t t p :// t u s c a n y . a p a c h e . org / c l o u d "/ > 6 </ w o r k s p a c e >

Starting a Domain Manager Like for the standalone domain, the domain manager of a distributed domain can be started via a Java program. The files which build the domain must be stored in the working directory of this program. It is interesting, that the domain manager is implemented using a standalone tuscany domain.

5 Prototype

Tuscany Node Launcher Tuscany provides different ways to launch a node for a dis- tributed domain. The method which is used for the implementation of the package deployer utilizes the domain manager.

When a node is successfully established in the workspace, domain composite and cloud composite file, the domain manager provides a so callednodeConfigurationURI. At this endpoint all necessary information is stored, that is needed to start a node. There- fore, a special node launcher program exists that executes a new node only by the specification of this URI.

Figure 5.7 illustrates the assembly of a tuscany distributed domain.

Figure 5.7.: Assembly of a Tuscany Distributed Domain