1 2 Previous Next 22 Replies Latest reply on Mar 2, 2007 8:49 AM by marklittle

    Virtual Registries?

      I have been looking at incorporating various frameworks into the ESB and it seems that the registry is only one per ESB (is this correct?).

      It would be great if we could have a concept of a virtual registry to connect up to say microcontainer, spring, etc...

      You configure the registry:

      <registry id="myregistryid" type="spring" location="/applicationContext.xml"/>
      
      
      <registry id="myregistryidB" type="uddi" location="http://localhost:9001/juddi"/>
      


      Where the location can be url or classpath reference.

      And the reference to services / actions:

      <action name="SpringBeanName" registryid="myregistryid" >
      
      </action>
      
      


      The name would looks up in the spring application context for class or another frameworks component architecture like microcontainer.

      If no registry id is found then it defaults to the default setting in the current configuration.

        • 1. Re: Virtual Registries?
          marklittle

          Kurt should be better able to reply, since he drove the registry work. As long as they support JAX-R, we could do that now I suppose. We have had the notion of a federated registry in the original architecture, that I'd like to get implemented eventually. Plus local cached/persisted copies of information, e.g., a flat file version of JAX-R with a minimal footprint.

          • 2. Re: Virtual Registries?
            kurtstam

            Hi Dan,

            I'd say you'd only have one (internal) registry per company. So all your apps can use that one. They way you talk about the the registry I think is more like a JNDI, and there is certainly some overlap with that, but it's not the same thing.

            That said, I'm trying to understand by what you mean with 'virtual'. It sounds like you mean connecting to more then one registry which would certainly be a possibilty - if there is a use case for it.

            Cheers,

            --Kurt

            • 3. Re: Virtual Registries?
              marklittle

               

              "kurt.stam@jboss.com" wrote:
              Hi Dan,
              I'd say you'd only have one (internal) registry per company. So all your apps can use that one.


              I don't think that's necessarily the case. One registery per company is one deployment choice, but one per organisational entity, or even one per group makes a lot of sense. Think of federated registries within a single company boundary.

              • 4. Re: Virtual Registries?
                anil.saldhana

                Isn't UDDIv3 along those lines - federation etc?

                • 5. Re: Virtual Registries?
                  kurtstam

                  Right, but even so you'd probably want to set up that up at the registry level and not at the ESB or even application level. Like Anil is saying this is along the lines of uddi v3.

                  • 6. Re: Virtual Registries?
                    marklittle

                    For one thing, we're not UDDI dependant ;-) So although v3 may give some capabilities, it's not a solution. A single registry (whatever the implementation) within an organisation is a single point of failure and something we need to avoid. Hence the reason for federation (or replication) of the service within the architecture and not as a backend implementation choice. The bootstrap process we have in place at the moment would be one of the first places to start, but then you'd need some way of deciding where to go for alternate (and equivalent) replicas of the registry service(s). It would be nice to think that all of this could be hidden behind the client's interface (the JAX-R equivalent of the client stub). To a degree that should be possible. Stateful replication is a hard problem ;-)

                    • 7. Re: Virtual Registries?
                      kurtstam

                      Sure but my point is that this should be hidden from the client. And that it is "along the lines of UDDI v3".

                      • 8. Re: Virtual Registries?
                        tfennelly

                        Isn't Kurts point... Registry details (federated or otherwise) should be invisible to someone using the Registry Service. I thought he was just using UDDIv3 as an example.

                        • 9. Re: Virtual Registries?
                          tfennelly

                          Ups, sorry :-)

                          • 10. Re: Virtual Registries?
                            marklittle

                             

                            "kurt.stam@jboss.com" wrote:
                            Sure but my point is that this should be hidden from the client. And that it is "along the lines of UDDI v3".


                            It depends who the client is then. I'm not suggesting this is visible to the application developer. But it needs to be visible to the component that interacts with the registry implementation. In my example, that would be the JAX-R client stub.

                            • 11. Re: Virtual Registries?
                              kurtstam

                              Ah ok. So now we outside of ESB code. Sure.

                              • 12. Re: Virtual Registries?
                                marklittle

                                 

                                "kurt.stam@jboss.com" wrote:
                                Ah ok. So now we outside of ESB code. Sure.


                                Depends what you mean by "ESB code". Since we may have to provide this capability, I'll class it as "ESB code" ;-)

                                • 13. Re: Virtual Registries?
                                  kurtstam

                                  Priceless LOL :). But now we have to move the discussion to a different forum. :)! But then all roads lead back to Rome, so...

                                  • 14. Re: Virtual Registries?
                                    tfennelly

                                    Guys, can we make this thread sticky too? It's too funny to be allowed slip away into the depths of the forum :-)

                                    1 2 Previous Next