axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <rineh...@us.ibm.com>
Subject Re: SOAP Attachment
Date Wed, 24 Oct 2001 18:03:15 GMT

>Well... I'm not sure with the current Message API, but with the changes
>that I have in mind (not yet finalized or completely thought out), each
>service will use a specific Message factory class for creating messages.
>If the service supports or requires messages with attachments, then all
>messages created by that services message factory will be an instance of
>MessageWithAttachments.  If the service does not support messages with
>attachments, then all messages created will be instances of Message.

Where does the "Message factory" get the information to know what
service is going to require attachments or not?

>I like things clean, neat, organized, and easy to find.  The
>org.apache.axis.message package should contain only the core Message API
>classes.  For SOAP specific stuff, create a org.apache.axis.message.soap
>package.  For message attachments, create a
>org.apache.axis.message.attachments package, etc.  Right now, having
>everything thrown into one package (org.apache.axis.message) is confusing
>and difficult to see what is going on.  It also complicates things if we
>really do intend to make the message protocol format pluggable.

I'll chalk this up I guess to a difference of opinion as to what the intent
of
having packages means in Java.  I did not perceive its primary role
to be a means for organization.  I view it as set of classes that provide
services to other classes.  In order to achieve this they are more than
likely required to share some methods that other classes that are not
involved with providing these services should not invoke.  This was
what I believe the reason for not needing the controversial "friend"
attribute used in "C++".  Now if it also helps in some way to be
neat and organized that too is good.



>- James M Snell/Fresno/IBM
>Web services architecture and strategy
>Internet Emerging Technologies, IBM
>544.9035 TIE line
>559.587.1233 Office
>919.486.0077 Voice Mail
>jasnell@us.ibm.com
>=================================================================
>Have I not commanded you?  Be strong and courageous.  Do not be terrified,
>do not be discouraged, for the Lord your God will be with you wherever you
>go.
>- Joshua 1:9
>Please respond to axis-dev@xml.apache.org
>To:     axis-dev@xml.apache.org
>cc:
>Subject:        Re: SOAP Attachment
>
>>A couple of off the cuff comments
>>1. I'd like to see support for attachments be completely pluggable.  If I
>>don't want to support attachments, I shouldn't have to have mail.jar and
>>activation.jar in my classpath.  This has always been a pain in the
>>hind-quarters with SOAP 2.x and I don't want to see it duplicated here.
>I "think" we can satisfy this as a run time requirement, but you might
>need
>them to compile. That is to say that if attachments are not present you
>don't
>need these in your classpath.  But if you don't and an attachment stream
>is
>present you'll probably get a class not found exception. I'll investigate
>this
>some more.
>However JAX-RPC depending exactly how you read it mandates or
>strongly advises the use of classes in these packages for attachments
>so any work with regard to this in Axis would have to be similarly
>pluggable to achieve what you are asking.
>>2. I personally have quite a few problems with the current Message API
>>implementation... specifically in that it does not meet our original
>>requirement of being pluggable and non-SOAP specific.  I'd actually like
>>to see those concerns addressed before we increase the complexity with
>>attachments.
>Sounds reasonable, when will you have this checked in so that me
>and Rob J. may begin?
>>3. Methods to add/get/remove attachments should be made part of a
>>MessageWithAttachments class that extends Message class, IMO.
>Is this how this will flow?
>A soap message comes that has no attachments so a Message
>class is created.
>A handler decides to add a header with an attachment so create
>a new MessageWithAttachments copy or construct whats needed from the old
>Message object  to the newly created MessageWithAttachments.
>The next handler in the chain decides to remove that  header
>and that only attachment, so create a new Message object , copy all
>thats need from the old MessageWtihAttachments .....
>>4. Packaging.  I'd prefer a separate package for this.  The
>>org.apache.axis.message package is muddled up enough and needs to be
>>cleaned up, IMO
>My understanding of Java's package feature is to put classes that are
>related in the same package so that they need not expose
>methods that only need to be invoked between them.  Are you
>saying that this work does not fit in to the package that deals with
>the other components of the SOAP message?
>I'm too new to pass judgment if the message package is muddled up,
>but I'd be interesting in knowing what your ideas  are to clear up?
>Will you have this checked in before or after the Message API rework?
>>- James M Snell/Fresno/IBM
>>Web services architecture and strategy
>>Internet Emerging Technologies, IBM
>>544.9035 TIE line
>>559.587.1233 Office
>>919.486.0077 Voice Mail
>>jasnell@us.ibm.com
>>=================================================================
>>Have I not commanded you?  Be strong and courageous.  Do not be
>terrified,
>>do not be discouraged, for the Lord your God will be with you wherever
>you
>>go.
>>- Joshua 1:9
>>Please respond to axis-dev@xml.apache.org
>>To:     axis-dev@xml.apache.org
>>cc:
>>Subject:        SOAP Attachment
>>
>>Attached is a summary of the ideas that Rob Jellinghaus and I have been
>>bouncing around in regard to
>>supporting attachments in Axis.  Comments? Suggestion?  Help?
>>(See attached file: Attachments.htm)
>>Rick Rineholt
>>"The truth is out there...  All you need is a better search engine!"
>>rineholt@us.ibm.com
>>
>
>Rick Rineholt
>"The truth is out there...  All you need is a better search engine!"
>rineholt@us.ibm.com
>


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

rineholt@us.ibm.com


Mime
View raw message