Vivek Pandey wrote:
>> I think it is possible.
>>
>> The SOAP part is read first. If there are any parts before it they
>> need to be cached. If the reading of the infoset in the SOAP part
>> results in access to a part after the SOAP part then:
>>
> Typically, start parameter tells which part is SOAP part if present
> otherwise its always the first part.
>
>> 1) on the first time the whole SOAP part is cached, and any parts
>> between the SOAP part and the part to acccess are cached; or
>>
>> 2) on the second or subsequent time any parts between the SOAP part
>> and the part to acccess are cached (if not already done so).
>>
>> When using just MTOM i am not sure caching will always be used needed
>> because i would expect attachments to be serialized linearly.
>>
> Not really. the MIME parts cant be assumed to be in a particular order.
>
I know that it cannot be assumed but my reasoning was that the infoset
would be serialized linearly and therefore the XOP attachments would be to.
>> I think the interesting case occurs when mixing MTOM and swa:Ref
>> attachments. We should put the latter as the last parts to avoid
>> processing until the last minute when they are accessed.
>
>
>
> I dont see how will that help? It all depends on the infoset as to when
> jaxb asks for a swaref part or mtom part data. Yes, a WSDL MIME part can
> be put last because this would be needed only at the time of unpacking
> or SOAP message -> parameters.
>
On processing when is an attachment part bound to a parameter of a
method? My assumption was that for the most part it would be bound after
the XOP parts have been processed. Therefore we may have an opportunity
to manage really efficiently very large swa:Ref attachments (basically
the attachment is being processed while still reading from the network).
I am trying to figure out if there are ways we can make it really
efficient when our clients talk to our services, while still being
efficient for other orders obtained using other implementations.
>>> Yes. We need some way to bridge content-type to Decoder. Whether it
>>> needs to be factory (which suggests pluggability), or it can be just
>>> a map, I don't know.
>>>
>>
>> OK.
>>
>> Should Encoder/Decoder implementations be stateless? If not i can
>> improve on the current StreamSOAPDecoder implementation.
>>
>>
> I would thnik so, otherwise we need to create new transport pipe for
> every request.
>
OK.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109