[
https://issues.apache.org/jira/browse/WSCOMMONS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840362#action_12840362
]
Andreas Veithen commented on WSCOMMONS-525:
-------------------------------------------
The component that will transform the Object to a SOAPEnvelope for the JAX-WS
case will indeed have a dependency on axis2-jaxws (or at least on JAXB).
Something important that I forgot to mention is that if there is a handler
(either an Axis2 module or a JAX-WS handler) that is not aware of the
OMDataSource and accesses the message as XML, it should see the message as if
it had been transmitted as SOAP. If a JAXBDataSource is used, then this is
automatically the case. Thus this component cannot live in the JMS transport,
but needs to be plugged into it through some interface (message builder or
something else).
Here is another use case that doesn't depend on any particular data binding or
Web service API and that could be realized with components shipped with the JMS
transport. Assume that you have two applications communicating via JMS using
ObjectMessages and that one of these applications is being outsourced or moved
off-site, so that they cannot communicate directly any more. One way to achieve
that could be to (use Synapse to) bridge from JMS to WS-RM over HTTP on one end
and from WS-RM to JMS on the other end. Since there is no data binding capable
of mapping every possible Java class to XML and vice-versa (every data binding
relies on some conventions or imposes some restrictions), the easiest way to do
that is to transmit the data as a serialized Java object (base64 encoded or
MTOM). If the JMS transport is configured such that it maps the Java object to
<wrapper>base64 encoded serialized Java object</wrapper>
and vice-versa, then the required Synapse configuration would be a simple
transport switch and routing.
> Supporting JMS Object Messages
> ------------------------------
>
> Key: WSCOMMONS-525
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-525
> Project: WS-Commons
> Issue Type: Improvement
> Components: Transport
> Affects Versions: Transports 1.0
> Reporter: indika priyantha kumara
> Fix For: Transports 1.1
>
> Attachments: jms-object-msg.patch
>
>
> I have attached herewith a patch to support Object Messages. What I did is as
> follows
> 1) Add a content type rule as follows
> <parameter name="transport.jms.ContentType">
> <rules>
>
> <objectMessage>application/java-serialized-object</objectMessage>
> </rules>
> </parameter>
> Even there is no content type for Java object messages, I have to specify one
> due to fact the JMS message receiver validates the content type. Furthermore,
> if there is content type, we can specify message builder / formatters.
> 2) When an Object message is received, it is wrapped with an
> ObjectDataSource and processed by the ObjectMessageBuilder. Within the
> ObjectMessageBuilder , if the content type is
> ''application/java-serialized-object" , It just wraps the ObjectDataSource
> using a DataHandler. The actual object can be accessed directly through the
> ObjectDataSource. This is useful for Apache Synapse as a mediator can access
> the object directly and do whatever it needs. If the content type is
> something other than ''application/java-serialized-object", selects the
> correct builder for the content type and build the java object with it by
> giving object as an XML stream. I here used XML Encoder... I will change it
> later.
> 3) When sending Object Messages, within the JMS transport, the object
> can be directly accessed from the ObjectDataSource. For other transport, if
> it is useful, ObjectMessageFormatter can be used.At later, I can improve
> ObjectDataSource to rerun the representation of Object based on the content
> type. E.g. XML, byte, etc... representations
> Any feedback is welcome. I will improve as per any suggestions and update the
> patch
> Thanks Indika
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
