[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Usage of Ref parms for WS-Reliable Messaging
> -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Thursday, Oct 05, 2006 2:55 PM > To: Anish Karmarkar > Cc: Marc Goodner; tom@coastin.com; wsrx > Subject: Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging > > Anish > > Firstly there is a general point, which is that good design is design > that meets the design brief and no more. We all know that > solutions that > go well beyond the design brief tend to have problems. I > would hazard a > guess that at least 50% of security problems come from > building in too > much richness. Interoperability is another key issue. If you look at > what WS-I did with WSDL it was specifically addressing the fact that > there was too much richness in the original WSDL > specification which led > to massive non-interop. It is interesting that you bring WSDL 1.0 up. I tend to disagree that the example applies here, on the contrary. It was not really the richness but rather the ambiquity the WS-I was trying to address. If you look at certain problems with the original WSDL, such as the extensibility, I would point out the reverse is true. The fixed up WSDL with WS-I has a better and richer definition for extensibility. To this date, there is debate about where the extensibility points are and original WSDL hinders the utility of extensibility for so many other specs that depend on it. As a result, there is the element vs attribute version that you end up targeting with extensions and it becomes a mess. In essence I can argue it is the replication of similar functionality and being too narrow in your definition gets you into trouble. I do wonder the same applies to the bundle of arguments about keeping makeConnection too narrowly scoped... <snip/> --umit
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]