juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Cutright" <Andy.Cutri...@borland.com>
Subject RE: jaxr implementation
Date Tue, 06 Apr 2004 15:23:50 GMT
bringing together steve's thoughts and your thoughts anou, the uddi4j
wrapper idea has the advantage of using heavily tested code. there's
some discussion in the JAXR spec about a pluggable architecture, but i
don't know where to look for current JAXR committee activity. all the
email lists seem to be archives, not active lists. 

if we as a team want to go with the juddi proxy stuff, that's OK with

still not clear on JAXME, though i have not downloaded it, which makes
me an expert ;) there's only 30-40/ interfaces, and i guess i've not
seen an XML spec that we can feed to JAXME. it appears to me we're
mostly going to write a bunch of stub code, which we'd be able to do by
hand reasonably quickly. this isn't something we're going to repeat, so
learning the new tool doesn't make much sense to me, but if someone
wants to, have fun :) i contrast this with using forrest, where we
simply had to learn the tool to play nicely, and forrest must always be
used to update the website.. 

do y'all agree with targeting these four initial methods as a
white-board exersize, and then fleshing out a healthy architecture? we'd
also be able to explore the 'JAXR Pluggable Provider' interface (pg 26
JAXR spec). 

yes, JAXR feels like a separate project eventually to me. making the
code base changes is fine by me. 

anyone know anything about ebXML? wonder if there's an open source
developer community we can leverage... 


> -----Original Message-----
> From: Anou Manavalan [mailto:anou_mana@hotmail.com] 
> Sent: Tuesday, April 06, 2004 6:44 AM
> To: juddi-dev@ws.apache.org
> Subject: RE: jaxr implementation
> Andy,
> This is what I thought. JAXR is a generalization spec and UDDI is the 
> specialized one. jUDDI is implemented as per spec. If we wrap 
> UDDI4J, it 
> will be one more layer in between them. Which will work, but 
> I am not sure 
> it will be great, it will add an extra baggage in terms of 
> processing and 
> also maintaing some one else's code.
> With JaxMe, you should be able to feed the JAXR spec and get 
> the classes 
> created for you depending on the spec, which I thought is a 
> good way to go 
> if we have to adhere to a spec and also it would leverage the 
> use of another 
> Apache product.  Even though we use JaxMe we are not stuck 
> with it, since 
> once the classes are created, we won't need them much, till the spec 
> changes.
> And once we have the classes, the final thing to do is to 
> talk to jUDDI, I 
> was thinking of taking some of the code from our proxy classes ( not 
> wrapping them exactly, but using the code base ).
> What do you guys think ?
> regards,
> -Anou

View raw message