1 2 3 4 5 Previous Next 72 Replies Latest reply on Apr 20, 2006 4:18 AM by starksm64 Go to original post
      • 60. Re: Need to get going on a ProfileService api
        starksm64

        Let's get concrete for a second as we can get caught in the ever expanding circle of abstractions forever.

        In the profile service prototype I'm working on, here are the basic notions.

        1. It is a local filesystem based implementation that has a representation of the deployments as a unified repository similar to how the installer models things as packs.
        2. A named profile is a selection of the packs.
        3. Bootstraping a profile entails building the BeanInfos for each deployment. This includes configuring the classpath, dependency, etc. metadata. The deployment Policy objects are abstractions for dependencies of injected values. The idea is that I have to iterate through the Policy objects for each deployment bean property looking for the first Policy which supports the property so I can wire a dependency to the associated source of the property data. The deployment metadata is some form of jboss-beans.xml fragments so far.

        That is pretty much it. There are a lot of details in 3 that I don't know yet. Hotdeployment is not supported in the first iteration.

        Being able to edit the profile definitions is another level of functionality. That is why I did not include the ability to save a profile initially. I think the save functionality should be an extension of an immutable profile service base interface. The first basic usecase of this level is hotdeployment.

        Being able to obtain management views of the deployments is another level of functionality. There are connected/disconnected notions here.

        • 61. Re: Need to get going on a ProfileService api
          starksm64

           

          "charles.crouch@jboss.com" wrote:
          "scott.stark@jboss.org" wrote:

          Its not clear that this should be a manifest api in the ProfileService. Why wouldn't this be an implementation detail that picks up the transaction aspect when running in a context with a transaction (and ejb3 embedded implementation of the ProfileService)?


          Ok, I guess the bigger question is how could any implementation of the Profile Service support transactions in any useful way. I could envisage treating Deployments as transactional resources just by storing them in a DB, but what about when it comes to updating Policies for Deployments which are running, e.g. how can I tell my JMS Server to rollback that change that I just made to it? Maybe this topic should be discussed on a subsequent thread?


          This is composed of so many levels its not a comprehensible question in general. This does relate to why I want to layer the profile service into immutable base interfaces with mutable subinterfaces as well as distinguish between connected and disconnected behavior.

          If the MC is well designed and integrated with AOP, the answer should be yes to all levels. To achieve transactional behavior for any operation will require transaction aware aspects to exist. This is the intractable part of the problem. All components have to be designed with this in mind, and the transaction aspects could be coming from both the deployments as well as the profile service itself. Throw in doing transactional ops across a cluster and you have a distributed tx CF in the making. This needs to be added in steps.


          • 62. Re: Need to get going on a ProfileService api
            ccrouch

             

            "scott.stark@jboss.org" wrote:

            Let's get concrete for a second as we can get caught in the ever expanding circle of abstractions forever.


            Fair comment, but for me one of the key things to get out of this thread is an agreed upon set of abstractions around which we can develop our APIs and also document use cases.

            I'm looking for the abstraction that lets us address the original stated problem that the "management view of the server is non-existent from the perspective of a stable API that could be the basis for managment tools/consoles".

            To do this I believe we need a management level concept that encapsulates things that can be added to a server and things that are already running there.

            So far we know:
            - Services aren't it, and we shouldn't use that name for this concept, as Adrian pointed out early on.
            - Deployments aren't it. Last week I argued they were, but I am happy to accept Scott's verdict that "What we need is the equivalent of the jsr77 view which says what a given type of deployment looks like."

            We need to define this other "thing", this "equivalent of the jsr77 view", which allows the management tools to use the same concept whether they are adding something to a server (i.e. deploying) or updating something which is already present.

            Can we just decide on a sensible for name for the things which will appear in this pseudo-jsr77 view, e.g. MC ManagedObject??. This will map to the "management view java bean that aggregates one or more deployment metadata beans" that Scott mentioned earlier, right? With that I can try again to come up with use cases which we can all agree upon make sense.

            For instance at some level of abstraction, hopefully this one, it *must* make sense to talk about transactions. At some level it must enventually cease being "not a comprehensible question in general." How these abstractions get implemented is obviously going to be the fiendishly complicated part.

            Thanks

            • 63. Re: Need to get going on a ProfileService api
              acoliver

              My god this is going nowhere. Shut up with the architect-speak and lets see some rought interfaces and code.

              • 64. Re: Need to get going on a ProfileService api
                starksm64

                 

                "acoliver@jboss.org" wrote:
                My god this is going nowhere. Shut up with the architect-speak and lets see some rought interfaces and code.

                Yes master. In progress as you vent.

                • 65. Re: Need to get going on a ProfileService api
                  acoliver

                  That's right Igor... 'Bout time you figured out who is boss round here.. Seriously though this is really starting to be a concern. If I'm not just going to do a dirty hack, and JBMS is going to be easy to administer w/o hacking XML config, then progress (as defined by code being written) needs to start happening. *whip cracking sound*

                  • 66. Re: Need to get going on a ProfileService api
                    starksm64

                     

                    "charles.crouch@jboss.com" wrote:

                    I'm looking for the abstraction that lets us address the original stated problem that the "management view of the server is non-existent from the perspective of a stable API that could be the basis for managment tools/consoles".

                    To do this I believe we need a management level concept that encapsulates things that can be added to a server and things that are already running there.

                    So far we know:
                    - Services aren't it, and we shouldn't use that name for this concept, as Adrian pointed out early on.
                    - Deployments aren't it. Last week I argued they were, but I am happy to accept Scott's verdict that "What we need is the equivalent of the jsr77 view which says what a given type of deployment looks like."

                    We need to define this other "thing", this "equivalent of the jsr77 view", which allows the management tools to use the same concept whether they are adding something to a server (i.e. deploying) or updating something which is already present.

                    Can we just decide on a sensible for name for the things which will appear in this pseudo-jsr77 view, e.g. MC ManagedObject??. This will map to the "management view java bean that aggregates one or more deployment metadata beans" that Scott mentioned earlier, right? With that I can try again to come up with use cases which we can all agree upon make sense.

                    For instance at some level of abstraction, hopefully this one, it *must* make sense to talk about transactions. At some level it must enventually cease being "not a comprehensible question in general." How these abstractions get implemented is obviously going to be the fiendishly complicated part.



                    The "management view java bean that aggregates one or more deployment metadata beans" is just not manifest in the abstraction yet because its something that should be layer on top of the raw deployment beans. It could be implemented on top of the existing metadata view. As Adrian pointed it there can be more help from the deployment bean metadata by having management view annotations that could be associated with the raw bean properties to indicate that propertyX should be associated with managementViewY.propertyX2. Probably we do need an explicit setManagementView/getManagementView interface into the profile service layers, but as I said I already view the current api as aggregating too many functions and need to be layered into different interfaces.

                    Expanding the prototype to support a portletized jmx-console type of view that uses such a mapping scheme is something I want done to have a full if simple proof of concept.

                    • 67. Re: Need to get going on a ProfileService api
                      acoliver

                      Sheesh, Not like I'm difficult or anything. All I've ever asked is that ya'll unquestionably serve me at my every whim. And complete said things to the utmost quality in the time that I need them. Is that too much to ask?

                      • 68. Re: Need to get going on a ProfileService api
                        starksm64

                         

                        "acoliver@jboss.org" wrote:
                        That's right Igor... 'Bout time you figured out who is boss round here.. Seriously though this is really starting to be a concern. If I'm not just going to do a dirty hack, and JBMS is going to be easy to administer w/o hacking XML config, then progress (as defined by code being written) needs to start happening. *whip cracking sound*

                        There is code:
                        http://wiki.jboss.org/wiki/Wiki.jsp?page=ProfileServiceClasses

                        I only go one way with uml tools (java to uml).


                        • 69. Re: Need to get going on a ProfileService api
                          acoliver

                          Can you please check them in somewhere? I'm not an architect so UML mostly gives me a headache.

                          • 70. Re: Need to get going on a ProfileService api
                            starksm64

                            Tonight.

                            • 71. Re: Need to get going on a ProfileService api
                              brian.stansberry

                              Did these get checked in somewhere? I'm not seeing them in the MC modules in AS HEAD.

                              • 72. Re: Need to get going on a ProfileService api
                                starksm64

                                The spi is in the container module. The initial kernel bootstrap implementation has not been committed yet.

                                1 2 3 4 5 Previous Next