Details

    • Type: Feature Request
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Estimated Difficulty:
      Low

      Description

      The XML marshalling used by Seam Remoting can be optimized significantly by making a few, relatively simple, changes.
      1. Making some element names shorter, specifically 'member'.
      2. Resolving object fields by position instead of by name. This eliminates the need for the 'name' attribute of the 'member' element.
      3. Handling nulls pointers in structures in a simpler way: Use an empty 'member' element.
      4. Removing some of the wrapper elements around primitive types.

      In our examples we've seen that the optimized XML is less than 40% of the size of the original XML.

        Gliffy Diagrams

          Activity

          Hide
          kpgalligan Kevin Galligan added a comment -

          First shot at reducing XML size. Changes are as follows:

          • Most tag names are significantly shorter. That includes types and structural tags (bean, map, number, element, member, etc). Where possible, they are 1 or 2 letters.
          • Members of beans are listed in alphabetical order instead of using the 'name' attribute. On the client side, the metadata is used to inflate the data objects. This significantly cuts down on data size for larger object graphs, but introduces a major potential issue discussed below.
          • The tag names for the simple types are shortened, and I defined them in one place in the code which is dynamically generated in the Remote servlet. This was to simply to make that clearer and easier to change in the short term. Once the structure is set, they could be put directly into the JS again.
          • Some remote.js changes. The type handling/registration code between DTO types and components had some duplication, so I rolled that into a single object, but kept the original method names in case somebody had redefined them. That could be trimmed in the future.

          Potential issue. If the interface js file is cached, and the object model changes, the positional member resolution will fail badly. Still need to sort that out. The file size savings are significant, however, so we should figure that out.

          We did some light testing locally and our data size was cut down to about 34% of the original. We could squeeze out a bit more by cutting down the tag names at the top (envelope, header, conversationId, etc). Its relatively small, though. The other place to cut would be the bean type names, but that would have required some real changes to how the API worked that I didn't want to get into.

          I also changed the interface file generation. This actually saves quite a bit. Our major interface file is cut back to 20% of the original size, from about 75k to 15k. It uses the metadata to build pretty much everything, including declaring the fields and getter/setter methods.

          In the current interface file there is a minor bug. Sort of a bug, anyway. It works, but its incorrect. The getter/setter methods are defined on the prototype, but the are defined each time the constructor is called. It works, but the prototype methods really only need to be defined once. Running that each time is just adding some proc overhead.

          Show
          kpgalligan Kevin Galligan added a comment - First shot at reducing XML size. Changes are as follows: Most tag names are significantly shorter. That includes types and structural tags (bean, map, number, element, member, etc). Where possible, they are 1 or 2 letters. Members of beans are listed in alphabetical order instead of using the 'name' attribute. On the client side, the metadata is used to inflate the data objects. This significantly cuts down on data size for larger object graphs, but introduces a major potential issue discussed below. The tag names for the simple types are shortened, and I defined them in one place in the code which is dynamically generated in the Remote servlet. This was to simply to make that clearer and easier to change in the short term. Once the structure is set, they could be put directly into the JS again. Some remote.js changes. The type handling/registration code between DTO types and components had some duplication, so I rolled that into a single object, but kept the original method names in case somebody had redefined them. That could be trimmed in the future. Potential issue. If the interface js file is cached, and the object model changes, the positional member resolution will fail badly. Still need to sort that out. The file size savings are significant, however, so we should figure that out. We did some light testing locally and our data size was cut down to about 34% of the original. We could squeeze out a bit more by cutting down the tag names at the top (envelope, header, conversationId, etc). Its relatively small, though. The other place to cut would be the bean type names, but that would have required some real changes to how the API worked that I didn't want to get into. I also changed the interface file generation. This actually saves quite a bit. Our major interface file is cut back to 20% of the original size, from about 75k to 15k. It uses the metadata to build pretty much everything, including declaring the fields and getter/setter methods. In the current interface file there is a minor bug. Sort of a bug, anyway. It works, but its incorrect. The getter/setter methods are defined on the prototype, but the are defined each time the constructor is called. It works, but the prototype methods really only need to be defined once. Running that each time is just adding some proc overhead.
          Hide
          shane.bryzak Shane Bryzak added a comment -

          Thanks for the patch - it seems to be for Seam 2 though. The Seam 3 Javascript in remote.js has changed significantly and this patch can't be applied to it.

          Show
          shane.bryzak Shane Bryzak added a comment - Thanks for the patch - it seems to be for Seam 2 though. The Seam 3 Javascript in remote.js has changed significantly and this patch can't be applied to it.
          Hide
          pgmjsd Joshua Davis added a comment -

          Yes, this is for Seam 2.2 which is what we use here. We could try applying it to Seam 3, but I remember reading that Seam 3 doesn't work with JBoss 5.1.0.GA. Is that still the case?

          Show
          pgmjsd Joshua Davis added a comment - Yes, this is for Seam 2.2 which is what we use here. We could try applying it to Seam 3, but I remember reading that Seam 3 doesn't work with JBoss 5.1.0.GA. Is that still the case?
          Hide
          kpgalligan Kevin Galligan added a comment -

          Sorry for the confusion. Taking a look at version 3 code.

          Show
          kpgalligan Kevin Galligan added a comment - Sorry for the confusion. Taking a look at version 3 code.

            People

            • Assignee:
              shane.bryzak Shane Bryzak
              Reporter:
              pgmjsd Joshua Davis
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development