OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[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]