Hi Chris What you've explained makes a complete sense to me, sorry for misunderstanding your earlier comment. Here's a couple of comments. On option 1: it would seem right to reject the request if it's not MTOMed, because it's stated to be required...
Thanks, Sergey ----- Original Message ----- From: "Christopher Moesel" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, April 25, 2007 6:44 PM Subject: RE: Questions While Implementing MTOM Policy Hi Sergey, I did not intend for wsp:Optional to mean that the service could choose not to support MTOM requests. What I meant was that wsp:Optional means the service can support both MTOM and non-MTOM requests and respond in the likewise manner (MTOM or non-MTOM). As service provider I have three choices in regards to MTOM support: 1) Require MTOM requests/responses 2) Make MTOM requests/responses optional 3) Don't support MTOM at all I need to differentiate between the first two, because the server response differs between them if a non-MTOM request is received: 1) If MTOM is required, then either reject the non-MTOM request completely, or accept it and respond with MTOM anyway (not sure which is appropriate, but the key is that if a response is sent, it is MTOM) 2) If MTOM is optional, then accept the non-MTOM request and respond with a non-MTOM request. Some service providers will want #2 because it enhances interoperability (non-MTOM clients can still use the service) but also allows for more efficient MTOM transmissions where possible. Some service providers will want #1 because #2 may make their service more vulnerable. For instance, a service that allows clients to send base64Binary data in their requests may not allow non-MTOM requests, since they would be inlined (not streaming), and could cause out-of-memory errors. So, that's why I think it's important to be able to honor the wsp:Optional attribute on the server side as well... That being said, the solution Dan helped me with asserts the MTOM assertion if the request is MTOM-enabled and doesn't assert it otherwise. If the MTOM assertion does not get asserted, then the framework chooses whether or not to throw an exception based on whether or not the policy is optional... To be 100% honest, I don't fully understand all of this stuff myself, but hopefully what I just said makes sense... -Chris -----Original Message----- From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 1:25 PM To: [email protected]; Dan Diephouse Subject: Re: Questions While Implementing MTOM Policy Hi Chris I've seen the merge email, this is great. I don't understand your comment about being unable to determine if the assertion was optional or not...Can you please explain why do you need to know it ? Specifically, how the service with the optional MTOM assertion can serve both MTOMed and not-MTOMed requests ? I was trying to highlight eartlier that wsp:optional is targeted at the client, not at the service provider... wsp:optional can not indicate to the service that it may choose not to support MTOMed requests. If CXF did it that way then it would not pass the WS-Policy interoperabilty.... Thanks, Sergey ----- Original Message ----- From: "Christopher Moesel" <[EMAIL PROTECTED]> To: <[email protected]>; "Dan Diephouse" <[EMAIL PROTECTED]> Sent: Monday, April 23, 2007 7:24 PM Subject: RE: Questions While Implementing MTOM Policy JIRA Issue w/ partially working patch for WS-MTOMPolicy support on the server side: https://issues.apache.org/jira/browse/CXF-593 As noted before, the broken part has to do with my inability to determine if the assertion is optional from within the interceptor. -Chris -----Original Message----- From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 1:52 PM To: Dan Diephouse; [email protected] Subject: Re: Questions While Implementing MTOM Policy Hi Dan > on the Client side, its all or nothing. I'm not sure what you mean. If the service's WSDL has an MTOM assertion attached, then : * if the assertion is not optional then the client-side interceptor knows it has to do MTOM, because this is what the service requires * if the assertion is optional then this interceptor can do some reasoning on whether to do MTOM or not... You're saying that it's not possible to do it at the moment, which is not a big problem per se, it's just limits the scope of what the client can do. In this case, one option is to configuire the client side explicitly to do MTOM if the service has the optional MTOM assertion. But this option (configuring the client) is not really required because this will make "MTOM always". On the client side one still can avoid the configuration (assuming the client runtime is policy aware) by just updating the MTOM handler to always do MTOM when it sees the service's MTOM assertion, whether it's optional or not. I'm also thinking that perhaps a custom version of the DataHandlers or JAXB marchallers can be provided to let the MTOM handler to do some reasoning when seeing am optional MTOM assertion, what do you reckon ? Cheers, Sergey ----- Original Message ----- From: Dan Diephouse To: [email protected] Cc: Sergey Beryozkin Sent: Monday, April 23, 2007 3:54 PM Subject: Re: Questions While Implementing MTOM Policy On 4/23/07, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: By the way, the issue Chris is trying to solve (finding out if the MTOM policy expression was set as optional or not) is the real issue for the client runtime. MTOM interceptor on the client side can check if it's required, if yes, then use MTOM, if not, then consider whether to use it or not anyway by checking the size of the outgoing message against the default or preconfigured value, etc... This is will be a no client configuration story (for MTOM)... Its not possible to check the size of the outgoing message or even just the attachment. The DataHandler API doesn't expose it (and nor does the JAXB AttachmentMarhsaller APIs), so on the Client side, its all or nothing. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
