[Ctk-developers] Ctk-developers Digest, Vol 26, Issue 6

Sascha Zelzer s.zelzer at dkfz-heidelberg.de
Fri Sep 9 04:26:56 EDT 2011


Hi,

On 09/09/2011 01:18 AM, Anthony Dass wrote:
> Hello Sascha and Ben,
>
> Thank you very much for the quick and detailed answers.
>
> In addition, when we tried to validate the message using the 
> online validations - http://www.xmlvalidation.com we also see the type 
> attribute :type="xsd:string" is not a valid XML attribute string and 
> also it looks that the namespace name is missing here. The string 
> should be either type="xsd:string" if no namespace is used(without 
> leading colon), or this xmlns:type="xsd:string" if xmlns is a 
> namespace name.
>
> Since the method addMethodAttribute of QtSoapmessage is setting this, 
> is that we need to change in the QtSoap module? or any other options? 
> please advice.

I had a look at the messages yesterday and could actually not reproduce 
your problem with the missing namespace (the messages between the CTK 
host and CTK app looked correct). I also looked at the QtSoap code and 
could not spot a problem at first sight.

Best,
Sascha

>
> thank you very much!
> /Anthony
>
>
> On Thu, Sep 8, 2011 at 6:47 AM, <ctk-developers-request at commontk.org 
> <mailto:ctk-developers-request at commontk.org>> wrote:
>
>     Send Ctk-developers mailing list submissions to
>     ctk-developers at commontk.org <mailto:ctk-developers at commontk.org>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>     http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>     or, via email, send a message with subject or body 'help' to
>     ctk-developers-request at commontk.org
>     <mailto:ctk-developers-request at commontk.org>
>
>     You can reach the person managing the list at
>     ctk-developers-owner at commontk.org
>     <mailto:ctk-developers-owner at commontk.org>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of Ctk-developers digest..."
>
>
>     Today's Topics:
>
>       1. Re: CTK based Hosted App fails when launched from Non-CTK
>          Host (Benoit Bleuze)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Thu, 8 Sep 2011 12:46:30 +0200 (CEST)
>     From: Benoit Bleuze <benoit.bleuze at inria.fr
>     <mailto:benoit.bleuze at inria.fr>>
>     Subject: Re: [Ctk-developers] CTK based Hosted App fails when launched
>            from Non-CTK Host
>     To: Sascha Zelzer <s.zelzer at dkfz-heidelberg.de
>     <mailto:s.zelzer at dkfz-heidelberg.de>>
>     Cc: Anthony Dass <antdass at gmail.com <mailto:antdass at gmail.com>>,
>     ctk-developers at commontk.org <mailto:ctk-developers at commontk.org>
>     Message-ID:
>     <610925954.61455.1315478790178.JavaMail.root at zmbs4.inria.fr
>     <mailto:610925954.61455.1315478790178.JavaMail.root at zmbs4.inria.fr>>
>     Content-Type: text/plain; charset="utf-8"
>
>     Hi Anthony, Sascha gave you all the technical answers we had in
>     stock so far, but I can add a bit of context here, it may help. As
>     Sascha said, the state/newState switch is due to XIP not following
>     the specifications. And your change is valid. We started with
>     "state", but the only other host we could use being XIP, we
>     changed it. You are welcome to revert it. I think we notified
>     Larry (Lawrence Tarbox) of that problem during the last hackfest
>     in Chapel Hill. Eventually XIP will change its API there (or so I
>     hope). Replacing the WSDL files doesn't change anything since we
>     don't use them to generate the interface, all the messages are
>     hard coded soap messages constructed from C++. Now I know nothing
>     of the WCF unfortunately, so I can't tell you whether the "type:"
>     keyword is misinterpreted or whatever. Sascha's suggestion of
>     changing the casing sounds promising to me. I remember we used
>     capitals in some actions , following the WSDL actually, and had to
>     change it afterwards for
>      specifications and XIP compatibility. I remember Larry telling us
>     the WSDL provided in the specs was not up to date, and thus we
>     provide an updated (or at least it was valid last february) set of
>     WSDL (and siblings) files there:
>     http://www.commontk.org/index.php/File:Wsdl_ft.zip Note that they
>     also have actions starting with capitals. I have a faint memory of
>     Larry giving us an explanation as to why they were upper cased,
>     but I can't remember the reason, my guess is that the .Net
>     implementation forced them to do so. And it is very well possible
>     that the XIP java implementation accepts both casing and the .NET
>     or WCF are stricter, so I guess you'll have to choose between the
>     proposed WSDL and the specifications... Keep us posted of your
>     progress. Ben ----- Original Message -----
>     > 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 found out 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:Envelope xmlns: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:Body xmlns:SOAP-ENV = "
>     > > http://schemas.xmlsoap.org/soap/envelope/ " >
>     > > < notifyStateChanged xmlns = " 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
>     > _______________________________________________
>     > Ctk-developers mailing list
>     > Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
>     > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     <http://public.kitware.com/pipermail/ctk-developers/attachments/20110908/e75bdbbd/attachment.htm>
>
>     ------------------------------
>
>     _______________________________________________
>     Ctk-developers mailing list
>     Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
>     http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>     End of Ctk-developers Digest, Vol 26, Issue 6
>     *********************************************
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110909/1cd1a009/attachment.html>


More information about the Ctk-developers mailing list