I'll also give my thoughts:
(1) Some transports can easily reproduce the original message. This is
the case for VFS, JMS, Mail and UDP. We should leverage this by
letting them put a DataHandler or DataSource object into the
MessageContext so that the original content can be retrieved later.
(Actually we should also define an extended message builder interface
that allows the transport to pass the DataHandler/DataSource to the
message builder. This would allow to optimize BinaryBuilder.)
(2) For transports such as HTTP that can't reproduce the original
message easily, we can wrap the InputStream provided to the message
builder in such a way that all data read from it is also copied to a
buffer.
(3) We need a way to detect whether the message has been modified or
not. Since AXIOM is entirely defined by interfaces, we can create
proxies to intercept calls to methods in SOAPEnvelope, SOAPHeader,
etc. These proxies need to be instantiated recursively, e.g. when
getHeader is called on the proxy for SOAPEnvelope, it should create a
proxy for SOAPHeader, etc. Obviously we can't do that for the entire
SAOP infoset as this would more or less double the number of Java
objects created for each message. So we should stop creating proxies
when the body of the message is accessed.
(4) We need to identify the methods in SOAPEnvelope, SOAPHeader, etc.
that don't modify (and don't allow the caller to modify) the SOAP
infoset and implement the proxies in such a way that whenever an
"unsafe" method is called, the message is marked as "tainted". When
this happens, we should also stop creating proxies and also stop
copying the original message data into the buffer (see point 2).
(5) The transport senders or message builders (to be decided) can then
check whether the message is tainted or not and send out the original
message if appropriate. At this point we can do further optimization
if we allow the sender to read the original data destructively as
suggested in SYNAPSE-357. If this is enabled we can do streaming at
the byte stream level (instead of the StAX level).
This looks quite complicated (especially point 3), but I think this
level of sophistication is required to have a solution that is
transparent to Axis2 and Synapse while still supporting optimization
even if the SOAP headers are read.
Andreas
On 27 juin 08, at 10:03, Ruwan Linton wrote:
Hi Indika,
Please see my comments inline;
On Fri, Jun 27, 2008 at 1:13 PM, indika kumara
<[EMAIL PROTECTED]> wrote:
Hi All
Some thought...
Currently message building and serializing is in transport layer.
According to the content type ,message is being built and we cannot
control the building process. For example , if the content type is
corresponding to the SOAP , then SOAP message is built and we cannot
avoid it.
No we can, just need to override the builder in the axis2.xml
associated with the content type and in there depending on a
parameter in the axis2.xml we can decide whether to build this
message with what ever the builder. May be this parameter can go
into the synapse.xml but not sure about the technical challenges of
the implementation, so lets keep that decision to the implementation
phase.
This is fine only if we use or access SOAP message. But if we can
dispatch to synapse,proxyservices,etc without touching SOAP message
Well, with axis2 this is a little hard because you might need a SOAP
info-set to come out passing the handler chain.
and if we will not touch the SOAP message within synapse, then , we
should not want a SOAP message. But , currently , we have not that
control .
I think we can get the control at the MessageBuilder level.
If we can provide a option to transport to specify whether to build
a message or not (build and set as SOAP envelope ) and also if can
provide a way in synapse language to specify whether to build a
message or not(Build mediator which builds message and sets as SOAP
envelope – default behavior may use content-type, but we have to
have options to override it.).
This is exactly what I meant.
One other possibility is , with in transport layer , the message
always set as stream or OMDatasource (use BinaryBuilder )
irrespective of content type and whenever try to access message on
the first time (messagecontext.getSOAPEnvelope()) and if SOAP
envelope has not been built yet, then builds it and sets as Envelope.
Again this is hard to implement, because even if you use
OMDataSource you will have to have a SOAPEnvelope and this
OMDataSource will be attached as the DataHandler for the payload
(most probably the payload will be a Text node with the DataSource
as the DataHandler) in which case there is no distinction between a
binary message like hessian messages and a SOAP message and will
lead to conflicts on building the message. Otherwise the builder has
to aware of each and every content-type and it has to embed the
logic on how to proceed with these content types, which will affect
the extensibility of the message formats supported by synapse.
This will be completely avoid building message as a SOAP envelope ,
if we have not any interest in it.
I think there should be a parameter to specify whether to build the
message or not, synapse should not be intelligent enough to take
that decision.
For serialization part , we can do the same thing.
I don't know this is a good suggestion , but I believe , for
scenarios, that we don't access SOPA message, we have to completely
avoid building it.
Completely agreed and +1 for this.
Thanks,
Ruwan
Thanks
Indika
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
