There's a debate going on about programming approaches to Web Services that allow them to be extensible and not brittle. There's one solution that I whole heartedly support. "Use named params. Ignore parameters you don't recognise. Default parameters that are not passed". This is what we did with CGI and in that environment it just works. It allows WS developers to add extra parameters to server code later without breaking existing clients. It allows servers to drop parameters when they're no longer needed. It allows clients to call the WS when they don't have all the data required. 

But unfortunately several server toolkit implementations break if a full set of parameters are not supplied. And it forces a particular style of encoding in XML-RPC that is supported but isn't obvious in the spec. There seems to be a mindset here that equates WS programming with local object programming in compiled languages. It may even be inherent in the "Obect Access" initials part of SOAP. Dynamic Scripting languages like PHP and perl have understood this for years.

If you hard code the WS call as a fixed list of required parameters and break when they're not all there or an extra one is present, you're storing up problems for the future.

---

[ << Viridian Note 00309: CFP 2002 Speech ] [ Sven's Squad >> ]
[ 22-Apr-02 7:49am ] [ G ] [ # ]