Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Re: origin of interoperability problems?

Expand Messages
  • Christopher B Ferris
    My point of view was that by doing the WSDL-first approach the service ... Right. But, the reason we are doing Web services is to achieve interoperability.
    Message 1 of 62 , May 9, 2005
    • 0 Attachment
      "> My point of view was that by doing the WSDL-first approach the service
      > implementation (whatever is java, .net..) cannot take advantage of the
      > language capabilities."

      Right. But, the reason we are doing Web services is to achieve
      interoperability. There are many
      types in Java that don't have corollaries in COBOL. There are C# types
      that don't exist in Java. The
      list goes on and on. Yet, we have implemented XML parsers on just about
      every platform and in
      every language imaginable.

      If you want to exchange hashmaps between java implementations, you can use
      JRMP for that.
      Just don't expect to have interoperability with C#:-)

      Cheers,

      Christopher Ferris
      STSM, Emerging e-business Industry Architecture
      email: chrisfer@...
      blog: http://webpages.charter.net/chrisfer/blog.html
      phone: +1 508 377 9295

      soapbuilders@yahoogroups.com wrote on 05/07/2005 06:35:21 PM:

      > --- In soapbuilders@yahoogroups.com, Rich Salz <rsalz@d...> wrote:
      > > > If I am a Java programmer that wants to create a service that
      > sends say,
      > > > a hashmap, by using WSDL-first I would define somehow a XSD type
      > > > (something like a list of key-value pairs), but then the toolkit
      will
      > > > not generate the hashmap type, so I would have to program the
      hashmap
      > > > behaviour myself. Isn't this an inconvenience? As a programmer, I
      > would
      > > > prefer to use predefined types.
      > >
      > > Not all languages have hashmaps, and not all hashmaps are the same
      > > (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.
      > >
      > > But if you don't care about non-Java, why not just use RMI?
      >
      >
      > My point of view was that by doing the WSDL-first approach the service
      > implementation (whatever is java, .net..) cannot take advantage of the
      > language capabilities. This means that you are going to get a map of
      > the XSD defined types: arrays, lists, etc, but not a mapping of more
      > complex structures like trees (unless you do the parsing yourself
      > using DOM as it was said before). But if your language supports graph
      > types, IMHO you can't take advantage of that using WSDL-first.
      >
      > Regards,
      >
      > -Enric
      >
      >
      >
      >
      >
      > >
      > > /r$
      > >
      > > --
      > > Rich Salz Chief Security Architect
      > > DataPower Technology http://www.datapower.com
      > > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss
      implementation and
      > interoperability issues. Please stay on-topic.
      >
      >
      > Yahoo! Groups Links
      > To visit your group on the web, go to:
      > http://groups.yahoo.com/group/soapbuilders/
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Steve Loughran
      ... 1. .net1.1 time assumes that times are in local tz, so if your service is working w/ GMT zones then you only get interop problems in the GMT locations. 2.
      Message 62 of 62 , Jul 5, 2005
      • 0 Attachment
        --- In soapbuilders@yahoogroups.com, Simon Fell <ws@z...> wrote:
        > >I've never personally had a dateTime problem, which in retrospect
        > >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).
        >

        1. .net1.1 time assumes that times are in local tz, so if your service
        is working w/ GMT zones then you only get interop problems in the GMT
        locations.

        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.

        -steve
      Your message has been successfully submitted and would be delivered to recipients shortly.