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

3676Re: [soapbuilders] usage of custom classes in requests

Expand Messages
  • Simon Fell
    Jun 5, 2001
    • 0 Attachment
      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/
      >
    • Show all 7 messages in this topic