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.
Figure 3.8. A complete SOAP request for the
setTimex2SparqlConverter web method of the
QueryGenerator is ready to be submitted.
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>
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.
Figure 3.9. The LanguageIdentifierPortBinding client window
can be used to find out the WSDL target namespace of the
LanguageIdentifier WS
implementations.
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>
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>
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>
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.
