Re: [Axis2] Re: XMLBeans, Attachments and Rampart

2007-05-05 Thread Dennis Sosnoski

Hi Jorge,

My understanding of how Rampart works now is that if you do *any* 
security processing on your service it will always build the full model 
of the document in memory. Chunking is not going to effect this at all.


 - Dennis

Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Jorge Fernandez wrote:

Hi Dennis,

Thanks for the information. I wonder if there is a limit on the size 
of attachments only when I want to encrypt them because in some cases 
I don't need to do it and AFAIK, with rampart you can choose which 
parts you want to encrypt.


A question for Thilina: When a client invokes a method from my Axis2 
Web Service and the response message is going to be very big, so I use 
http chunking: Does axis build all the message at once in memory and 
then break it pieces?? I possible to build each part in memory and 
send it, release memory and build - send the next one??


I'm having some memory issues after invoking some methods that build 
big messages. I'm using Axis2 under Tomcat and the memory size ot 
Tomcat increases from 50 MB to 300 MB and I didn't see it decreasing.


Thanks and regards,

Jorge Fernández


*/Dennis Sosnoski <[EMAIL PROTECTED]>/* escribió:

Hi Jorge,

I haven't verified Rampart handling of attachments, but based on what
I've seen in other cases I suspect it will build an in-memory
representation of the entire document (including attachments, as
embedded base64 text) any time Rampart is engaged for a service. This
should really only be necessary when you're signing or encrypting the
body, but in my trials Rampart built the in-memory tree even when
just
adding timestamps.

The reason why the attachments need to be part of the tree goes
back to
the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM
are
treated just as if they were embedded directly in the XML document,
using base64 encoding - MTOM is *only* a transport level
optimization.
This means that when you use WS-Security you need to have a view
of the
document with the attachments present as the base64 strings. AFAIK
there's no way around this issue, since it was "by design".

It would be possible in theory for the WS-Security implementation
to be
smart about handling attachments, and basically just generate a
streaming version of the base64 representation for the attachment
data
as needed when signing (digesting, actually) or encrypting. But this
would require changes all the way down to the underlying XML
Signature
and XML Encryption implementations, and I'd suspect such changes are
unlikely to occur without a lot of user demand. In the meantime, I
suspect the practical limit for attachment size with Rampart engaged
will be somewhere in the 10 MB range.

- Dennis

Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Jorge Fernandez wrote:
> Hi again,
>
> I didn't have answer for my question. So I'll try again.
>
> My problem is that I was using XMLBeans for my project. But
XMLBeans
> doesn't support MTOM. So I tried to use ADB but I have some
problems
> with the mapping of my objects to xml so I would like keep using
> XMLBeans.
>
> Also I want to secure my message also and I found that Rampart and
> MTOM have memory problems.
>
> This are my questions:
>
> - When I used ADB and MTOM I could see that if I don't enable MTOM,
> the attachment is sent in binary code as a String inside de SOAP
> message but if I enable MTOM, it's send outside the message in
clear
> text (I used an xml file as example of attachment). I would like to
> send the attachment outside the message in binary code. Is this
possible??
>
>
>
> - I know that MTOM is better than SwA, but what are the reasons?
>
> - Is there any limit in the size of messages that axis2 can send, I
> mean in both the envelope and as attachments?? I'll have to send
huge
> arrays of int or other data. I'll have to send some of them as
> attachments to avoid the multiple tags the xml would generate.
>
> - The last one: As I'm building big messages, I'm having memory
> problems and I would like to know if axis can build this
messages in
> parts, like build the first part of the message when it reach a
limit
> size and send it, then build another one and send it..
>
> Any help will be appreciated.
>
> Thanks in advance,
>
> Jorge Fernández
>
>
>
> */Jorge Fernandez /* escribió:
>
> Hi all,
>
> I would like to know if it's 

RE: [Axis2] Re: XMLBeans, Attachments and Rampart

2007-05-05 Thread Jorge Fernandez
Also the last thing I would like to know is how can I transfer a short array 
because in the xml it generates lots of tags so I thought of sending it as an 
attachment but I think that I have to transform it to I byte array, am I right? 
Is it possible to transfer it as an attachment without having to transform it??


Jorge Fernandez <[EMAIL PROTECTED]> escribió: Hi Dennis, 

Thanks for the information. I wonder if there is a limit on the size of 
attachments only when I want to encrypt them because in some cases I don't need 
to do it and AFAIK, with rampart you can choose which parts you want to 
encrypt. 

A question for Thilina: When a client invokes a method from my Axis2 Web 
Service and the response message is going to be very big, so I use http 
chunking: Does axis build all the message at once in memory and then break it 
pieces?? I possible to build each part in memory and send it, release memory 
and build - send the next one??

I'm having some memory issues after invoking some methods that build big 
messages. I'm using Axis2 under Tomcat and the memory size ot Tomcat increases 
from 50 MB to 300 MB and I didn't see it decreasing. 

Thanks and regards,

Jorge Fernández


Dennis Sosnoski <[EMAIL PROTECTED]> escribió: Hi Jorge,

I haven't verified Rampart handling of attachments, but based on what 
I've seen in other cases I suspect it will build an in-memory 
representation of the entire document (including attachments, as 
embedded base64 text) any time Rampart is engaged for a service. This 
should really only be necessary when you're signing or encrypting the 
body, but in my trials Rampart built the in-memory tree even when just 
adding timestamps.

The reason why the attachments need to be part of the tree goes back to 
the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM are 
treated just as if they were embedded directly in the XML document, 
using base64 encoding - MTOM is *only* a transport level optimization. 
This means that when you use WS-Security you need to have a view of the 
document with the attachments present as the base64 strings. AFAIK 
there's no  way around this issue, since it was "by design".

It would be possible in theory for the WS-Security implementation to be 
smart about handling attachments, and basically just generate a 
streaming version of the base64 representation for the attachment data 
as needed when signing (digesting, actually) or encrypting. But this 
would require changes all the way down to the underlying XML Signature 
and XML Encryption implementations, and I'd suspect such changes are 
unlikely to occur without a lot of user demand. In the meantime, I 
suspect the practical limit for attachment size with Rampart engaged 
will be somewhere in the 10 MB range.

  - Dennis

Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Jorge Fernandez wrote:
> Hi again,
>
> I didn't have  answer for my question. So I'll try again.
>
> My problem is that I was using XMLBeans for my project. But XMLBeans 
> doesn't support MTOM. So I tried to use ADB but I have some problems 
> with the mapping of my objects to xml so I would like keep using 
> XMLBeans.
>
> Also I want to secure my message also and I found that Rampart and 
> MTOM have memory problems.
>
> This are my questions:
>
>   -  When I used ADB and MTOM I could see that if I don't enable MTOM, 
> the attachment is sent in binary code as a String inside de SOAP 
> message but if I enable MTOM, it's send outside the message in clear 
> text (I used an xml file as example of attachment). I would like to 
> send the attachment outside the message in binary code. Is this possible??
>
>
>
>   -  I know that MTOM is better than SwA, but what are the reasons?
>
>   -  Is there  any limit in the size of messages that axis2 can send, I 
> mean in both the envelope and as attachments?? I'll have to send huge 
> arrays of int or other data. I'll have to send some of them as 
> attachments to avoid the multiple tags the xml would generate.
>
>   -  The last one: As I'm building big messages, I'm having memory 
> problems and I would like to know if axis can build this messages in 
> parts, like build the first part of the message when it reach a limit 
> size and send it, then build another one and send it..
>
> Any help will be appreciated.
>
> Thanks in advance,
>
> Jorge Fernández
>
>
>
> */Jorge Fernandez /* escribió:
>
> Hi all,
>
> I would like to know if it's possible to use XMLBeans and Rampart
> with attachtments cos I heard that XMLBeans doesn't support  MTOM
> and I doubt if Rampart supports SwA or there is any problem in
> that combination.
>
> Thanks and regards,
>
> Jorge Fernández
>
>
> 
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a

RE: [Axis2] Re: XMLBeans, Attachments and Rampart

2007-05-05 Thread Jorge Fernandez
Hi Dennis, 

Thanks for the information. I wonder if there is a limit on the size of 
attachments only when I want to encrypt them because in some cases I don't need 
to do it and AFAIK, with rampart you can choose which parts you want to 
encrypt. 

A question for Thilina: When a client invokes a method from my Axis2 Web 
Service and the response message is going to be very big, so I use http 
chunking: Does axis build all the message at once in memory and then break it 
pieces?? I possible to build each part in memory and send it, release memory 
and build - send the next one??

I'm having some memory issues after invoking some methods that build big 
messages. I'm using Axis2 under Tomcat and the memory size ot Tomcat increases 
from 50 MB to 300 MB and I didn't see it decreasing. 

Thanks and regards,

Jorge Fernández


Dennis Sosnoski <[EMAIL PROTECTED]> escribió: Hi Jorge,

I haven't verified Rampart handling of attachments, but based on what 
I've seen in other cases I suspect it will build an in-memory 
representation of the entire document (including attachments, as 
embedded base64 text) any time Rampart is engaged for a service. This 
should really only be necessary when you're signing or encrypting the 
body, but in my trials Rampart built the in-memory tree even when just 
adding timestamps.

The reason why the attachments need to be part of the tree goes back to 
the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM are 
treated just as if they were embedded directly in the XML document, 
using base64 encoding - MTOM is *only* a transport level optimization. 
This means that when you use WS-Security you need to have a view of the 
document with the attachments present as the base64 strings. AFAIK 
there's no way around this issue, since it was "by design".

It would be possible in theory for the WS-Security implementation to be 
smart about handling attachments, and basically just generate a 
streaming version of the base64 representation for the attachment data 
as needed when signing (digesting, actually) or encrypting. But this 
would require changes all the way down to the underlying XML Signature 
and XML Encryption implementations, and I'd suspect such changes are 
unlikely to occur without a lot of user demand. In the meantime, I 
suspect the practical limit for attachment size with Rampart engaged 
will be somewhere in the 10 MB range.

  - Dennis

Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Jorge Fernandez wrote:
> Hi again,
>
> I didn't have answer for my question. So I'll try again.
>
> My problem is that I was using XMLBeans for my project. But XMLBeans 
> doesn't support MTOM. So I tried to use ADB but I have some problems 
> with the mapping of my objects to xml so I would like keep using 
> XMLBeans.
>
> Also I want to secure my message also and I found that Rampart and 
> MTOM have memory problems.
>
> This are my questions:
>
>   -  When I used ADB and MTOM I could see that if I don't enable MTOM, 
> the attachment is sent in binary code as a String inside de SOAP 
> message but if I enable MTOM, it's send outside the message in clear 
> text (I used an xml file as example of attachment). I would like to 
> send the attachment outside the message in binary code. Is this possible??
>
>
>
>   -  I know that MTOM is better than SwA, but what are the reasons?
>
>   -  Is there any limit in the size of messages that axis2 can send, I 
> mean in both the envelope and as attachments?? I'll have to send huge 
> arrays of int or other data. I'll have to send some of them as 
> attachments to avoid the multiple tags the xml would generate.
>
>   -  The last one: As I'm building big messages, I'm having memory 
> problems and I would like to know if axis can build this messages in 
> parts, like build the first part of the message when it reach a limit 
> size and send it, then build another one and send it..
>
> Any help will be appreciated.
>
> Thanks in advance,
>
> Jorge Fernández
>
>
>
> */Jorge Fernandez /* escribió:
>
> Hi all,
>
> I would like to know if it's possible to use XMLBeans and Rampart
> with attachtments cos I heard that XMLBeans doesn't support MTOM
> and I doubt if Rampart supports SwA or there is any problem in
> that combination.
>
> Thanks and regards,
>
> Jorge Fernández
>
>
> 
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com
> 
>
>
> 
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com 
>  


-
To

[Axis2] Re: XMLBeans, Attachments and Rampart

2007-05-04 Thread Dennis Sosnoski

Hi Jorge,

I haven't verified Rampart handling of attachments, but based on what 
I've seen in other cases I suspect it will build an in-memory 
representation of the entire document (including attachments, as 
embedded base64 text) any time Rampart is engaged for a service. This 
should really only be necessary when you're signing or encrypting the 
body, but in my trials Rampart built the in-memory tree even when just 
adding timestamps.


The reason why the attachments need to be part of the tree goes back to 
the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM are 
treated just as if they were embedded directly in the XML document, 
using base64 encoding - MTOM is *only* a transport level optimization. 
This means that when you use WS-Security you need to have a view of the 
document with the attachments present as the base64 strings. AFAIK 
there's no way around this issue, since it was "by design".


It would be possible in theory for the WS-Security implementation to be 
smart about handling attachments, and basically just generate a 
streaming version of the base64 representation for the attachment data 
as needed when signing (digesting, actually) or encrypting. But this 
would require changes all the way down to the underlying XML Signature 
and XML Encryption implementations, and I'd suspect such changes are 
unlikely to occur without a lot of user demand. In the meantime, I 
suspect the practical limit for attachment size with Rampart engaged 
will be somewhere in the 10 MB range.


 - Dennis

Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Jorge Fernandez wrote:

Hi again,

I didn't have answer for my question. So I'll try again.

My problem is that I was using XMLBeans for my project. But XMLBeans 
doesn't support MTOM. So I tried to use ADB but I have some problems 
with the mapping of my objects to xml so I would like keep using 
XMLBeans.


Also I want to secure my message also and I found that Rampart and 
MTOM have memory problems.


This are my questions:

  -  When I used ADB and MTOM I could see that if I don't enable MTOM, 
the attachment is sent in binary code as a String inside de SOAP 
message but if I enable MTOM, it's send outside the message in clear 
text (I used an xml file as example of attachment). I would like to 
send the attachment outside the message in binary code. Is this possible??




  -  I know that MTOM is better than SwA, but what are the reasons?

  -  Is there any limit in the size of messages that axis2 can send, I 
mean in both the envelope and as attachments?? I'll have to send huge 
arrays of int or other data. I'll have to send some of them as 
attachments to avoid the multiple tags the xml would generate.


  -  The last one: As I'm building big messages, I'm having memory 
problems and I would like to know if axis can build this messages in 
parts, like build the first part of the message when it reach a limit 
size and send it, then build another one and send it..


Any help will be appreciated.

Thanks in advance,

Jorge Fernández



*/Jorge Fernandez <[EMAIL PROTECTED]>/* escribió:

Hi all,

I would like to know if it's possible to use XMLBeans and Rampart
with attachtments cos I heard that XMLBeans doesn't support MTOM
and I doubt if Rampart supports SwA or there is any problem in
that combination.

Thanks and regards,

Jorge Fernández




LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com






LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]