9 Replies Latest reply on Mar 22, 2010 10:28 PM by kurtstam

    Usecase request: UDDI lookup of EndPoints


      I've been working on integration of UDDI into RiftSaw, and we now register BPEL EndPoints into jUDDI. We also have request to lookup EndPoints in UDDI, so I think the way this would work is:


      1. One deploys a BPEL service along with all the WSDLs of the EndPoints this service is going to call.


      2. When the BPEL process is about to call one of these EndPoints, we would extracts the service name from the packaged up WSDL, then we would use this name to query the UDDI, and get back the BindingTemplate(s) which contains the URL of the WSDL of the remote WebService.


      3.If there are more then one BindingTemplates we need somekind of policy as to which one to take (FirstAvailable, RoundRobin, RandomRobin)

      We then take this URL and obtain the 'fresh' WSDL, from which we obtain the physical EndPoint.


      Does this make sense?


      The upside of this is that if WebServices relocate over time the BPEL process would keep on running.


      The downside is that it will be a bit slower since we now do UDDI lookups with each call, we probably need to cache. Also we will need to deal with stale EndPoint information. Basically the stuff the ServiceInvoker deals with in JBESB.


      I'd love to get some feedback on the use-cases this feature to figure out what it is we really need to implement here.





        • 1. Re: Usecase request: UDDI lookup of EndPoints

          I think this covers the main use-case, which is to enable the BPEL process designer to avoid having to explicitly define the address of the service being invoked.


          However I am unclear about what gets stored in UDDI. Normally a WSDL can have a service (with name) which can have multiple named ports, which can each have a URL.


          So if you only have a service name for the UDDI lookup, where the service has multiple ports, what do you receive back? Do you need to use the portname as part of the UDDI lookup?


          Yes agree some form of caching will be required - and the UDDI lookup approach should only be used in cases where the soap:address has not been explicitly provided in the invoked WSDL (that is packaged with the BPEL process).

          • 2. Re: Usecase request: UDDI lookup of EndPoints

            Here is a nice writeup on what should get stored about a WebService: http://soa.sys-con.com/node/39868. The thing I'm concerned about is that we can really only rely on consist information in the UDDI if we do the registration ourselves through the 'auto-registration' on deployment I was talking about.Then looking up by serviceName my lead to getting duplicate services back. Since different businesses can register the same serviceName. Also the auto registration process heavily relies on the WSDL info being correct, and the port info being correct. So if you have the correct WSDLs why wouldn't you package those in the BPEL service. I'm obviously a proponent on using UDDI, I just want to make something that is going to solve a problem, make things easier,  and not something that ends up "being in the way", and it is "over complicating" things.



            • 3. Re: Usecase request: UDDI lookup of EndPoints

              I think the problems you raise is what governance should eventually solve - to ensure the information in the registry is valid.


              However we need an ability to do late binding of web service addresses, so the approach you have outlined seems to be the best option.

              • 4. Re: Usecase request: UDDI lookup of EndPoints
                While not the responsibility of the Riftsaw team, would it make sense for the ESB team to register the WSDLs that it generates(e.g. EBWS) according to the principles outlined in the article Kurt referred to? This would at least allow us to test the solution Kurt describes against properly registered services.
                • 5. Re: Usecase request: UDDI lookup of EndPoints

                  1. I think the jUDDI annotations are a better option then to burden ESB with it. As long as there is a file for the WebService to which a developer can add the annotations then we should be all set.


                  2. Can we add some information about the service in the BPEL deployment? i.e. Can we add a category somewhere in the BPEL metadata?



                  • 6. Re: Usecase request: UDDI lookup of EndPoints



                    There is no file to annotate in the case of EBWS or SOAPProxy, etc.



                    • 7. Re: Usecase request: UDDI lookup of EndPoints

                      1. Is there a deployment event we can hook into?


                      2. Also I think I may be have been too negative about the lookup if we do a full WSDL registration (as described in the link above) as we can add things like namespace etc to the lookup.



                      • 8. Re: Usecase request: UDDI lookup of EndPoints
                        Yes, both EBWS and SOAPProxy generate a WSDL at deployment time (the former from XSDs referenced in the jboss-esb.xml and the latter from an existing WSDL that is proxied, also referenced in the jboss-esb.xml). In the first case the WSDL is in the deploy/data/wsdl directory (in the latter I don't actually know where to find the wsdl). The exact mechanics of how this takes place I don't know (never reviewed the source), so you would need to get with Kevin and David respectively.
                        • 9. Re: Usecase request: UDDI lookup of EndPoints

                          http://jira.jboss.org/jira/browse/RIFTSAW-158. The lookup code is now checked in. I still need to come up with a solution to auto-register WS proxies on the ESB side, but we should have lift off now.