From a testing perspective, it's sounding like we'll be adding a de facto

I'd like to reboot the discussion around SOAP support in apiman. Originally I was thinking we could implement it without parsing the full message. I even have some code for doing this. However, after thinking about it some more (and after some discussion about soapaction vs. resource path in a separate jira) I'm thinking we simply have an option that will parse the entire soap message upfront *as an option*. I'd like any opinions anyone might have on this matter. :) The idea would be to handle the soap message in a java-standard fashion (jax-ws, javax.xml.soap, SAAJ, etc). The resulting soap message would be available to policies as part of the policy context, and it could be processed however the policy wants. When proxying to the back-end, the (possibly modified) soap message will be serialized to a string and written to the back-end API. Thoughts? Question for @Keith primarily: do you have any advice/code that efficiently parses a soap message? And is there someone you've worked with that has a lot of SOAP experience who could perhaps chime in some expertise? -Eric

Correct on both counts. On 4/22/2016 2:30 PM, Leonard Dimaggio wrote: > So, from a user's perspective, all they have to do to enable SOAP is > click a checkbox? > > From a testing perspective, it's sounding like we'll be adding a de > facto SOAP pre-processor, and that the policy-related code will not be > changing? > > > Thanks!, > Len > > > > On Thu, Apr 21, 2016 at 12:16 PM, Eric Wittmann > <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> wrote: > > I'd like to reboot the discussion around SOAP support in apiman. > Originally I was thinking we could implement it without parsing the > full message. I even have some code for doing this. > > However, after thinking about it some more (and after some > discussion about soapaction vs. resource path in a separate jira) > I'm thinking we simply have an option that will parse the entire > soap message upfront *as an option*. > > I'd like any opinions anyone might have on this matter. :) The > idea would be to handle the soap message in a java-standard fashion > (jax-ws, javax.xml.soap, SAAJ, etc). The resulting soap message > would be available to policies as part of the policy context, and it > could be processed however the policy wants. > > When proxying to the back-end, the (possibly modified) soap message > will be serialized to a string and written to the back-end API. > > Thoughts? > > Question for @Keith primarily: do you have any advice/code that > efficiently parses a soap message? And is there someone you've > worked with that has a lot of SOAP experience who could perhaps > chime in some expertise? > > -Eric > > > > > -- > Len DiMaggio (ldimaggi(a)redhat.com <mailto:ldimaggi@redhat.com>) > JBoss by Red Hat > 314 Littleton Road > Westford, MA 01886 USA > tel: 978.392.3179 > cell: 781.472.9912 > http://www.redhat.com > http://community.jboss.org/people/ldimaggio > > >

> On Apr 21, 2016, at 12:16 PM, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: > > I'd like to reboot the discussion around SOAP support in apiman. Originally I was thinking we could implement it without parsing the full message. I even have some code for doing this. > > However, after thinking about it some more (and after some discussion about soapaction vs. resource path in a separate jira) I'm thinking we simply have an option that will parse the entire soap message upfront *as an option*. > > I'd like any opinions anyone might have on this matter. :) The idea would be to handle the soap message in a java-standard fashion (jax-ws, javax.xml.soap, SAAJ, etc). The resulting soap message would be available to policies as part of the policy context, and it could be processed however the policy wants. > > When proxying to the back-end, the (possibly modified) soap message will be serialized to a string and written to the back-end API. > > Thoughts? This seems like a pragmatic first step to me. The SAAJ object model is DOM-backed, so this approach would give users a lot of flexibility in processing the message. > > Question for @Keith primarily: do you have any advice/code that efficiently parses a soap message? And is there someone you've worked with that has a lot of SOAP experience who could perhaps chime in some expertise? I would talk to Alessio on the JBoss WS team - I expect they have done quite a bit of performance tuning over the years for EAP. regards, keith > > -Eric

That all happens in CXF before it gets to SY. I worked with SAAJ quite a bit back in my Sun days, looks like the basic factory methods are still around: https://docs.oracle.com/javase/7/docs/api/javax/xml/soap/MessageFactory.html You can pass in a stream and the HTTP headers to create a new SOAPMessage instance. cheers, keith > On Apr 28, 2016, at 10:46 AM, Eric Wittmann <eric.wittmann(a)redhat.com > <mailto:eric.wittmann@redhat.com>> wrote: > > Thanks Keith - I'll ping Alessio. In the meantime, any chance > SwitchYard has some basic support for parsing a soap message using saaj? > > -Eric > > On 4/28/2016 9:22 AM, Keith Babo wrote: >> >>> On Apr 21, 2016, at 12:16 PM, Eric Wittmann >>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> wrote: >>> >>> I'd like to reboot the discussion around SOAP support in apiman. >>> Originally I was thinking we could implement it without parsing the >>> full message. I even have some code for doing this. >>> >>> However, after thinking about it some more (and after some >>> discussion about soapaction vs. resource path in a separate jira) >>> I'm thinking we simply have an option that will parse the entire >>> soap message upfront *as an option*. >>> >>> I'd like any opinions anyone might have on this matter. :) The >>> idea would be to handle the soap message in a java-standard fashion >>> (jax-ws, javax.xml.soap, SAAJ, etc). The resulting soap message >>> would be available to policies as part of the policy context, and it >>> could be processed however the policy wants. >>> >>> When proxying to the back-end, the (possibly modified) soap message >>> will be serialized to a string and written to the back-end API. >>> >>> Thoughts? >> >> This seems like a pragmatic first step to me. The SAAJ object model >> is DOM-backed, so this approach would give users a lot of flexibility >> in processing the message. >> >>> >>> Question for @Keith primarily: do you have any advice/code that >>> efficiently parses a soap message? And is there someone you've >>> worked with that has a lot of SOAP experience who could perhaps >>> chime in some expertise? >> >> I would talk to Alessio on the JBoss WS team - I expect they have >> done quite a bit of performance tuning over the years for EAP. >> >> regards, >> keith >> >>> >>> -Eric >>