[prev in list] [next in list] [prev in thread] [next in thread] 

List:       scout-dev
Subject:    Re: Deprecate the jUDDI API?
From:       "Alex O'Ree" <spyhunter99 () gmail ! com>
Date:       2013-05-30 22:20:45
Message-ID: CALLT8khonZgcVsghkOoHcnG2pY0ga3m9CSzB1=+qJ_WSBW3g-Q () mail ! gmail ! com
[Download RAW message or body]

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 <kurt.stam@gmail.com> 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" <spyhunter99@gmail.com> 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 <tcunning@redhat.com> 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?
> > > 
> > > 


[prev in list] [next in list] [prev in thread] [next in thread]