7 Replies Latest reply on Jun 29, 2006 8:05 AM by heiko.braun

    MTOM/XOP support

    heiko.braun

      Heiko wrote:


      > Hi Alexey,
      >
      > I started working on MTOM (http://www.w3.org/TR/soap12-mtom/), that
      > supports binary optimization for bean properties / complex types. The
      > basic idea is that any xsd:base64binary type will not be represented
      > as
      > base64 encoded string, but directly written to a mime multipart that
      > carries the data. This way encoding/decoding of base64 data can be
      > skipped.
      >
      > The reason why I am approaching you is that we require this feature
      > for any bean property that is described as xsd:base64binary. We
      > decided for a design that follows the JAXB 2.0 specs and allows
      > callbacks from the binding layer to the soap processor in order to optimize binary data.
      > It's described in JAXB 2.0 specs, section H.3.
      >
      > I would like to bring the AttachmentMarshaller / Unmarshaller concept
      > forward and introduce it to our current binding implemention, so that
      > I can complete the MTOM support for document/literal requests.
      >
      > Should we go for a brief skype conference once you made yourself
      > familiar with the AttachmentMarshaller API? We could then talk through
      > the details.
      >
      > Regards, Heiko



        • 1. Re: MTOM/XOP support
          heiko.braun

          Heiko Braun wrote:


          > Hi Alexey,
          >
          > after a discussion with thomas, we decided that only the declared type
          > 'xmlmime:base64Binary' should be optimized, instead of all
          > xsd:base64binaries:
          >
          > <xs:schema targetNamespace="http://www.w3.org/2005/05/xmlmime">
          >
          > <xs:attribute name="contentType">
          > <xs:simpleType>
          > <xs:restriction base="xs:string">
          > <xs:minLength value="3"/>
          > </xs:restriction>
          > </xs:simpleType>
          > </xs:attribute>
          >
          > <xs:attribute name="expectedContentTypes" type="xs:string"/>
          >
          > <xs:complexType name="base64Binary">
          > <xs:simpleContent>
          > <xs:extension base="xs:base64Binary">
          > <xs:attribute ref="xmime:contentType"/>
          > </xs:extension>
          > </xs:simpleContent>
          > </xs:complexType>
          >
          > </xs:schema>
          >
          > It seems that we are not able to read the content-type attribute from
          > our current schema model, therefore we do simple content-type guessing
          > based on the java type. The jbossws.utils.MimeUtils class contains
          > examples for that.
          >
          > Anyway i think your marshaller/unmarshaller implementations do not
          > need to deal with it, as the implementaiton actually comes from
          > jbossws, right?
          >
          > I saw that you factored the interface to XOPMarshaller/Unmarshaller. I
          > will move our implementation to that interface as well and drop the
          > initial abstractions from javax.xml.*
          >
          > /Heiko


          • 2. Re: MTOM/XOP support
            heiko.braun

            Alex wrote:


            thanks for the info. I've already started work on any derivation of xs:base64Binary though.
            The reason for adding XOPMarshaller was purely build system related.
            Otherwise there would be cyclic module dependecies, i.e. between common and j2ee.


            • 3. Re: MTOM/XOP support
              heiko.braun

              You can name it as you like as long as the concept stays the same.
              BTW, should we move

              isXopOptimizable(TypeBinding type)
              to the interface as well? This way the implementation (jbossws in this case) could decide which declared types can be optimized. Actually we do that upfront already anyway ...


              • 4. Re: MTOM/XOP support
                aloubyansky

                Maybe. So far it's internal impl details that may change. I would like to finish the basic support for this first.

                • 5. Re: MTOM/XOP support
                  aloubyansky

                  Here is what I currently have http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossXB_XOP

                  Also see org.jboss.test.xml.XOPUnitTestCase.

                  Let me know what is missing and the priorities.

                  • 6. Re: MTOM/XOP support
                    aloubyansky

                    I realized it's too soon for the WS team to be happy about this. XOP marshalling is supported by the SchemaBinding-based marshaller, not the XercesXsMarshaller which is currently used by the JBossWS.
                    I don't want to spend time on XercesXsMarshaller now. Switching to the SchemaBinding-based marshaller has been planned for a long time now

                    http://jira.jboss.com/jira/browse/JBWS-673

                    It's time to finally make this step.

                    • 7. Re: MTOM/XOP support
                      heiko.braun

                      in order to get rid of the XB dependencies towards JAF & Mail i suggets we factor out the DataHandler from the XOP interfaces and use an equivalent class that's suffiecient to our needs:

                      I.e:

                      public interface XOPMarshaller
                      {
                       boolean isXOPPackage();
                       String addMtomAttachment(XOPObject obj, String elementNamespace, String elementName);
                       String addMtomAttachment(byte[] data, String elementNamespace, String elementName);
                      }
                      


                      public class XOPObject {
                      
                       private Object content;
                       private String contentType;
                      
                       public XOPObject(Object content) {
                       this.content = content;
                       }
                      
                       public Object getContent() {
                       return content;
                       }
                      
                       public String getContentType() {
                       return contentType;
                       }
                      
                       public void setContentType(String contentType) {
                       this.contentType = contentType;
                       }
                      }