Hi Kurt, Thanks for your response. I started looking into setting up a workspace, but I have to do it on my own time (not my client's). And it will take time for me to get up to speed... I still work with CVS (and have worked with ClearCase in the past) so I'm new to Maven. I'll be doing a demo later today of what we have with jUDDIv3 (with a couple of manually entered services using SOAPUI) and if the client wants to proceed, then I'll be more motivated to get the WSDL2UDDI class more solid since it will help us to implement. Not all of of the services are Java-based, so the annotations are not helpful and besides they host the services (endpoints) on 2 different ESB's, which only talk UDDIv2...so they really need an easy way to just register the WSDL's into the UDDI using the WSDL's URL. Bottom-line is this may not top the client's priority list, so I may not be able to help with your 4-6 week release timeframe :(
Thanks Kurt, Jeff. Jeffrey L. McCain cell : 518-428-8765 From: Kurt T Stam <[email protected]> To: [email protected] Date: 04/23/2012 09:50 PM Subject: Re: questions about jUDDIv3 future Hi Jeffrey, Was my response helpful? I think we will be releasing 3.1.4 in 4 to 6 weeks or so. Are you interested to make a contribution? It'd be great to get the WSDL2UDDI completed and hooked into the annotations (JUDDI-514). Also I hooked up gwt-validation, so this enables the road to edit functionality for the console. I can assign some jiras to you, and you can attach patches to earn commit rights. Cheers, --Kurt On 4/19/12 2:58 PM, Kurt T Stam wrote: On 4/19/12 2:43 PM, Jeffrey L McCain wrote: Hello, I've been exploring various UDDI solutions and I think jUDDIv3 is a good solution, but I have some concerns. 1) I've seen it stated that "jUDDIv3 only supports the UDDI v3 protocol". I've seen this in action as I cannot use the Eclipse Web Services Explorer or the Oracle Service Bus 11g to connect to jUDDIv3. It would seem that there are tons of UDDIv2-based products already out there and that jUDDIv3 not supporting them is a big limitation. The problem seems simple (on the surface) to solve...allowing the old v2-namespace-service calls to still occur in the jUDDIv3...basically exposing the old v2 services, but call the newer implementation code? Is there a reason this was not allowed (in the spec)? There is no reason other then time to implement. jUDDIv3 is JAX-WS/JAXB based, jUDDI v2 had a home grown UDDI Servlet. It should not be that hard to make it speak UDDI v2. In fact the wrapper classes for JAXR pretty much do this already. So you could use that to build a v2 proxy. Or extent the JAX-WS/JAXB layer itself to support UDDI v2, which would be the cleanest option. 2) There is a nice .class under development in the uddi-client code called "WSDL2UDDI.java", but it only implements 2 of the 5 parts required to represent a Web Service in the UDDI data structure. Is anybody working on this currently? (I know that since this is open-source I should finish it myself ;) and submit it, but before I spend time on it, I'd like to know if its already in the works...especially since it was last touched in about January?) Yes this works it is in use by the BPEL2UDDI, which is used by the Riftsaw/Apache ODE project to register BPEL processes. It'd be great to get a contribution to finish the WSDL2UDDI class. 3) The portal console is nice, but it does not replace the functionality that was in the v2 console which let you invoke every method. The only way to publish a service now is programatically. Is there anything in the works on this one? You can use tooling like SOAPUI which does pretty much the same as the old v2 console. That said, we'd love to add create/edit functionality to the portal console, and welcome contributions. Note that we've developed the annotations, so you can slap UDDI annotations on your webservices to do auto-registration on deployment of the services. Thanks! Jeffrey L. McCain Hope this helps. Cheers, --Kurt
<<inline: graycol.gif>>
