9 Replies Latest reply on Sep 27, 2006 6:15 PM by marklittle

    Registry Service Design

    kurtstam

      We will soon have an embeddedable JAXR/UDDI component using Apache Scout as the JAXR implementation, a local transport implementation to support local java calls, and a slightly modified jUDDI to support these direct java calls (and soon there after hopefully RMI calls too). OK so far so good. Now the ESB has access to any kind of XML registry (it'd be ebXML or UDDI), and by default it will use embedded jUDDI.

      Now what if other systems want to access this registry?

      I see 3 scenarios of how you could do this:
      1. If the registry is embedded, those systems can use JAXR and RMI (Scout with our RMI-Transport) to connect to the UDDI embedded in the JBossESB.
      2. Those systems can call to their very own embedded jUDDI, which is configured to use the same database. Or use their own registry database with somekind of replication.
      3. What if the client is not java based? Then you could deploy juddi.war and point it to the same registry database (or in jboss - versions newer then 4.0.2 you already have juddi build-in when running 'all'.). Now you have a soap webservice you can go to (for UDDI).

      Do these scenarios seem right? Does it cover all real world needs? BTW I'm not talking about clustering and/or caching, we can worry about that later.

      We could take it to the next level and bring up a Registry Service in the JBossESB. All clients can/should connect to this one and it can query to other registries in your business. If we do this, what kind of XML protocol should we support? Our own, or both UDDI and ebXML. Do we need something like this for the GA release?

      I'd love some feedback on this :).

      --Kurt

        • 1. Re: Registry Service Design
          marklittle

           

          "kurt.stam@jboss.com" wrote:
          We will soon have an embeddedable JAXR/UDDI component using Apache Scout as the JAXR implementation, a local transport implementation to support local java calls, and a slightly modified jUDDI to support these direct java calls (and soon there after hopefully RMI calls too). OK so far so good. Now the ESB has access to any kind of XML registry (it'd be ebXML or UDDI), and by default it will use embedded jUDDI.

          Now what if other systems want to access this registry?


          As long as the registry implementation is pluggable, then anyone who wants to replace our out-of-the-box implementation with their own will have to determine the best deployment configuration for themselves. This works fine as long as the interface we're using (JAX-R) does not expose any deployment/implementation choices: I assume it doesn't.

          What I'm driving at is that as long as the interface is right, this is just another server and clients/services don't need to know (probably couldn't care) whether it is co-located or running in another address space.

          So what you're asking below is really specific to our out-of-the-box deployment, true?


          I see 3 scenarios of how you could do this:
          1. If the registry is embedded, those systems can use JAXR and RMI (Scout with our RMI-Transport) to connect to the UDDI embedded in the JBossESB.
          2. Those systems can call to their very own embedded jUDDI, which is configured to use the same database. Or use their own registry database with somekind of replication.
          3. What if the client is not java based? Then you could deploy juddi.war and point it to the same registry database (or in jboss - versions newer then 4.0.2 you already have juddi build-in when running 'all'.). Now you have a soap webservice you can go to (for UDDI).


          I think this covers the bases as far as the 4.0 GA is concerned: shared or independent deployments. We just need to make sure that we can support those configurations fairly easily as far as the user is concerned, i.e., "use this config for a single shared Registry Service, and this one for independent co-located Registry Service".


          Do these scenarios seem right? Does it cover all real world needs? BTW I'm not talking about clustering and/or caching, we can worry about that later.

          We could take it to the next level and bring up a Registry Service in the JBossESB.


          We definitely need to support that.


          All clients can/should connect to this one and it can query to other registries in your business. If we do this, what kind of XML protocol should we support? Our own, or both UDDI and ebXML. Do we need something like this for the GA release?

          I'd love some feedback on this :).

          --Kurt


          The default deployment for our Registry Service should be a single instance per ESB. That's the easiest for people to understand and manage. Once we go beyond the GA, we can add in caching, fault tolerance etc.

          What do you mean by "what kind of XML protocol"?

          • 2. Re: Registry Service Design
            kurtstam

            So forget my comment about which protocol to use, as I see it now the Registry Service will be a service that will return a stub to a JAXR java instance.
            Basically this will cover scenario 1 and 2, for scenario 3 you will need to deploy the juddi.war and you can talk to jUDDI directly using SOAP. SO let's focus on how this service is going to be initialized. Basically we need a bootstrap process to set a number of Properties.

            1. javax.xml.registry.queryManagerURL, which is the inquiryURI
            2. javax.xml.registry.lifeCycleManagerURL, which is publishURI
            3. javax.xml.registry.factoryClass, which defined the inplementation of the ConnectionFactory (this is the configuration to set Scout as our JAXR implementation). It's going to be unlikely that you would not be using scout, but it should be possible to switch out.
            4. scout.proxy.transportClass, if you do use scout you need to provide the mode of transport between Scout and the UDDI (SOAP, SAAJ, Local, RMI).


            These four parameters can be set in
            - the conf/jbossesb.properties file. This sets them an System.properties for the ESB context.
            - for standalone clients they should be set in the startup script as system parameters.

            The same bootstrap process will read these parameters. How does this relate to the PropertyManager?

            How are we going to do Security for November? Are username/password going to be bootstrap parameters too, or will we provide another mechanism?

            --Kurt

            • 3. Re: Registry Service Design
              marklittle

               

              "kurt.stam@jboss.com" wrote:
              So forget my comment about which protocol to use, as I see it now the Registry Service will be a service that will return a stub to a JAXR java instance.
              Basically this will cover scenario 1 and 2, for scenario 3 you will need to deploy the juddi.war and you can talk to jUDDI directly using SOAP. SO let's focus on how this service is going to be initialized. Basically we need a bootstrap process to set a number of Properties.

              1. javax.xml.registry.queryManagerURL, which is the inquiryURI
              2. javax.xml.registry.lifeCycleManagerURL, which is publishURI
              3. javax.xml.registry.factoryClass, which defined the inplementation of the ConnectionFactory (this is the configuration to set Scout as our JAXR implementation). It's going to be unlikely that you would not be using scout, but it should be possible to switch out.
              4. scout.proxy.transportClass, if you do use scout you need to provide the mode of transport between Scout and the UDDI (SOAP, SAAJ, Local, RMI).


              It's always difficult to judge when there's no code or diagrams to look at ;-), but I've a question ...

              So if someone has their own non-Scout based UDDI implementation (specifically Systinet UDDI), they'll be able to plug that into the bootstrap process and it'll just work (tm)? I know this is something we discussed but I just want to double check.


              These four parameters can be set in
              - the conf/jbossesb.properties file. This sets them an System.properties for the ESB context.
              - for standalone clients they should be set in the startup script as system parameters.

              The same bootstrap process will read these parameters. How does this relate to the PropertyManager?


              Funny you should ask. I'm in the process of adding an entry on the PropertyManager.


              How are we going to do Security for November? Are username/password going to be bootstrap parameters too, or will we provide another mechanism?


              Before giving some suggestions: Security for what specifically?

              • 4. Re: Registry Service Design
                kurtstam

                1. I have added some diagrams here https://labs.jboss.com:443/wiki/JudyEvaluation

                2. You should be able to plug in any UDDI. Then there is the 'Systenet Client' which is their own Java API, which is not a JAXR implementation. If it where you could have plugged it into the current design. Now the client useless to us, however you should be able to use Scout to gwt to their UDDI, using SOAP.

                3. For security I was thinking about who can get access to the different (business) services, and what framework we are going to use. WHat endpoint can be used by what requestor.

                • 5. Re: Registry Service Design
                  marklittle

                   

                  "kurt.stam@jboss.com" wrote:
                  1. I have added some diagrams here https://labs.jboss.com:443/wiki/JudyEvaluation

                  2. You should be able to plug in any UDDI. Then there is the 'Systenet Client' which is their own Java API, which is not a JAXR implementation. If it where you could have plugged it into the current design. Now the client useless to us, however you should be able to use Scout to gwt to their UDDI, using SOAP.


                  OK. Do you know if anyone has actually done this?


                  3. For security I was thinking about who can get access to the different (business) services, and what framework we are going to use. WHat endpoint can be used by what requestor.


                  So this is security in general, rather than security for the registry service?

                  • 6. Re: Registry Service Design
                    kurtstam

                     

                    Do you know if anyone has actually done this?

                    You mean you're afraid scout is not mature enough? I can post this question on the scout user mailing list if you want.

                    So this is security in general, rather than security for the registry service?

                    Yeah I always like to see the big picture first.

                    Juddi only worries about having the publisher's id, however we could use this http://wiki.apache.org/ws/Using_JBoss_to_Authenticate_Users, but all of this is very jUDDI specific.
                    [/url]

                    • 7. Re: Registry Service Design
                      marklittle

                       

                      "kurt.stam@jboss.com" wrote:
                      Do you know if anyone has actually done this?

                      You mean you're afraid scout is not mature enough? I can post this question on the scout user mailing list if you want.


                      Yes, that would be good, thanks.


                      So this is security in general, rather than security for the registry service?

                      Yeah I always like to see the big picture first.


                      We definitely need a more general approach to security, but that isn't going to happen in the 4.0 timeframe. For example, whatever we do needs to tie into WS-Sec.


                      Juddi only worries about having the publisher's id, however we could use this http://wiki.apache.org/ws/Using_JBoss_to_Authenticate_Users, but all of this is very jUDDI specific.
                      [/url]


                      Given time contraints, it may be worth going down this route for now. Whatever we do at this stage will get re-worked for the next release, I'm fairly sure.

                      • 8. Re: Registry Service Design
                        kurtstam

                        To trigger the bootstrap process we need something that gets run at deploytime. The use of a sar for would be nice. Are there any objections to use mbeans in our deployment architecture?

                        --Kurt

                        • 9. Re: Registry Service Design
                          marklittle

                          Given the current nature of our deployments, that sounds reasonable. Not sure about longer term, but that's something we can revisit when/if necessary.