3 Replies Latest reply on Nov 10, 2006 9:29 AM by julien1

    Consumer registration to the producer

      I have added a set of interfaces that defines the bare minimum of what the portal requires as a managing entity. Those interfaces are used by the portal to manage the set of consumers (i.e from the GUI) and their registrations.

      Also it is designed such as the underlying persistence mechanism can be hibernate. We will have specifc requirements here as the implementation will be provided by an already existing service (org.jboss.portal.core.impl.portlet.state.PersistenceStateStore) in order to have an efficient management of state. I.e destroying a consumer will destroy all the underlying portlet clones. It is likely that the PersistentStateStore will implement the ConsumerRegistry interface.


        • 1. Re: Consumer registration to the producer

          I don't see the need today to send opaque registration data to the consumer. The registration id (handle) should be sufficient unless we discover fancy security scenarios that can leverage it. So for now we should left that aside, it can still be added later if we need it. That will avoid unnecessary complexity.

          • 2. Re: Consumer registration to the producer

            I was talking only for the producer of course, as our consumer will need to store registration state sent by any producer.

            "julien@jboss.com" wrote:
            I don't see the need today to send opaque registration data to the consumer. The registration id (handle) should be sufficient unless we discover fancy security scenarios that can leverage it. So for now we should left that aside, it can still be added later if we need it. That will avoid unnecessary complexity.


            • 3. Re: Consumer registration to the producer

              I worked on the registration stuff, here is what I did :

              - removed responsibilities from the RegistrationPolicy. It used to create handle values for the registration. This responsibility is clearly implemented by the consumer registry which knows how it is created (either by a database generator, or by a UUID, etc...)

              - moved all the policy related stuff into the policies package in order to avoid the mix with the registratry stuff. By the way it could be possible to move the registry to a org.jboss.portal.wsrp.producer.registration.registry package.

              - I removed the fact that a registration object is "owned" by a consumer. Actually registration objects are managed by the consumer registry directly and there is a one to many association between a consumer and its registration :

              
               Consumer consumer = registry.getConsumer("abc");
              
               // Enforce the fact that we need an existing consumer
               // in order to create a registration
               Registration registration = consumer.addRegistration(regData);
              
               // We can retrieve all the registrations owned by the consumer
               assertTrue(consumer.getRegistrations().contains(registration));
              
               // We can retrieve a registration by its id directly
               Registration same = registry.getRegistration(registration.getId());
               assertEquals(registration, same)
              
               // We can remove a registration
               registry.removeRegistration(registration.getId());
              
               // Removing the registration break the association
               assertTrue(consumer.getRegistrations().isEmpty());
              
              


              We could also remove directly the consumer and in cascade remove the registrations.

              
               Consumer consumer = registry.getConsumer("abc");
               Registration registration = consumer.addRegistration(regData);
              
               // Will destroy the registration object as well
               registry.removeConsumer(consumer);