Composite Service Configuration and Readers

A CSConfiguration object contains all the information provided by the user that is required to execute the service translation process. It consists of the following elements:

• Composite Service: The layered composite service object to be translated (discussed in Section 4.3.3).

• Composite Service Input Details: A list of records, each of which is composed of the name, data type and value of a specific input parameter of the composite service to be translated.

• Target Language: The language to which the composite service needs to be translated. At present, our implementation supports Objective Lucid, XML and DOT languages (discussed in Section 4.1).

• Destination Folder: Complete path of the folder where the translation file is placed once generated.

• DOT Executable Name: Complete path of the DOT executable file (dot.exe) required for executing the DOT program generated by the DOT translator module in order to produce a .png image file containing the graphical representation of the translated composite service.

Once a CSConfiguration object is created, its target language component is used to determine the appropriate translator module to be invoked, which accepts the configuration object as an argument. While the XML translator module makes use of only the composite service object contained within the configuration object for generating its target language representation, the Objective Lucid and DOT translators also require the input details and the DOT executable file location respectively in order to complete the translation. The destination folder component of the configuration is used by all of the currently available translator modules as the location for placing the translation files that each of them generates.

As mentioned in Section 4.3.1, a user can opt for different modes for supplying the composite service configuration details. We have designed and implemented an architecture (as depicted in Figure 20) that allows modular addition and removal of readers for each of these modes. At present, this implementation can support console and XML file readers.

Major design and implementation specifications of this architecture have been listed below:

• CSConfigReader is the interface to be implemented by all concrete composite service configuration readers. It declares the readCSConfig method, which should be defined

Figure 20: Composite Service Configuration Reader Architecture

to accept composite service configuration details from the user based on the mode of input being handled by each concrete reader.

The logger object created by the translation driver (described in Section 4.3.1) is provided as an argument to the readCSConfig method in order to allow any error messages generated during the construction of the CSConfiguration object to be recorded in a log file.

• ConsoleCSConfigReader is the concrete composite service configuration reader for interacting with the user through the console to obtain composite service configuration details. It implements the CSConfigReader interface and defines the readCSConfig method. After reading and processing all the required information, the method creates a CSConfiguration object to be used for service translation.

• FileCSConfigReader is the abstract class to be extended by all concrete composite service configuration file readers. It implements the CSConfigReader interface but does not define the readCSConfig method; the method is expected to be defined by

This class contains a configFileName data member and a mutator method for assigning a value to it. The configFileName member is inherited by all concrete file readers and stores the complete path of the file to be read by them.

• XMLFileCSConfigReader is the concrete composite service configuration reader for extracting composite service configuration details from a user-specified XML file. It extends the FileCSConfigReader class and defines the readCSConfig method.

After reading and processing all the required information, the method creates a CSConfiguration object to be used for service translation.

Readers for other file formats (depicted as OtherFileCSConfigReader in Figure 20) can be easily added to the existing architecture by extending the FileCSConfigReader class and defining the readCSConfig method to do the file-specific parsing. To include readers for other modes of input, such as, databases, a new class (depicted as OtherCSConfigReader in Figure 20) can be added to this hierarchy and made to implement the CSConfigReader interface while defining the required behavior in the readCSConfig method.

The readCSConfig method for the console reader is responsible for performing the following tasks:

1. Consecutively prompting the user on the console to provide the value for each element of a composite service configuration according to the following rules:

• CS Repository Filename must include the complete name (with extension) and path of the repository file containing description of the composite service to be translated. For now, only .txt and .xml are recognized as acceptable file extensions.

• Composite Service Name must be the name of the composite service to be extracted from the given repository for translation.

• Target Language Name must be the name of the formal language to which the specified composite service needs to be translated. For now, only Lucid, XML and DOT are recognized as acceptable target languages.

• CS Input Values must be in accordance with the name and data type mentioned in the prompt for each specific composite service input. User will be prompted for input values only if the chosen target language is Lucid.

• DOT Executable Filename must include the complete name (with extension) and path of the DOT executable file (dot.exe). User will be prompted for this file location only if the chosen target language is DOT.

2. Depending on the type of the specified repository, invoking the corresponding composite service reader (discussed in Section 4.3.3) in order to fetch the specified service’s description from the repository and using it to create the LayeredCompositeService object to be translated into the target language.

3. If the chosen target language is Lucid, creating a list of input records using the input name and data type from the LayeredCompositeService object and their respective values received from the user.

4. Creating a CSConfiguration object using the specified repository file location as the destination folder for the translation file to be generated together with all the other information collected in the preceding steps.

5. In case of any failures during the creation of the CSConfiguration object, recording proper error messages in the log file associated with the logger object accepted as an argument and aborting the translation process immediately.

The readCSConfig method for the XML file reader performs the same tasks as those performed by its console counterpart with the only distinction being that, instead of reading the configuration details from the console, this method obtains them by parsing a user-specified XML configuration file, which comprises of the following elements:

• csconfig: It is the root element of the XML file.

• csrepofilename: It appears once in the XML file, as a sub-element of the root. The

value assigned to its “value” attribute is the complete name (with extension) and path of the composite service repository file.

• csname: It appears once in the XML file, as a sub-element of the root. The value assigned to its “value” attribute is the name of the composite service to be extracted from the given repository for translation.

• targetlang: It appears once in the XML file, as a sub-element of the root. The value assigned to its “value” attribute is the name of the formal language to which the specified composite service needs to be translated.

• input: It appears once for each composite service input, as a sub-element of the root.

It has three sub-elements called “name”, “type” and “value”. The values assigned to the “value” attributes of these sub-elements are, respectively, the corresponding input’s name, data type and value. This element is required only for translation to Lucid.

• dotexename: It appears once in the XML file, as a sub-element of the root. The value assigned to its “value” attribute is the complete name (with extension) and path of the DOT executable file (dot.exe). This element is required only for translation to DOT.

The same format and rules apply to composite service configuration’s XML elements as defined for the console mode. As examples, consider Listings 4.4, 4.5 and 4.6, depicting the contents of the XML configuration files for translating the Range composite service (depicted in Figure 17) into XML, DOT and Objective Lucid respectively.

Listing 4.4: Range CS Configuration for XML Translation (in XML File Format)

1 <?xml version=‘‘1.0’’ encoding=‘‘UTF−8’’ standalone=‘‘no’’?>

2 <csconfig>

3 <csrepofilename value=‘‘testinput/xmltranslatortests/Serialized Repository . txt ’ ’/>

4 <csname value=‘‘range’’/>

5 <targetlang value=‘‘XML’’/>

6 </csconfig>

Listing 4.5: Range CS Configuration for DOT Translation (in XML File Format)

Listing 4.6: Range CS Configuration for Lucid Translation (in XML File Format)

1 <?xml version=‘‘1.0’’ encoding=‘‘UTF−8’’ standalone=‘‘no’’?>

2 <csconfig>

3 <csrepofilename value=‘‘testinput/ lucidtranslatortests /Serialized Repository . txt ’ ’/>

4 <csname value=‘‘range’’/>

As mentioned in Section 4.3.2, a user can specify different types of composite service repositories as part of composite service configurations. Based on the repository type specified in a configuration, the operating composite service configuration reader invokes a particular composite service reader for parsing the given repository, using the composite service name from the configuration for locating the service in the repository and