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

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

Expand Messages
  • Anne Thomas Manes
    ... The impedance mismatch is between the XSD types (hierarchies) and OO language types (rich object graphs), regardless of the abilities of the current
    Message 1 of 62 , May 6, 2005
    • 0 Attachment
      I'm not sure your original casting of the problem is quite accurate:

      > although XSD is very powerful for describing type semantics,
      > current toolkits don't support all the constructs and this produces
      > impedance mismatches.

      The impedance mismatch is between the XSD types (hierarchies) and OO
      language types (rich object graphs), regardless of the abilities of
      the current toolkits -- the type systems are fundamentally different.
      I actually think that the major interoperability issues are caused
      from the other direction -- current toolkits aren't very good at
      mapping rich object graphs to hierarchical structures. Many toolkits
      attempt to treat SOAP/WSDL as just another distributed object system
      (similar to CORBA, RMI, and DCOM). The toolkits focus on generating
      XSD definitions from code -- and lots of developers try to expose
      language-specific object types (Java hashmaps, .NET Datasets, etc)
      through their SOAP interfaces. This approach often results in
      interoperability challenges.

      If developers start with WSDL descriptions and XSD types and generate
      code from them, the interop issues are definitely lessened. And if the
      toolkit doesn't support a specific XSD construct, the toolkit can
      always resort to DOM.

      Anne

      On 5/6/05, Rich Salz <rsalz@...> wrote:
      > > But therefore I wonder: given the importance that XSD bindings have
      > > for interoperability, how is that the WS-I BP doesn't put any limit
      > > into the XSD constructs?
      >
      > It's being considered. Some problems are that the resulting subset
      > might be useless and the WG would get mired down in political debates
      > (just like with the original schema WG). It might be simpler just to
      > encourage everyone to implement what was already agreed-to, the W3C spec.
      >
      > /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
      >
      >
      >
      >
      >
    • 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.