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

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

Expand Messages
  • Enric Jaen
    ... Thinking about the WSDL-first approach, I get to this reasoning: If I am a Java programmer that wants to create a service that sends say, a hashmap, by
    Message 1 of 62 , May 7, 2005
    • 0 Attachment
      > >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
      > >
      > >
      > >
      > You are absolutely correct. I call them R3AWs (Retarded 3GL API
      > Wrappers). The tight binding between WSDL and 3GL API makes some
      > toolkits very easy to make a POJO into a Web service, but you pay as
      > soon as the POJO changes.
      >
      > There needs to be an abstraction, aka service contract (called service
      > signature in webMethods Integration Server) which keeps the generated
      > WSDL from actually caring about the implementation. This is more work up
      > front, but forces one to focus on the question "What should my public
      > API be?" and "What API do I want to commit to providing SLAs for?",
      > which is exactly what will happen as we evolve to "WSDL First"
      > implementations.


      Thinking about the WSDL-first approach, I get to this reasoning:
      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.


      Regards,
      -Enric
    • 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.