> I'm getting a very bad vibe from SOAP attachements for large binary
> files between Java and .Net:
>
> 1. MIME not supported by .Net
>
> 2. DIME not well supported by Java stacks
DIMS has been deprecated even by MSFT.
> 3. MTOM too new
Apache Axis2 certainly supports it as do several other stacks now.
Depending on your willingness to use "new" code you could use MTOM.
> 4. SOAP stacks load entire object into memory, and break with 1GB files
Not Axis2- after a (configurable) threshold the attachment streams
directly into disk.
> SOAP stacks are not designed to transfer large binary data.
> Typically, the details of the protocol are hidden from the client, and
> their isn't any fine grain control (for good reason).
If you use the full power of MTOM, then you get the advantage of being
able to sign the binary parts as well. So once you have streaming MTOM
support then it should work fine for you.
> Possible solutions?
>
> 1. indirection: put HTTP URL link into SOAP Body, rather than file
> itself.
If this is an option then its always a better way .. basically pass by
reference.
> 2. base64 encode file and put into SOAP envelope. Seems okay for
> small files; bigger files could be broken up; this seems ugly.
If the SOAP stack is designed with MTOM in mind, then this and the
optimized case work the same way .. the diff is that the client picks
whether to optimize or not based on metadata from the server. Anyway,
you're looking for non-MTOM options.
> Any suggestions, pointers?
What platforms are you looking for this function on? If its Java then
you can use Apache Axis2 for this. (There are other stacks that support
MTOM as well.)
Sanjiva.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
