Re: [soapbuilders] Re: origin of interoperability problems?
- Bingo! Give that man a ceeegar.
STSM, Emerging e-business Industry Architecture
phone: +1 508 377 9295
email@example.com wrote on 05/09/2005 10:47:11 AM:
> >I didn't say that it would be hard. Just not practical. The world isimplementation and
> >not pure java... there's still a gazillion lines of COBOL running
> >(even some that I wrote back in the stone ages:-). What's a hashmap
> >to COBOL?
> While I also think defining hashmaps compatibly across languages is
> difficult (does CORBA do it?), I think this discussion is missing the
> real difficulty of interoperability. It's not that it's hard to pass
> hash tables from Java to COBOL. It's that it's still hard to pass
> integers from Java to .NET. Or arrays of structures from Java to Perl.
> The more I get into trying to build interoperable web services, the
> more I think the whole XML->native type binding approach is just
> fundamentally broken. I can't see any theoretical reason it shouldn't
> work, but the practical outcome is so bad it makes me think something
> must be wrong with the idea.
> People say the best way to build interoperable web services is focus
> on the XML documents. I'm increasingly thinking that's the only way to
> do things. Alas, what that means in most languages is you treat your
> SOAP packets like XML documents and slog through them with DOM or the
> like. I fear that in many languages you're better off without the
> fancy SOAP/WSDL toolkits entirely.
> If we're reduced to parsing XML documents, all SOAP+WSDL has
> accomplished is the soap:Header tag. That's not so exciting.
> This group is a forum for builders of SOAP implementations to discuss
> interoperability issues. Please stay on-topic.
> Yahoo! Groups Links
> To visit your group on the web, go to:
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
- --- In firstname.lastname@example.org, 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.