Friday, October 22, 2004

Great minds don't think alike

I disagree with the idea that great minds think alike.  But when they do, you can be pretty sure it's a great idea.

Wednesday, June 09, 2004

Java client for an ASP.NET web service, part 6

It turns out that the change to RPC style was exactly what made the difference. Now the Java client can call into my .NET web service without a problem. Specifically, I added the following class attribute to my web service:
[System.Web.Services.Protocols.SoapRpcService]
This changed the format of the WSDL that .NET generates drastically. All the operations are still there, but instead of being in "message" format, they are in "RPC" format. I actually don't know what that means, but it makes the clients work.

Now to make sure it doesn't break our ColdFusion clients...

Tuesday, June 08, 2004

Java client for an ASP.NET web service, part 5

I have switched from "message" style to "RPC" style encoding of the WSDL in response to advice on the MSDN web site: http://msdn.microsoft.com/library/en-us/dnservice/html/service12052001.asp. Apparently Java uses RPC more frequently. Maybe it will make a difference.

Java client for an ASP.NET web service, part 4

I tried this:
<?xml version="1.0" encoding="UTF-8"?> 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
	<soapenv:Body> 
		<StartEvaluation xmlns="http://ottawa.byu.edu/Emar" href="#id0" > 
		</StartEvaluation> 

		<multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="" xsi:type="ns1:StartEvaluation" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://ottawa.byu.edu/Emar"> 
			<PIN xsi:type="xsd:string">TESTPIN</PIN> 
			<QuestionnaireName xsi:type="xsd:string">READY</QuestionnaireName> 
		</multiRef> 
	</soapenv:Body>
</soapenv:Envelope>
According to my last idea, this ought to work because the href is now in the StartEvaluation tag, so the arguments would be put directly where they ought to go. This doesn’t work either. After researching tons on Google on the problem, it appears that this notation is an advanced one. Seeing as I am running .NET web services code that was written 2+ years ago, I would not be surprised if Microsoft has not implemented it yet. I am looking into the options for upgrading the server. Maybe they have patches...

Java client for an ASP.NET web service, part 3

I came across a very handy, easy to compile Java application that makes it easy to just paste in and modify SOAP requests and analyze the web service responses. It may help in any debugging you may do.
http://www.nsftools.com/tools/SoapTester.htm

Java client for an ASP.NET web service, part 2

I got it to work, with modification. Here’s a snippet of what the client was trying:
<StartEvaluation xmlns="http://ottawa.byu.edu/Emar">
	<parameters href="#id0" xmlns=""/>
</StartEvaluation>
<multiRef id="id0" ...>
	<PIN xsi:type="xsd:string">TESTPIN</PIN>
	<QuestionnaireName xsi:type="xsd:string">READY</QuestionnaireName>
</multiRef>
I have never seen the href->id link notation before, but I researched it, and I believe that, if .NET were interpreting it correctly, that this is how it would be re-assembled:
<StartEvaluation xmlns="http://ottawa.byu.edu/Emar">
	<parameters>
		<PIN xsi:type="xsd:string">TESTPIN</PIN>
		<QuestionnaireName xsi:type="xsd:string">READY</QuestionnaireName>
	</parameters>
</StartEvaluation>
This is not according to the spec in the WSDL. Sending this literal text also generated the bug. The PIN and QuestionnaireName tags must be immediately descendants of the StartEvaluation tag, like this:
<StartEvaluation xmlns="http://ottawa.byu.edu/Emar">
	<PIN xsi:type="xsd:string">TESTPIN</PIN>
	<QuestionnaireName xsi:type="xsd:string">READY</QuestionnaireName>
</StartEvaluation>
This does actually achieve the desired result. I am not sure if I am interpreting the HREF-ID linking correctly. Please tell me whether I am correct or not on how the XML should be interpreted. If I am, then that seems to explain why the error is happening. I believe there are two solutions:
  1. You modify your client code so that it emits the XML compliant with this service.
  2. I write a SOAP filter that intercepts requests like the ones you are sending and refactors them so that the web service can understand it.
Option two may be longer than option 1 to implement, since I have my hands pretty full. I do know that ColdFusion and my WSDL2Java utility do just fine with the web service as is, so I would hope that there is just an attribute somewhere in your object that you can set to turn off the multiref thing.

Java client for an ASP.NET web service, part 1

Tried to get a Java client using webMethods to communicate with my .NET web service. I was not on the Java end. A 3rd party client was. We had an interoperability problem when the Java client sent the SOAP message:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body> 
        <StartEvaluation xmlns="http://ottawa.byu.edu/Emar"> 
            <parameters href="#id0"xmlns=""/> 
        </StartEvaluation>
        <multiRef id="id0"soapenc:root="0" soapenv:encodingStyle=""xsi:type="ns1:StartEvaluation"xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:ns1="http://ottawa.byu.edu/Emar">
            <PIN xsi:type="xsd:string">TESTPIN</PIN> 
           <QuestionnaireNamexsi:type="xsd:string">READY</QuestionnaireName>
        </multiRef> 
    </soapenv:Body>
</soapenv:Envelope>

The multiRef was not interpreted by the .NET web service the way the Java client was expecting, and the result was that none of the arguments actually got passed into the web method.

After researching on Google for a while, it appeared that using links with multiRef is a rather "advanced" topic and some implementors do not support it.

Still researching how to solve the problem. See future web blogs for solution (hopefully).

Friday, May 07, 2004

MasterPages in ASP.NET 1.x

Just discovered the MasterPages support for ASP.NET 1.x, thanks to Andy
with 4GuysFromRolla.  I haven't used it yet, but the reviews look
very good.  I think I can use it to replace my homespun
MasterPages code.  That could be nice.

Tuesday, May 04, 2004

WebMethods GLUE

WebMethods GLUE, which MSDN pushes as the tool of choice for Java to
work with WSE on the .NET level, appears to be incompatible with the
latest version of Microsoft's WSE toolkit.



I have successfully
signed and encrypted messages to and from a web service using .NET in
C#. The struggle remaining seems to be password validation and
encryption of username and password. Then of course getting these new
WSE extensions working on other platforms so that clients using other
languages and platforms can still call my newly protected web service.
What good is a web service that can't be accessed at all?