[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] In support of simplifying WSRM Policy
Yes, agreed! All the best, Ashok > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Thursday, January 12, 2006 6:32 AM > To: ashok.malhotra@oracle.com > Cc: wsrx > Subject: Re: [ws-rx] In support of simplifying WSRM Policy > > Ashok > > That is the customer scenario. I'm not arguing for removing > policy - I think the single assertion that RM is required or > optional is highly valuable. However, by removing > MaxMessageNum, and making AckInterval a part of the > CreateSequenceResponse, we simplify the policy - making it > simpler for the cases where policy is not used. > > Paul > > Ashok Malhotra wrote: > > There is one scenario, though, in which no WS-RX policy is needed. > > This is where a number of services are covered by a > corporate policy > > that says all messages are or are not RM. Perhaps this was the > > situation with your customer. > > > > All the best, Ashok > > > > > > > >> -----Original Message----- > >> From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] > >> Sent: Thursday, January 12, 2006 6:00 AM > >> To: Paul Fremantle; wsrx > >> Subject: RE: [ws-rx] In support of simplifying WSRM Policy > >> > >> Paul: > >> I'm all for simplification but I have a couple of questions of > >> clarification. > >> > >> If I'm considering using a Web Service I look at its WSDL. > >> This tells me the message structures but does not tell me > whether any > >> of the messages need to use a reliable protocol. > >> If some/all the messages need a RM protocol we need to be > able to say > >> this somehow. > >> > >> We also need to be able to say which or all messages need the > >> protocol so we need some attachment options. > >> > >> All the best, Ashok > >> > >> > >> > >>> -----Original Message----- > >>> From: Paul Fremantle [mailto:paul@wso2.com] > >>> Sent: Thursday, January 12, 2006 2:33 AM > >>> To: wsrx > >>> Subject: [ws-rx] In support of simplifying WSRM Policy > >>> > >>> Yesterday I visited a large financial institution (a > customer of a > >>> number of our member's companies) who is looking seriously > >>> > >> at WSRM as > >> > >>> a major part of their infrastructure. > >>> > >>> They made some pertinent comments, based on trying three > >>> > >> different RM > >> > >>> implementations from various of the organisations > >>> > >> represented in our > >> > >>> TC. > >>> > >>> Interoperability is their biggest issue. The biggest > problems they > >>> have had today come from WS-Policy attachment. Different > >>> > >> vendors have > >> > >>> chosen to put the WSRMP in different places, and this > caused them a > >>> number of headaches. When I pointed out this was an easy > >>> > >> thing for us > >> > >>> to fix, I got the reply that they have no need for > policy. They are > >>> using WSRM in fixed patterns inside there organisation, and they > >>> suggested (unprompted I might add) that they would like an > >>> > >> effective > >> > >>> model of using WSRM without policy. I believe this backs up the > >>> proposals I have made for simplifying WSRM Policy. > >>> > >>> They also made a request that when doing interoperability > >>> > >> testing we > >> > >>> not only publish the results, but also some details of the > >>> > >> codebases > >> > >>> that were used. They have concerns that some > interoperability tests > >>> have been effected using different codebases than are then > >>> > >> offered to > >> > >>> the marketplace. > >>> > >>> Regards, Paul > >>> > >>> -- > >>> > >>> Paul Fremantle > >>> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > >>> > >>> http://bloglines.com/blog/paulfremantle > >>> paul@wso2.com > >>> > >>> "Oxygenating the Web Service Platform", www.wso2.com > >>> > >>> > >>> > >>> > >> > >> > > > > > > -- > > Paul Fremantle > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > http://bloglines.com/blog/paulfremantle > paul@wso2.com > > "Oxygenating the Web Service Platform", www.wso2.com > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]