[Ctk-developers] CTK based Hosted App fails when launched from Non-CTK Host

[Sascha Zelzer]

Hi Anthony,

Welcome to the ctk-developers list.

> We've tried adapting one of our DICOM application into a CTK Based 
> Hosted App. It works well when tried with the ctkhost - we could 
> launch the app, load the DICOM data and get through different states 
> as well.
>

So far, good news.

> However when tried launching the same app with different non-ctk based 
> host,  it launches our app but fails to load any data. This non-ctk 
> based host seems to be written using the WCF as per specification in 
>  DICOM 118.
>

Please note that we could only test our implementation against the XIP 
host (written in Java) so far. So the problems you are experiencing 
might very well relate to our implementation.

> On investigating, we noticed that the initial ‘IDLE’ message sent by 
> the App upon launch is not getting processed by the Non-CTK based host.
>
> When traced the SOAP communication, we foundout that the messages from 
> the plug-in are getting to the host, but then they are not processed 
> by WCF because of some WSDL contacts mismatch. Thus the host does not 
> receive any messages. Here’s the log message:
>
> <Message>*The message with Action '' cannot be processed at the 
> receiver, due to a ContractFilter mismatch at the EndpointDispatcher. 
> This may be because of either a contract mismatch (mismatched Actions 
> between sender and receiver) or a binding/security mismatch between 
> the sender and the receiver.  Check that sender and receiver have the 
> same contract and the same binding (including security requirements, 
> e.g. Message, Transport, None).*</Message>
>
> When debugging the WCF processing of the message we get the 
> deserialization error:
>
> "The ':' character, hexadecimal value 0x3A, cannot be included in a 
> name. Line 4, position 11."
>
> Here’s the SOAP message braced between the CTK-plugin and Non-CTK 
> based Host:
>
> <SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsd="http://www.w3.org/1999/XMLSchema">
>
> <SOAP-ENV:Bodyxmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
>
> <notifyStateChangedxmlns="http://wg23.dicom.nema.org/">
>
> <newState:type="xsd:string">IDLE</newState>
>
> </notifyStateChanged>
>
> </SOAP-ENV:Body>
>
> </SOAP-ENV:Envelope>
>
> We can see the “:type” item in the newState element that’s causing the 
> error in WCF. Also, per DICOM supplement 118 it should be called 
> “state”, not “newState”.
>

Looking at the debug output from the CTK hosted app, the xml namespace 
for the "type" attribute in the "newState" tag is intact. So I am 
wondering it the output above has already been modified somehow by the 
WCF host or if it is the original message from the CTK hosted app.

> Here’s the example of the SOAP message generated by Non-CTK based 
> HostedApp:
>
> <s:Envelope  xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
>           <s:Body>
>                   <NotifyStateChanged  xmlns="http://dicom.nema.org/PS3.19/HostService-20100825">
>                            <state>IDLE</state>
>                   </NotifyStateChanged>
>           </s:Body>
> </s:Envelope>
>
> Next, we tried changing “newState” to “state” but again it fails when 
> tried with  the  non-ctk based host and producing the same error.
>

I think it is still either related to the ":type" attribute or the error 
described below. Concerning state/newState, please also see my comments 
below.

>  ...
>
> /2011-09-06 17:17:59,609 <faultstring xsi:type="xsd:string" 
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">The message with 
> Action '' cannot be processed at the receiver, due to a ContractFilter 
> mismatch at the EndpointDispatcher. This may be because of either a 
> contract mismatch (mismatched Actions between sender and receiver) or 
> a binding/security mismatch between the sender and the receiver.  
> Check that sender and receiver have the same contract and the same 
> binding (including security requirements, e.g. Message, Transport, 
> None).</faultstring>/
>
> /.../

This actually hints at a problem concerning the action names. Looking at 
the WSDL, the operation names start with upper case latters, where we 
are using lower case (unfortunately, the text in the DICOM Part 19 specs 
refer to the method names with starting lower case letters).

> I even tried replacing the WSDL files with the one provided by Non-CTK 
> based  host, but still it doesn’t  seem to work.
>

Yes, that does not change the actual behavior.

> When looked at the code, I noticed a comment in the CTK code (below 
> methods)  “spec would be "state", java has "newState" FIX 
> JAVA/STANDARD”. Could  this be something we need to look for? If so 
> may I know what would be the change in Java side.
>

Unfortunately, again, the text in the specs refer to "newState" for the 
argument name and this is what the XIP host is using. So we used it too 
for testing with XIP. But I agree that the WSDL should be the definite 
guide and we should use "state" when not testing with XIP.

My advice would be to keep your modification ("newState" -> "state") and 
also try to modify the action (method) names in ctkDicomAppService.cpp 
(lines 40 - 60) to use upper case for the first letter.

I would be happy if you could keep us posted about your progress.

Thanks,
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110908/83833dff/attachment.html>