3.2.4. Initializing the QALL-ME Framework

All WSs of your demo QA system are running now, however, a few of them still need to be initialized. In particular this is the system-wide QAPlanner WS and all QueryGenerator instances you have chosen to deploy. Initializing in this context means that we have to tell these WSs the locations of other WSs which the former are referencing and using. The QAPlanner basically encapsulates the complete QA system and thus calls and manages almost all available WSs; because of that it also has to be provided with all these WSs. The QueryGenerator WSs need working EntailmentTesters (cf. section 2.3.2: “System Components”) and a reference to the WS which converts TIMEX2 annotations to SPARQL filters (cf. section 4.2.3.3).

Initializing is done using dedicated web methods of the two types of WSs. Let’s first initialize the QueryGenerators.

There are five web methods available for each QueryGenerator which can be found below every QueryGeneratorPortBinding node in soapUI: generateSPARQLQuery, getEntailmentTester, setEntailmentTester, getTimex2SparqlConverter and setTimex2SparqlConverter. As you have probably guessed, the interesting web methods here are setEntailmentTester and setTimex2SparqlConverter. The only thing these two web methods need is the WSDL URL of the EntailmentTester for the language of the respective QueryGenerator implementation and the WSDL URL of the system-wide Timex2SparqlConverter WS. Let’s have a look at in which format these web methods want to get these URLs: open the Request 1 entry below the setTimex2SparqlConverter by double-clicking on it. In the new editor window you can see a complete SOAP request as it is sent to the WS. SoapUI has already created a request body skeleton based on the interface information it has gotten from the WSDL description. The <uri> element contains a question mark which we have to replace with the correct parameter. As said, this has to be the WSDL URL of the deployed system-wide setTimex2SparqlConverter implementation; in our case this may have been something like http://localhost:8080/qmfdemo/timex2sparqlconversion/Timex2SparqlConverterWS – see Figure 3.8. The request is now ready to be submitted to the WS. Therefore simply click on the green arrow in the top left corner of the Request 1 window. If you have entered a correct URL, then you should get get back a <dummy> element only – otherwise a SOAP fault.


Your QueryGenerator now knows about the Timex2SparqlConverter to use internally; you can check this using the getTimex2SparqlConverter web method. In the request editor you don’t have to provide any parameters – the created dummy value is sufficient. After clicking on the green submit button again, you should get back exactly the URL you have entered previously. As the Timex2SparqlConverter is a system-wide WS you can now set the same WSDL URL in all your QueryGenerator instances in the same way.

What is still missing in your QueryGenerator initializations is the setting of the EntailmentTesters to use via the setEntailmentTester web methods. This works in the same way as setting the Timex2SparqlConverter. Just make sure you always select the WSDL URL of an appropriate EntailmentTester implementation, i.e., of an implementation for the same language as the respective QueryGenerator. For example, in the German QueryGenerator implementation you have to set an EntailmentTester implementation for German, too. Initialize all QueryGenerators which you are using now to complete the QueryGenerator initialization.

Initializing the QAPlanner is very similar to the initialization of the QueryGenerators: you pass WSDL URLs to its setComponent web method. However, as the planner manages QA subsystems for several language and location specific subsystems it is not sufficient to just pass in WSDL URLs; otherwise the planner would not know to which language or location subsystem the given component belongs. Therefore you also have to specify whether a given component is system-wide, language specific or location specific and – in the two latter cases – to which language or location subsystem the component belongs.

When you open the request editor for the setComponent web method, you’ll see that soapUI has again created a SOAP request skeleton already:

<soapenv:Body>
	<qap:ComponentSetupRequest>
		<componentID>?</componentID>
		<!--Optional:-->
		<componentLang>?</componentLang>
		<!--Optional:-->
		<componentLoc>?</componentLoc>
		<!--Optional:-->
		<systemWideComponent/>
		<wsdlURL>?</wsdlURL>
	</qap:ComponentSetupRequest>
