Kurt, the jUDDI API Service has the following methods adminDelete_tmodel delete_ClientSubscriptionInfo delete_publisher get_allPublisherDetail get_publisherDetail invoke_SyncSubscription save_Clerk save_ClientSubscriptionInfo save_Node save_publisher
Which method is the one you're referring to: "subscriptions between jUDDI nodes, where client info is exchanged." On Thu, May 30, 2013 at 10:51 AM, Kurt Stam <[email protected]> wrote: > 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? >>> >>>
