Re: [Opaltoolkit-users] opal bugs

[Anthony B. <ant...@ir...>]

Hi,
I'll give you the code soon, but for now you can view an example there:
The original WSDL generated by Opal: 
http://genoweb3.irisa.fr:8383/opal2/services/TuiuiuServicePort?wsdl
And the specific WSDL generated by our code: 
http://genoweb3.irisa.fr:8383/typedservices/TuiuiuServicePort.wsdl

We use the 'type' tag to create it. In fact it's basically an xslt 
stylesheet applied to the original WSDL and which uses types defined in 
the config file.
Then we have a servlet filter that do the conversion from the 
corresponding SOAP request (with specific fields) to a SOAP request in 
the format expected by Opal: this is done with another xslt stylesheet 
which uses the types from config file to reconstruct the command line args.

Regards,
Anthony

Luca Clementi wrote:
> osallou wrote:
>> Hi,
>> a few comments about mail.
>> About drmaa, the case:
>>
>> opal2/ -> using DRMAA version X
>> someotherapp/ -> using DRMAA version Y
>>
>> is not a good case. This is true for most of libraries, but not for 
>> DRMAA. drmaa library requires that you init it only once as a thread 
>> safe library. It should not be loaded multiple times on the same 
>> container (see drmaa doc). To manage this, it needs to be put in 
>> common/shared libs so that it is loaded only once for all web apps.
>
> Dear Olivier,
> Thanks for the info. In the next release we will consider moving DRMAA 
> in common/lib as you suggest.
>> About the code we developped, it is just a servlet filter, it does 
>> not modify the Opal code. It is placed as a filter in front of the 
>> webapp in the web container. This way, the basic WSDL generated by 
>> Opal is still valid (and generic). We provide in fact an additional 
>> WSDL per application which is specific (defines each parameters) and 
>> more useful for end-user when used via tools like Taverna which loads 
>> the WSDL to present it as a component inthe GUI.
>> So, this is only an add-on which can be added (or not) in the web 
>> container to provide additional functionality. Anthony will provide 
>> you the code to have a look. If basic WSDL is used, the filter 
>> transparently send the message to Opal. If specific WSDL is used, 
>> then it modify it (from specific to generic) and send the transformed 
>> message to Opal.
>
> That sounds very interesting.
>
> So far our approach is based on creating customized opal node for the 
> various Workflow systems (at the moment we have one for Kepler and one 
> for Vision) that read the application metadata (the 'type' tag in our 
> appConfig 
> http://www.nbcr.net/software/opal/docs/2.0/opalgui-advancedsub.html) 
> and create their input and output accordingly.
>
>
> Just a question, how do you describe the input and output of your 
> application? Do you use our 'type' tag or you have defined you own 
> language?
>
> Sincerely,
> Luca