9 Replies Latest reply on Dec 8, 2006 7:32 PM by weston.price

    ProfileService kickoff

    starksm64

      See for the overview of the ProfileService notions, issues and current state.
      http://wiki.jboss.org/wiki/Wiki.jsp?page=ProfileService

      Resolving the issues and coming up with a stable api to which we can code our management tools is what we need to discuss.

        • 1. Re: ProfileService kickoff
          weston.price

          Excellent summary of the issues as well as the overall goal of the service itself.

          One thing I would assume is that the underlying Repository could be a variety of implemenations (RDMBS, LDAP, Serialized Java etc) and that we will provide drivers or adapters that would allow different repository deployment types. Obviously a longer term target, but I think it's important from the repository metadata standpoint to not get 'locked' in to an particular implementation right off the bat.

          • 2. Re: ProfileService kickoff
            starksm64

            Yes, there will be a repository interface that externalizes its implementation from the profile service.

            • 3. Re: ProfileService kickoff
              weston.price

              Trivial at this stage I know, but it would seem to answer *some* of those questions we were talking about on the call. I am still hung up in my head about a few things:

              I understand a 'management view' of the an actual physical deployment (EAR, WAR, RAR), I guess what I am hung up on is what we were calling the diff/merge on the call.

              How does X know that Y has changed and as a result, updates Z? It's the variation between the management view and the actual physical deployment that is tough for me to get my head around at this point.

              • 4. Re: ProfileService kickoff
                starksm64

                This is what I was trying to drill into as well. The profile service is the service that returns the managment interface it obtains from the deployment by parsing it, and when updates are done, its done via a crud view of the profile service. There are different ways this can be handled. What we talked about was:

                1. The profile service runs the deployment through the the deployment chain up to the metadata parsing phase to obtain the deployment specified metadata. This is why its important for component deployers to properly separate metadata parsing into stages. This is stored as an attachment associated with the deployment in the repository.

                2. When there is an update via the crud interface, the profile service takes this metadata, clones it, and applies the managed object changes to it. This is stored as an override in the repository.

                3. When the profile service is asked for the DeploymentContexts associated with a DeplomentUnit, it attaches the approriate metadata as a predetermined attachment.

                4. A deployer querying DeploymentUnit.getAttachment will see the overriden, predetermined instance.

                • 5. Re: ProfileService kickoff
                  weston.price

                  OK, I think I have a better grasp on this now.

                  From a root deployment (initial deployment) the profile service has to know about what gets deployed and the metadata that gets generated as result, or at the very least, it's Management DD. It does this via the deployment chain as you talked about. The results of the initial deployment are persisted to the repository. Diffs can begin at this point, effectively the deployment is versioned.

                  I think I was hung up more on the 'who starts the chain' more than I was what happens as a result.

                  So, based on this design, there is no concept of a JBoss instance existing without a ProfileService, they are effectively one and the same in terms of the 'client view'. The ProfileService really takes over what the old JMX system used to provide but with a ton of more features (versioning, dynamic lifecycle including a STOP, etc).

                  Let me know if I am on the right track.





                  • 6. Re: ProfileService kickoff
                    weston.price

                    Yes, now I see.

                    The 'mapping' issue we talked about now comes into play.The underlying metadata (EAR, WAR, RAR) is effectlively much different than the management meta data that the ProfileService understands. How does the subset (management) infrastructure create/read/update/delete against the superset (actual metadata).





                    • 7. Re: ProfileService kickoff
                      starksm64

                       

                      "weston.price@jboss.com" wrote:

                      From a root deployment (initial deployment) the profile service has to know about what gets deployed and the metadata that gets generated as result, or at the very least, it's Management DD. It does this via the deployment chain as you talked about. The results of the initial deployment are persisted to the repository. Diffs can begin at this point, effectively the deployment is versioned.

                      I think I was hung up more on the 'who starts the chain' more than I was what happens as a result.

                      So, based on this design, there is no concept of a JBoss instance existing without a ProfileService, they are effectively one and the same in terms of the 'client view'. The ProfileService really takes over what the old JMX system used to provide but with a ton of more features (versioning, dynamic lifecycle including a STOP, etc).

                      Let me know if I am on the right track.


                      The profile service plugs into the long standing ServerImpl bootstrap mechanism, so to some extent its replacable. With the update to all of the deployers, there is an extended contract on how deployments are brought into the server that obsoletes the old scanners, but they could be ported over in place of the profile service.

                      Certainly all of the new features we are working on now are quality of service issues that can be disabled and you still have a functional server. We do want a full featured profile service as the default replacement for the old jmx deployment mechanism, so yes, there is no interesting jboss server without a profile service.


                      • 8. Re: ProfileService kickoff
                        starksm64

                         

                        "weston.price@jboss.com" wrote:

                        The 'mapping' issue we talked about now comes into play.The underlying metadata (EAR, WAR, RAR) is effectlively much different than the management meta data that the ProfileService understands. How does the subset (management) infrastructure create/read/update/delete against the superset (actual metadata).

                        This is the magic Adrian is working on. Until we see that I don't know the details.


                        • 9. Re: ProfileService kickoff
                          weston.price

                          Cool. I just wanted to walk through how I see it working. Sounds like we are all on the same page.