Folks,
Perhaps there is a need to fix the spec in this regard. Saying nothing about exceptions/faults is
not good, since the implied looseness means that different runtime vendors could choose alternative
approaches with nasty effects for end user applications.
Any suggestions for what the spec SHOULD say about exception handling for the
JMS Binding?
Yours, Mike.
ant elder wrote:
But that spec extract says nothing about how to handle exceptions, the
key bit being line 227 which explicitly leaves this out, as does the
current OASIS versions of the spec. I did ask the spec guys about this
once a while back (not on any mailing list so I can't provide a link)
the answer was that as JMS doesn't have any standard definition of fault
messages so the SCA JMS spec doesn't define anything here either and how
to handle this is SCA runtime specific. (as a slight aside, line 227
already makes the JMS spec inconsistent with JAXWS as a return value is
unwrapped XML not wrapped, not sure our current wireformat is doing that
correctly). I'm missing the reason this could be considered a
"backdoor", its not like doing this would open up any vulnerabilities
that i can see so a backdoor to where?
Anyway, what to do for 1.4? We did support non-JAXWS exceptions in
previous releases so wouldn't it be better to continue doing that in 1.x
and perhaps if we really do want to change this then to do it only in 2.x?
...ant
On Wed, Jan 7, 2009 at 9:14 PM, Raymond Feng <[email protected]
<mailto:[email protected]>> wrote:
IMO, the wire format controls how business data and/or fault are
represented in the JMSMessage. The following is quoted from the OSOA
JMS binding spec 1.0:
217 1.5.2 Default Data Binding
218 The default data binding behavior maps between a JMSMessage and
the object(s) expected by
219 the component implementation. We encourage component
implementers to avoid exposure of
220 JMS APIs to component implementations, however in the case of an
existing implementation that
221 expects a JMSMessage, this provides for simple reuse of that as
an SCA component.
222 The message body is mapped to the parameters or return value of
the target operation as
223 follows:
224 . If there is a single parameter or return value that is a
JMSMessage, then the JMSMessage is
225 passed as is.
226 . Otherwise, the JMSMessage must be a JMS text message
containing XML.
227 . If there is a single parameter, or for the return value, the
JMS text XML payload is the XML
228 serialization of that parameter according to the WSDL schema for
the message.
229 . If there are multiple parameters, then they are encoded in XML
using the document wrapped
230 style, according to the WSDL schema for the message.
And the SCA java spec says:
1715 1.9. WSDL to Java and Java to WSDL
1716 The SCA Client and Implementation Model for Java applies the
WSDL to Java and Java to WSDL mapping
1717 rules as defined by the JAX-WS specification [4] for generating
remotable Java interfaces from WSDL
1718 portTypes and vice versa.
Based on this, my assumption is for text/xml wire format, we follow
the Java to WSDL mapping rules defined by JAXWS. It should also
apply to fault data. Passing exceptions as Objects in JMSMessage
seems to be a backdoor and it is not consistent with the wire
format. It requires both client and service side have the same
CheckedException class.
Thanks,
Raymond
