axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <>
Subject Re: How do you know you've got attachments?
Date Sun, 28 Oct 2001 03:27:25 GMT
May I propose:
On the first pass we restrict to only supporting attachments as direct
parameters.  This makes it easy to detect which parameters are attachments
And  once detected, attachments are put in the message object.  Then any
attachments in the message object send as attacments... none send SOAP
I don't think this is too limiting for the following reasons: I don't think
it's a step back from SOAP 2.x since I don't think it supported attachments
except as parameters,
As far a I know when it comes to WSDL it is only possible to express
attachments as parameters, so we are covered from a Web Services

In next pass, once we have a better understanding of ALL the implications
that attachments has brought to Axis, and it becomes a must do
 to support arrays of  attachments, or complex types with attachments, I
envision we can do something with
the TypeMappingRegistry.  I think in the fist pass we will need a
serializer for attachments provided by Axis.  I was thinking of
making this serializer as  part of the default SOAP type registry, but now
maybe thinking about it, its better not to.  If the user explicitly
adds to the call object this serializer and  if we don't have any
attachments that have been directly added to the message object  then we
can do one of two things:
just send the payload as attachments and hope there really is one buried in
a complextype or array, and when found through
serialization add it the message object.  Or, prescan all the complex and
array objects and when the first one is found stop and decide its time to
send an attachment payload.

Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

Rob Jellinghaus <> on 10/27/2001 07:01:53 PM

Please respond to

Subject:  Re: How do you know you've got attachments?

Well, we certainly could add a call.setProperty(etc., etc.) method -- but
what about a service that doesn't *use* a Call object, but that just
returns some Java object?  I really don't see how a Java provider type of
service (which may not really even know that Axis is calling it!) can
specify, up front, that its response message should be a MIME envelope.

I think that for now, the serialize-and-detect-DataHandlers approach is the
way to go.  If we really want to support streaming of large envelopes
(which we certainly don't do now), and if we need to start sending MIME
before we've done any serialization, probably the best thing to do is just
always to send MIME envelopes even if there is only one (root) part!

I'm pretty clear on the full picture of how attachments will work, and I
don't see many (any?) other options, especially in the
Java-service-provider case.  I suppose the Java service provider could do
the accept-the-MessageContext-argument trick, but I'm not sure it's worth


(p.s. Sorry everyone for the duplicate messages -- my mailer gets slightly
confused by axis-dev headers, for some reason... I'll make sure it doesn't
happen again.)

At 05:59 PM 10/27/2001 -0400, Doug Davis wrote:
>I don't buy that - either they're going to be creating an object that
>will signal to us that they want attachments (ie. AxisDataHandler)
>or they could at least tell us explicitly
>(call.setProperty(Call.HAS_ATTACHMENTS, true)).
>I bet once we know the full picture of how attachments will work
>there will be some way to know before we start to serialize the
>envelope that we need a MIME envelope.
>Rob Jellinghaus <> on 10/27/2001 05:04:41 PM
>Please respond to
>Subject:  Re: How do you know you've got attachments?
>In the general case, you might not be passing a raw DataHandler into the
>call object; you might pass an array of them, or a struct containing them,
>or an array of structs containing them.  The same is true on the server
>side where you could return any serializable object (say, a whole tree of
>beans of some kind, some of which have DataHandler members).
>In general, you don't know whether there are any DataHandlers hiding down
>inside the values being passed, until you serialize.
>At 08:08 AM 10/27/2001 -0400, Doug Davis wrote:
>>I'm missing something - if someone passes in a DataHandler
>>to the Call object, and it is going to be made into an attachment
>>then why do you need to search or buffer anything- you know there's
>>an attachment right away (based on the type of the argument, its
>>a DataHandler) just set a flag and then when you serialize you know
>>know you need MIME - no buffering needed. What am I missing?
>>Rob Jellinghaus <> on 10/26/2001 08:51:36 PM
>>Please respond to
>>Subject:  How do you know you've got attachments?
>>(I'm sending these various attachment design issues to the list, partly
>>because I genuinely do want input, and partly because some folks here
>>in the past requested more visibility into ongoing design topics.)
>>When sending an outbound message, how should Axis determine whether to
>>a MIME enclosure or not?
>>The simple answer is "if there are any attachments, send a MIME envelope.
>>However, one common scenario for using attachments will be that users
>>simply pass a DataHandler as an argument to a Call object.  (Apache SOAP
>>supports this -- just pass a DataHandler as argument, and it will be
>>serialized as an attachment, and deserialized as a DataHandler on the
>>So if the user passes a DataHandler as an argument, rather than
>>calling any addBodyPart-like API, then when does Axis recognize that
>>are now attachments in the Message?
>>There are two alternatives:
>>- When SOAPBodyElements are added to a SOAPEnvelope, they could be
>>to see if they contain DataHandlers.
>>     Pro: this is done before any serialization, so you can know upfront
>>you need to create a MIME envelope.
>>     Con: this would be complex and there isn't any precedent for it.
>>- When an envelope is serialized, any DataHandlers encountered could be
>>converted into attachments.
>>     Pro: this leverages the serialization framework, and lets it do its
>>     Con: you have to serialize the whole envelope before you start
>>any MIME content, since it is envelope serialization that tells you what
>>attachments you must send.
>>Apache SOAP takes the second strategy... actually, even worse:  it
>>serializes, not only the envelope, but also all the attachments!  It
>>buffers them all in memory and then sends the whole buffer.  This means
>>that Apache SOAP's memory overhead is something like 2x the size of the
>>attachments themselves.
>>I plan to pursue the second strategy:  serialize the envelope (only!)
>>a buffer before sending.  This means that we will not support streaming
>>very huge envelopes, but I think that's OK -- we're prioritizing support
>>for huge attachments, not huge envelopes.
>>Thoughts?  Lack of response will be interpreted as assent :-)

View raw message