RE: [soapbuilders] Re: origin of interoperability problems?
- Rich, et al
> Not all languages have hashmaps, and not all hashmaps are the sameAbout a year ago, pushed by code-heads within BT,
> (e.g., C++ STL vs Java). If you don't care about non-Java languages,
> then you don't need the interop provided by WSDL-first.
i made a proposal for expressing some common schema constructs
to assist round-tripping of some simple data structures for inclusion
in the WSDL 2.0 primer:
Following recent discussion in the WSDL WG, i'm currently trying to
represent this in the form of a W3C 'note', which may or may
not be published by the WSDL Working Group. It's no longer
likely to be in the Primer as it's more of specification than introductory
If this went anyway towards us having a common approach for representing
a 'hash', i'd be best pleased, though realise if it was simply as I outline, it
would have happend sometime ago during the prime of soapbuilding.
Any input folks may have on this initiative will be greatefully received.
> But if you don't care about non-Java, why not just use RMI?In my experience RMI isn't that interoperable between different vendors
and even in one notable case, between two versions of application server
produced by a single vendor. i kid you not.
- --- In email@example.com, Simon Fell <ws@z...> wrote:
> >I've never personally had a dateTime problem, which in retrospect1. .net1.1 time assumes that times are in local tz, so if your service
> >surprises me. Our users have a lot of confusion about timezones, but
> >the interop is actually working the way it is supposed to.
> Steve Loughran has written a number of times about problems with
> dateTime, i've never fully understood the issue he talks about,
> although lots of users get confused over timezones, and whether there
> toolkit works with UTC or local times (as most platforms DateTime
> datatype typically doesn't retain TZ info).
is working w/ GMT zones then you only get interop problems in the GMT
2. Axis self tests were failing for me in the GMT0BST tz; nobody else
could see it. wierd.
3. I had an axis1.1 client/server where stuff was coming in a hour out
on 127.0.0.1 based communications.
Now, this is all in the past. Things may be fixed. Using time_t fixes
things for me too mostly, though you have other problems there (leap
seconds, the effect of the moon on the oceans, etc, etc). Try it and
see. But remember to test not just in different systems, but in boxes
(or at least virtual boxes) in different zones and locales.