</soapenv:Body>
Unfortunately the XML comments in the skeleton are a bit misleading. Having a look at either the WSDL interface definition for the web method or the reference manual section for the QAPlanner (cf.
4.2.2.2), you will find out that there are actually three different kinds of possible requests: the three elements <componentLang>, <componentLoc> and <systemWideComponent> are mutually exclusive but one of them must be present in every request.

No matter which of the three requests you use, you always have to provide an ID for the component type you are trying to set and the WSDL URL of the component implementation you’d like to use. The latter parameter should be clear: as for the initializations we have done previously you have to have a look at the appropriate administration page in your application server and copy the correct URL from there. The component type ID has to be the target namespace URI of the WSDL definition of the component type that you’d like to set. Such an ID is unique for a certain type of WS, i.e., there can be different language or location specific implementations that have the same namespace or ID. There are several places where you can find the correct namespace for the WS that you are setting. In soapUI you can simply double-click on the WS in question: in the opening client window you find the required information in the Overview tab under Namespace in the WSDL Definition section. For example, when double clicking on the LanguageIdentifierPortBinding node of your soapUI project, you get the LanguageIdentifierPortBinding client window as depicted in Figure 3.9; the namespace URI of the LanguageIdentifier WSs is http://qallme.sf.net/wsdl/languageidentification.wsdl.


It should be clear now, how system-wide components are set in the QAPlanner using the setComponent web method. Here is an example for the LanguageIdentifier:

<soapenv:Body>
	<qap:ComponentSetupRequest>
		<componentID>http://qallme.sf.net/wsdl/languageidentification.wsdl</componentID>
		<systemWideComponent/>
		<wsdlURL>http://localhost:8080/qmfdemo/languageidentification/LanguageIdentifierWS?wsdl</wsdlURL>
	</qap:ComponentSetupRequest>
</soapenv:Body>
Actually the LanguageIdentifier is currently the only system-wide component of which the QAPlanner needs to know, so after submitting the above request, we’re done with regard to the system-wide components.[
5]

Setting language and location specific components is very similar. You just have to additionally specify the language or location for the component to set. Languages are represented by their two-letter, lower-case ISO 639-1 alpha-2 codes, such as “de” for German. Locations are represented by their two-letter, upper-case ISO 3166-1 alpha-2 codes, such as “GB” for the United Kingdom. Setting a language specific component can then be done with the following SOAP request body – here showing the one for a German QueryGenerator component:

<soapenv:Body>
	<qap:ComponentSetupRequest>
		<componentID>http://qallme.sf.net/wsdl/querygeneration.wsdl</componentID>
		<componentLang>de</componentLang>
		<wsdlURL>http://localhost:8080/qmfdemo/de-querygeneration/QueryGeneratorWS?wsdl</wsdlURL>
	</qap:ComponentSetupRequest>
</soapenv:Body>
Location specific components are set with a request similar to the following one for an AnswerPool for Great Britain:
<soapenv:Body>
	<qap:ComponentSetupRequest>
		<componentID>http://qallme.sf.net/wsdl/answerpool.wsdl</componentID>
		<componentLoc>GB</componentLoc>
		<wsdlURL>http://localhost:8080/qmfdemo/GB-answerpool/AnswerPoolWS?wsdl</wsdlURL>
	</qap:ComponentSetupRequest>
</soapenv:Body>
Set all your language and location specific components now of which the QAPlanner should know. This should be all WS components except for the EntailmentTesters as they only need to be known by the QueryGenerators. Just to be clear here: you will have to run an extra request for every component you set.

Congratulations, all initializations are done! You have a complete and fully functional QA system now which possibly even answers questions cross-lingually.



[5] There are currently three system-wide components in the QALL-ME Framework in total. However, the QAPlanner doesn’t need to know about itself and the Timex2SparqlConverter is only relevant for the QueryGenerators. Because of this we only have to set the LanguageIdentifier component in the QAPlanner.