xsd:dateTime incompatibility between .Net and Apache Axis

[Lucvdv]

I have to connect to a server set up by the government, where they used
Apache Axis to create a webservice.

The code I use to interface to the webservice is generated by wsdl.exe,
based on a .wsdl file they sent me.


Now a problem turns up with a date field they implemented as xsd:dateTime,
even though it only contains a date.

The WSLD entry is:
<element name="birthDay" nillable="true" type="xsd:dateT ime"/>


The problem seems to be related to daylight saving time (whether DST was in
use or not on the date I'm passing to the service).

For about half of the dates (those in summer), everything is OK. The
actual string sent for 26 June 1978 for example, is[color=blue]
> <birthDay xsi:type="xsd:d ateTime">1978-06-26T00:00:00.000 0000+02:00</birthDay>[/color]
The server interprets it correctly.

With other dates, it goes wrong: for example[color=blue]
> <birthDay xsi:type="xsd:d ateTime">1955-04-14T00:00:00.000 0000+02:00</birthDay>[/color]
is interpreted by the service as one day earlier: April 13, 1955.

My time zone is actually GMT+01, but with DST it becomes +02, and that's
where I think the problem lies: the clock jumps back one day in
compensating for the time zone.

But how do I get rid of the +02:00 and send just the date?


I tried sending it as an "xsd:date", but the server doesn't accept it (HTTP
error "200 - Information not available").

As a temporary fix I'm just adding 12 hours to the dates before I send them
now, but I'd rather have the DST effect out completely.



BTW, my client app is a .Net Windows Forms application, but I had to resort
to a packet sniffer to see what it is actually sending and receiving.

Isn't there a way in the SOAP classes to get access to the raw XML that's
being transferred, so I can examine it in the debugger or log it to disk?
It would have saved me considerable time in diagnosing the problem if I'd
had that available from the start.


Related: if the server now returns an error code (such as the 200 above), I
have to wait until the connection times out before the proxy code returns.
If I had access to the raw response in some way, I could build in error
detection and return immediately. I've looked at what objects and
properties I can access when I use BeginGet and EndGet instead of getting
it synchronously, but I don't seem to find what I'm looking for.

[Lucvdv]

Re: xsd:dateTime incompatibility between .Net and Apache Axis

On Mon, 28 Nov 2005 15:07:23 +0100, Lucvdv <replace_name@n ull.net> wrote:
[color=blue]
> I tried sending it as an "xsd:date", but the server doesn't accept it (HTTP
> error "200 - Information not available").[/color]

Oops. That error was caused by something else - the server itself seems to
be down, I get the same error on its opening page.

I'll try again when it is back up.

[Lucvdv]

Re: xsd:dateTime incompatibility between .Net and Apache Axis

On Mon, 28 Nov 2005 15:20:22 +0100, Lucvdv <replace_name@n ull.net> wrote:
[color=blue]
> On Mon, 28 Nov 2005 15:07:23 +0100, Lucvdv <replace_name@n ull.net> wrote:
>[color=green]
> > I tried sending it as an "xsd:date", but the server doesn't accept it (HTTP
> > error "200 - Information not available").[/color]
>
> Oops. That error was caused by something else - the server itself seems to
> be down, I get the same error on its opening page.
>
> I'll try again when it is back up.[/color]

The server is back up, and it still doesn't work: it ignores the date if I
send it as xsd:date.


[The server takes identity details including birthdate, and returns whether
that person appears in a list. With xsd:date, it's as if the list is
empty.]

[DC]

Re: xsd:dateTime incompatibility between .Net and Apache Axis

Sounds like you are having an issue with XML namespaces.

Here is a working example of a C# client communicating with a Java/AXIS1.2
server, exchanging data of complex (custom) types. The complex type
includes an xsd:dateTime .

http://dinoch.dyndns.org:7070/axis1.2/AboutCtService.jsp

One of the fundamental things you should do in order to get interop to
happen between Java/AXIS (in fact any Java web services stack) and .NET is
to take the "WSDL first" approach. This means define your interface between
client and server in WSDL, and then generate from that WSDL server-side
skeletons and client-side stubs, whether Java is the server and .NET is the
client, or vice versa.

If you start with an implementation, lets say a Java class and then just pop
that up as a webservice (AXIS has some nifty support for a .jws thing that
allows all public methods to be exposed as webservice methods), you will
have some difficulty getting interop to happen. Sure it is possiblre to
do a demo, but in more complex scenarios, you'll have trouble.

See also, this page:

http://wiki.apache.org/ws/FrontPage/Axis/DotNetInterop

--
-Dino
D i n o . C h i e s a AT M i c r o s o f t . c o m



"Lucvdv" <replace_name@n ull.net> wrote in message
news:lh1oo15gac oerv2f6a0mtlhmc kvk9hrp0s@4ax.c om...[color=blue]
> On Mon, 28 Nov 2005 15:20:22 +0100, Lucvdv <replace_name@n ull.net> wrote:
>[color=green]
>> On Mon, 28 Nov 2005 15:07:23 +0100, Lucvdv <replace_name@n ull.net> wrote:
>>[color=darkred]
>> > I tried sending it as an "xsd:date", but the server doesn't accept it
>> > (HTTP
>> > error "200 - Information not available").[/color]
>>
>> Oops. That error was caused by something else - the server itself seems
>> to
>> be down, I get the same error on its opening page.
>>
>> I'll try again when it is back up.[/color]
>
> The server is back up, and it still doesn't work: it ignores the date if I
> send it as xsd:date.
>
>
> [The server takes identity details including birthdate, and returns
> whether
> that person appears in a list. With xsd:date, it's as if the list is
> empty.][/color]

[Lucvdv]

Re: xsd:dateTime incompatibility between .Net and Apache Axis

On Wed, 30 Nov 2005 17:21:35 -0500, "DC" <dinoch@online. microsoft.com>
wrote:
[color=blue]
> One of the fundamental things you should do in order to get interop to
> happen between Java/AXIS (in fact any Java web services stack) and .NET is
> to take the "WSDL first" approach. This means define your interface between
> client and server in WSDL, and then generate from that WSDL server-side
> skeletons and client-side stubs, whether Java is the server and .NET is the
> client, or vice versa.[/color]

That's how it was done, at least on my side: the WSDL was generated by
Axis, I ran it through wsdl.exe to create a proxy class.

This lead to the problem with timezone/DST: the webservice (Axis)
interprets half of the dates I send it as one day earlier than I sent it.

The only change I applied (manually) to the proxy is that I added
authentication, because the server requires that.


The problem is that I don't have any control over the webservice (server
side). A third party created it for a government agency, and it's
considered finished (and being accessed by several others as well, so any
change might lead to problems there).

So I think I'll have to stick to my patchwork solution of setting the time
of day to 12:00 (noon) in each date, instead of letting it default to
midnight.



BTW, when I added authentication, I set PreAuthenticate to True. Yet by
sniffing the network packets I see that my client still sends its full
request without authenticating first, which fails, and then it re-sends the
same request with authentication.
Do you happen to know if anything can be done about that?


This is the original constructor of the proxy, as wsdl.exe made it:

Public Sub New()
MyBase.New()
Me.Url = "http://www...(snipped)
End Sub

This is my version (no other changes made anywhere):

Public Sub New(ByVal User As String, ByVal Pass As String)
MyBase.New()
Me.Credentials = New System.Net.Netw orkCredential(U ser, Pass)
Me.PreAuthentic ate = True
Me.Timeout = 30000 ' 30 seconds instead of default of 100
Me.Url = "http://www...(snipped)
End Sub