One complication we need to address as part of this is around subscriptions between jUDDI nodes, where client info is exchanged. I hear you talk about 2 things
- move the jUDDI-API to it's own module/jar (so no functional changes, but making dependencies more clear. - depreciate the jUDDI API altogether and use straight DB access rather then going through the WebServices layer. Which one are we talking? --K On May 30, 2013, at 9:57 AM, "Alex O'Ree" <[email protected]> wrote: > Admin user interface is in the works, I'm actually just starting it > now. A lot of stuff will be borrowed some the juddi-gui mod as well as > other existing stuff, so it should go pretty quickly. Again, we'll > still need the code because it's primarily admin based stuff. The > discussion is really, do end users really need access to it as a web > service? Maybe, maybe not. > > TCK tests shouldn't be affected by it. > > On Thu, May 30, 2013 at 9:49 AM, Tom Cunningham <[email protected]> wrote: >> >> I don't see many reasons against removing the juddi-api but maybe it makes >> hemore sense to wait to remove it till a replacement is available in the >> administrative user interface? The backwards compatibility argument >> seems a lot stronger if you have a replacement in hand. >> >> Is removing it going to affect any of the tests? I can't remember if >> any of them are using it in setup. >> >> >> >> On 5/29/13 7:50 PM, Alex O'Ree wrote: >>> >>> A while, I had a conversation with Kurt on IRC about possibly >>> deprecating and/or removing the jUDDI API web service from the 3.2 >>> release. I'm personally for this decision and would suggest removing >>> it (from the juddi-client and uddi-ws package) as there's isn't much >>> value added to it from and end user's perspective. They are all >>> administrative functions. >>> >>> I would suggest as follows: >>> 1) remove the juddi API web service references from the client and >>> uddi-ws package >>> 2) repackage the juddi API web service client side stuff as a seperate >>> jar file, just in case anyone needs backwards compatibility. >>> 3) continue to deploy the web service within juddi-war >>> 4) continue to build an administrative user interface. See JUDDI-455, >>> JUDDI-579, JUDDI-607. This will greatly aid system administrators. >>> These functions can simply reuse the code from jUDDI API web service >>> 5) finally, document the changes >>> >>> This is open for discussion, but I just wanted to get the ball rolling >>> on this one. Any thoughts or opinions on this? >> >>
