4 Replies Latest reply on Nov 19, 2014 11:52 AM by brmeyer

    S-RAMP's tree structure design

    brmeyer

      Lately, a few questions have come up regarding S-RAMP's tree structure.  For what it's worth, I figured I'd throw this out as a reference:

       

      First, a couple of S-RAMP topics to note.  Artifacts in the repository are either "primary" or "derived".  As an example, if you upload a WSDL (primary artifact -- WsdlDocument), we automatically derive other artifacts from that: Messages, Operations, Ports, etc.  All artifacts carry metadata, built-in and provided by S-RAMP.  Users can also provide custom properties, as well as relationships between artifacts.  Some of the relationships are automatic (based on the "derivers"), others are custom and controlled ad-hoc by the user.  We also support ontology classifications.

       

      All of that is to describe the tree.  Here's a quick overview:

       

      When you upload a primary artifact, it's assigned a UUID.  That UUID is used to generate the tree path, rather than something more logical/hierarchical.  There are several reasons for this, most notably performance (limit the tree width -- any node is guaranteed to have <= 255 children).  For example, a UUID of 76baf4a0-69ad-11e4-9803-0800200c9a66 would end up on a path of /s-ramp/76/ba/f4/a0-69ad-11e4-9803-0800200c9a66 (more of a B-Tree structure).  So, if you solely push in primary artifacts, those artifacts don't result in any derived artifacts, and no relationships are defined, you'd have a directed acyclic graph (although, technically, I believe Modeshape might have each node carry a "parent" reference, but we don't actually use that).

       

      Derived artifacts are the only true hierarchical leaves on the tree, attached to the primary artifact that created them.  Many of our built-in derivers (XSD, WSDL, WS-Policy, Switchyard, Teiid, etc.) result in relationships, linking together the set of derived artifacts in useful ways.  Users can also define ad-hoc relationships between any artifacts, both primary and derived.  All relationships become named Modeshape node references.

       

      Other graphs, such as a pure cycle graph, are certainly possible.  However, it is largely up to the client to configure the relationships in a cyclic manner.

        • 1. Re: S-RAMP's tree structure design
          jorgemoralespou_2

          Is it possible to extend some way (easy way) the derivers so they add the relationships that a customer wants.

          Let's say that by default, a WSDL deriver, extracts the parts, schemas, etc... and adds a relationship of "derivedFrom" in the derived artifact. Let's say that I want that the extracting process adds a relationship of "contains" in the base artifact to the derived ones, so I can graphically see "contents" while looking at a primary artifact, and "containers" when looking at a derived artifact.

          I guess that also, a WSDL extracted from a SwitchYard app, will have also relations to the container (switchyardApp) as well as to the derived info (schemas,...) so I can browse the documents easily. This means that also extractors need to have some logic to be extensible.

          Does it make sense?

           

          Also, a side question is, if I deploy 2 WSDLs with same schema included, will that result in 2 different derived types, or 1 derived type with 2 relations of derivedFrom?

          • 2. Re: S-RAMP's tree structure design
            brmeyer

            > Is it possible to extend some way (easy way) the derivers so they add the relationships that a customer wants.

            Absolutely!  See "11.2.6. Extending: Custom ArtifactBuilder": Chapter 11. Overlord S-RAMP Implementation.  Note that this contract is new in 0.7.  Up through 0.6, a similar concept existed, but was called ArtifactDeriver.

             

            > Also, a side question is, if I deploy 2 WSDLs with same schema included, will that result in 2 different derived types, or 1 derived type with 2 relations of derivedFrom?

            At the moment, yes, that would result in duplicated schema artifacts.  However, [SRAMP-465] Investigate alternative methods for relationship resolution - JBoss Issue Tracker will change that and support re-use.

            • 3. Re: S-RAMP's tree structure design
              jorgemoralespou_2

              > Absolutely!  See "11.2.6. Extending: Custom ArtifactBuilder"

              If I create/deploy new ArtifactBuilders, how will they coexist with existing ones. Will all of the ArtifactBuilders discovered be called? Will my Artifact builder need to extend the base one? I've looked at the code for the demo, but not sure about this point :-D

              • 4. Re: Re: S-RAMP's tree structure design
                brmeyer
                If I create/deploy new ArtifactBuilders, how will they coexist with existing ones. Will all of the ArtifactBuilders discovered be called? Will my Artifact builder need to extend the base one?

                Abstract superclasses are provide for common functionality, most notably for XML document handling.  However, that's definitely not required.  They co-exist independently, and therefore each action is additive.