Application design or service composition

Application design or service composition

So far we have looked at single services in isolation without talking about how to combine them. One of the most essential features of the ClaRA is the ability to take standalone services (application building blocks) and compose an application based on these services. For the following exercise we will design an application consisting of 2 services. We will use EvIO read and write services that were created in the previous tutorial section. A ClaRA application design process is nothing more then linking services together, which means that we present the output data of the first service as an input data for a service, linked to the first one. Let us now link the EvioFileReaderService to the EvioFileWriterService, creating a ClaRA application that copies the content of an EvIO format file to another file. We are not going to make EvioFileWriterService more intelligent making this application a purely proof of concept exercise. At this point we assume that the mentioned services are already deployed in a ClaRA environment. Now let us write a simple orchestrator the will link these services together. Here is the code:

{

public LinkServices(String name) {

}

In the main method we accept the canonical names of the services to be linked. After checking if these services are properly deployed we link them.

String oName = args[0];

String service1 = args[1];

String service2 = args[2];

LinkServices lso = new LinkServices(oName);

lso.updateRegistration();

if(!lso.isServiceRunning(service1)){

System.out.println("Error: Can not find the registration information for the service = "+service1);

System.exit(1);

}

// check if the service2 is registered

System.out.println("Error: Can not find the registration information for the service = "+service2);

System.exit(2);

}
// link services

if(!lso.linkServices(service1,service2)){

System.out.println("Error: linking services");

}

lso.exit(); } }

ClaRA application debugging and communication logging service

The clara-platform Unix script executed with a –log command line argument will start the service communications logging normative service. This is a service that logs all service communication transient meta-data in the ClaRA database. The parameter given to the –log option defines the severity level of a service execution status that will be logged in the database. For example the -log warning option will tell the logging service to log messages having warning or error status. The option –log without a parameter logs all messages (info, warning and error) from every service and or orchestrator actively running in a ClaRA DPE (data processing environment). Note that clara-dpe Unix shell script also has the –log option.

The table below illustrates the service_log table description that is used to store service communications transient meta-data.

Field	Type	Null	Key	Default	Extra
data	varchar(100)	NO	PRI	NULL
data_source	varchar(100)	YES		NULL
data_destination	varchar(100)	YES		NULL
data_description	varchar(100)	YES		NULL
exec_status	varchar(100)	YES		NULL
mime_type	varchar(100)	YES		NULL
data_unit	varchar(100)	YES		NULL
language	varchar(100)	YES		NULL
version	varchar(100)	YES		NULL
control	varchar(100)	YES		NULL
exception_source	varchar(100)	YES		NULL
exception_destination	varchar(100)	YES		NULL

Download 415.94 Kb.

Share with your friends: