1 2 3 4 Previous Next 51 Replies Latest reply on Sep 25, 2006 11:44 AM by kurtstam

    Registry Design

    mugdho

      Like Mark had mentioned, the Beta release did not give much of an insight to the registry design. So now we need to start looking into that.
      The idea initially was to have a standalone custom regsitry that can be deployed on multiple machines to prevent single point of failure.
      Moreover the registry should be independent of a specific implementation like UDDI.
      Now based on the JBossWS project we decided to initially design with jUDDI and later move on to our custom regsirty. Now the problem with jUDDI is that it is WS based, so we would need to have an application server where we deployed the registry. This is something that we had planned to avoid since the registry should be essentially stand alone.
      I have been going thru the jUDDI code and I came to realise that along with builiding our custom listener for the requests, we may need to plugins for the aspects of security and authentication.
      For starters however we can get the current Code bound with jUDDI.
      Please let me know your thoughts on this.

        • 1. Re: Registry Design
          kurtstam

          Registry is on the top of our (well mine really) list now that the beta is released. There has been some discussion already which was nicely summarized in your wiki entry (http://labs.jboss.com/portal/index.html?ctrl:cmd=render&ctrl:window=default.wiki.WikiPortletWindow&page=Jbossesb%2FJAXR&language=EN)
          The initial idea of a standalone (distributed) custom registry is still the current. I think the design of this will start in 2 weeks time or so. If anyone has additional requirements, then this is a good time to speak up! I will also update the wiki page as we get down into it, and we welcome your involvement!

          I'm sorry that is pretty vague, for now at least. Feel free to repost specific question you want to have answered now and I can take a crack at it.

          • 2. Re: Registry Design
            mugdho

            I suppose then its a good time that I get a good hang of jUDDI for the moment. Once we get into design we can start answering the various aspects of the registry.
            The initial discussion questioned the fact whether we could keep the Registry free of UDDI or any particular implementation. Is that the current idea as well or will we address other types of implementation which JAXR supports (assuming that we will be using JAXR for implementing the API calls)

            • 3. Re: Registry Design
              kurtstam

              Yes as always we want our users to plug in whatever service they want to use if they don't want to use their own, so the JAXR api seems the way to go for interacting with the registries (inluding our own). So hopefully we can keep the esb code free of UDDI. However, for the implementation the registry itself, I'm not yet sure how that is going to play out, but you'd think that if we will use JAXR to call it we will have no need for UDDI specifics, since we can't call it anyway. So, in short, the answer is yes that is still the current idea :).

              • 4. Re: Registry Design
                mugdho

                Okay, so lets see if my understanding of registry is correct.
                We use UDDI+SOAP for the requests to the Regsitry. The Registry reads these messages and locates the required service which is sent back to the user. So essentially the UDDI aspect should be ending once the message has been translated and beyond that given any type of implementation it would be the same.
                Am I correct till here?

                • 5. Re: Registry Design
                  tfennelly

                  "In theory" that sounds like what we're after Mugdho :-)

                  Basically, I think the approach would be:
                  1. Work out the requirements for our registry - the capabilities it needs to have etc.
                  2. Work out a suitable implementation that's flexible enough to allow us layer UDDI etc on top of the core implementation. The core impl is not standards based, but that doesn't mean you can't beg_borrow_and_steal ideas from a number of standards.
                  3. Layer UDDI etc on top of the core implementation.

                  My understanding is that this is the basic architectural philosophy across all aspects of the ESB - a standards agnostic component core with the relevant standards layered more thinly on top.

                  • 6. Re: Registry Design
                    mugdho

                    So the most _important_ question which we face first is what are the requirements of our Registry.
                    The main aim of a registry is to hold information of the services that are requested. So it forms the main lookup area for our ESB. This does imply that the registry will be storing a lot of data.
                    The jUDDI implementation uses a database like MySQL to store this data. Similarly we would need to provide the ability to the user to use any custom database.
                    The Registry would do most of the talking with our own ESB code I presume and be abstracted from the user requesting a service.

                    I assume there would be other functionalities of the Registry as well. I guess we can gather some user inputs about the same from what the other folks would _want_ from the Registry?

                    • 7. Re: Registry Design
                      tfennelly

                      I'm not sure exactly what sort of abstraction we'd need re a reg. My initial guess would be that we need to abstract the type of functionality defined in the "Inquiry API Set" as described in the UDDI spec at http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908076.

                      Would we need anything else? Would we need equivalent abstractions for all those these inquiry patterns? Would the ESB need to be able to add/update metadata in the registry? What sort of functional cross-over exists between UDDI and other reg specs in this area (inquiry)?

                      • 8. Re: Registry Design
                        estebanschifman

                        A good starting point would be to design our 'RegistryEntry' class. We should forget of how to store it and concentrate on what we need of this class. Whatever the requirements might be, don't rule out the alternative of using the Rosetta object store as the registry repository.
                        This 'out of the box' alternative will help us remain completely independent of the relational paradigm.

                        • 9. Re: Registry Design
                          mugdho

                          Okay. Lets start from scratch then. The basics of any registry...what do we want from it? Based on that we can decide what the RegistryEntry class would need to contain. Since we are keeping the Registry independent of UDDI we need to have an abstraction layer over here as well.

                          I guess we will need inputs about the requirements. The very basic functions of any regiistry are Inquiry and Update
                          1) Inquiry - Who is inquiring the Registry? How is the inquiry taking place?
                          2) Updates - The services will need to get registered in the Registry. How would the users do this?
                          3) Authentication - I suppose we would require authentication modules for the Registry. Since the Registry will be stand alone, we may need to figure out this.
                          4) Finally Rosetta has a Registry. How much can we reuse from it.

                          Thoughts on these?

                          • 10. Re: Registry Design
                            tfennelly

                             

                            1) Inquiry - Who is inquiring the Registry? How is the inquiry taking place?

                            We'll def need an abstraction for this!

                            Who? Internal and External clients.

                            How? I guess a SOAP interface is the most useable.

                            2) Updates - The services will need to get registered in the Registry. How would the users do this?

                            I'd wonder if we need to worry about this!! Who needs to make reg updates? Will reg updates need to be made by a running ESB or Services? Do we need it for the GA release?

                            3) Authentication - I suppose we would require authentication modules for the Registry. Since the Registry will be stand alone, we may need to figure out this.

                            For the GA release (and possibly beyond), can we not rely on some form of container managed security (Authentication/Authorisation)? Just seems like this is a nut that's been cracked a million times over! Excuse my ignorance if I'm completely wrong on this :-)

                            • 11. Re: Registry Design
                              tfennelly

                              In fact, in terms of the authentication - the reg is a service, right! Therefore (in theory), the security requirements for accessing and using this service should be the same as that required for accessing and using any other service - and should be handled by whatever security "features" come with the ESB. As yet, I haven't heard anything of what these features will be though :-)

                              • 12. Re: Registry Design
                                mugdho

                                 

                                How? I guess SOAP Interface will be the most useable.

                                SOAP sounds good. Haven't used it much though. But I guess its not tied to UDDI.

                                I'd wonder if we need to worry about this!! Who needs to make reg updates? Will reg updates need to be made by a running ESB or Services? Do we need it for the GA release?

                                How about the users trying to add a new service to be registered? We would need to provide a way for that I guess. Perhaps thru an admin console?


                                For the GA release (and possibly beyond), can we not rely on some form of container managed security (Authentication/Authorisation)?...

                                I assume you are talking of a container like Tomcat? Or is there anything else we could use?

                                Yeah I do suppose we would need the Registry to have similar Security features as the other services of the ESB. But we can think of them when the security features are worked out :-)).

                                • 13. Re: Registry Design
                                  tfennelly

                                   

                                  How about the users trying to add a new service to be registered? We would need to provide a way for that I guess. Perhaps thru an admin console?

                                  Exactly! I'd expect this type of info to be added to the registry via whatever admin console comes with the reg product. I don't think this is something we need to abstract.

                                  I assume you are talking of a container like Tomcat? Or is there anything else we could use?

                                  Yeah I do suppose we would need the Registry to have similar Security features as the other services of the ESB. But we can think of them when the security features are worked out :-)).


                                  Aye, I think "Service Security" is a bigger issue that needs to be solved for all services being plugged into the ESB. I'm not sure there's anything special about the registry in this regard.

                                  • 14. Re: Registry Design
                                    mugdho

                                    Okay. So now we are getting somewhere :-)).
                                    So...
                                    The Inquiry needs to be abstracted using SOAP.
                                    The Updates will be thru the Admin Console and wouldn't need abstraction.
                                    The Service Security is for the ESB has a whole and we will need to work it out together.

                                    Next thing that I can think of is the Distributed nature of the Registry. Clustered Registry I should say. And it would be stand alone as well. So the first thing we need is a listener for requests. Would we grow this from scratch or we reuse currently available listeners from some application?

                                    1 2 3 4 Previous Next