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

3678RE: [soapbuilders] usage of custom classes in requests

Expand Messages
  • James Snell
    Jun 5, 2001
    • 0 Attachment
      To expand on this point, XML Schemas that are published for Web Services
      should very well be immutable. Especially considering the fact that
      many applications may be built around that schema. Case in point, look
      at what happened with RSS feeds around the world when Yahoo dumped the
      RSS DTD. Since so many people were using that DTD to validate against,
      there were some big problems.

      - James

      -----Original Message-----
      From: Andrew Layman [mailto:yahoo@...]
      Sent: Tuesday, June 05, 2001 9:43 PM
      To: soapbuilders@yahoogroups.com
      Subject: Re: [soapbuilders] usage of custom classes in requests


      Your comparison to COM interfaces is accurate, and in the main, I agree
      with you. However, XML and Web Services can be a bit more flexible. If
      the fields in a message are optional, meaning that they can be safely
      ignored, then you can just add them. Similarly, if a service can accept
      new messages but this does not require refusing older messages, then
      they can just be added. Finally, the SOAP model of messages as being
      composed of a loose confederation of strongly-typed parts, marked using
      the mustUnderstand attribute, allows more flexibility.

      It is plainly impossible on the scale of the Web to get all senders and
      receivers updated simultaneously to matching versions of software, so
      receivers will need to be ready to receive messages from out-of-date
      senders.

      ----- Original Message -----
      From: "Simon Fell" <soap@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Tuesday, June 05, 2001 9:00 PM
      Subject: Re: [soapbuilders] usage of custom classes in requests


      I don't see any alternatives but to version SOAP based interfaces in
      much the way that COM interfaces are versioned.

      Cheers
      Simon

      On Tue, 5 Jun 2001 20:33:26 -0700, in soap you wrote:

      >I think it is better to plan your application with the idea that the
      message
      >formats on the wire are what matter. The API used to create them may
      >vary, but as long as you can create the right messages, you can
      >interoperate.
      >
      >I encourage people to define their messages using XML schemas and their

      >services using WSDL. This just says what the messages must be and
      >avoids the APIs. Schemas also have the ability to allow extensible
      >content using the <anyElement> particle.
      >
      >That said, of course your applications will evolve over time. It is
      >likely that your server will need to accept and respond to older-style
      >messages
      for
      >quite a while after you have added support for newer ones.
      >
      >
      >
      >----- Original Message -----
      >From: "Ed Keen" <edk@...>
      >To: <soapbuilders@yahoogroups.com>
      >Sent: Tuesday, June 05, 2001 8:46 AM
      >Subject: RE: [soapbuilders] usage of custom classes in requests
      >
      >
      >Andrew, you make a good point. It is a given, though, that anyone's
      >business model will grow and change, and we must account for that
      >eventuality. The question is, how do you deal with that change? When
      >a
      new
      >required field is added, the client-side developers will have to make
      >changes to their code no matter what (and there is no way around that).
      The
      >question is, do you then force them to also download a new version of
      >your api library with each change? That is what I am trying to avoid.
      >
      >
      >-----Original Message-----
      >From: Andrew Layman [mailto:yahoo@...]
      >Sent: Tuesday, June 05, 2001 10:39 AM
      >To: soapbuilders@yahoogroups.com
      >Subject: Re: [soapbuilders] usage of custom classes in requests
      >
      >
      >Ed asks about custom classes, saying "So, whenever the interface for
      >these classes changes (say we add a new required field), we would have
      >to redistribute the client classes. This could become a distribution
      >nightmare."
      >
      >The problem is real, but it is not the fault of custom classes. It
      >comes about because you say that the new field is required. If it
      >truly is, then the client will not know what to do with the field,
      >custom or not.
      >
      >This is why SOAP and schemas make such a big deal about required vs.
      >optional.
      >
      >
      >----- Original Message -----
      >From: "Ed Keen" <edk@...>
      >To: <soap-user@...>
      >Cc: <soapbuilders@yahoogroups.com>
      >Sent: Tuesday, June 05, 2001 7:41 AM
      >Subject: [soapbuilders] usage of custom classes in requests
      >
      >
      >I would like feedback on the whether or not any of you are using custom

      >classes in your soap calls. While it is definitely convenient on the
      Apache
      >server side (with its serializers & deserializers), it places an extra
      >burden on the client, because now they must have these custom classes
      >on their side too. For win32 clients, this becomes an even more
      >difficult task. Our company would probably wind up writing a DLL that
      >would contain the analog of our custom classes for Windows. So,
      >whenever the interface for these classes changes (say we add a new
      >required field), we would have to redistribute the client classes.
      >This could become a distribution nightmare.
      >
      >I am wondering if it would be less trouble to just have the clients
      >send
      all
      >their data as separate parameters (which could make for a long
      >parameter list, I know) to some proxy-type servlet on the server-side
      >which would intercept the soap call, package that data into our custom
      >classes, and
      send
      >the request on its way. It's more work on the server-side, but it
      >would avoid the need to distribute these custom serailizable client
      >classes.
      >
      >Does any of that make sense? What are the rest of you doing in regards

      >to this? Please don't tell me to use WSDL. Been there. Tried that.
      >
      >Thanks,
      >Ed
      >
      >
      >To unsubscribe from this group, send an email to:
      >soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      >Your use of Yahoo! Groups is subject to
      >http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      >To unsubscribe from this group, send an email to:
      >soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      >Your use of Yahoo! Groups is subject to
      >http://docs.yahoo.com/info/terms/
      >
      >
      >To unsubscribe from this group, send an email to:
      >soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      >Your use of Yahoo! Groups is subject to
      >http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      >To unsubscribe from this group, send an email to:
      >soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      >Your use of Yahoo! Groups is subject to
      >http://docs.yahoo.com/info/terms/
      >


      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/




      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • Show all 7 messages in this topic