juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Scout and jUDDI
Date Thu, 18 Aug 2005 14:32:26 GMT
Guillaume,

If you sign up for the additional work :) then you can have it :) :)
Seriously, am looking forward to improving both projects AND looking
forward to more participation from redhat and objectweb.

-- dims


On 8/18/05, Steve Viens <sviens@gmail.com> wrote:
> Initially we developed Scout on top of jUDDI in order to quickly produce a
> type 0 JAXR provider.  Type 0 (zero) providers support accessing UDDI
> registries only.  The goal however is for Scout to become a type 1 provider
> which would include support for both UDDI and ebXML registries.  
>   
> As you would probably expect, there are no plans for jUDDI to support ebXML.
>  If a move to an XMLBeans would enable Scout to support both UDDI and ebXML
> (a type 1 provider) then I'm in favor of a move to XMLBeans and eliminating
> Scout's dependency on jUDDI. 
>   
> Steve
>  
>   
> On 8/18/05, Fernando Nasser <fnasser@redhat.com> wrote: 
> > Davanum Srinivas wrote:
> > > Fernando,
> > >
> > > Please include everyone's view point. If people who use juddi want to 
> > > use scout they should not have to include xmlbeans jars (EXACTLY the
> > > way you don't want to use juddi jars). So best case scenario here is
> > > to have a pluggable way in scout to do either xmlbeans or juddi types. 
> > > No one is going to complain that way. Please let me know if this is ok
> > > for you.
> > >
> > 
> > It actually seems that the types used by jUDDI are unrelated (i.e. they
> > should be) to the ones used by Scout (except for some JARX types to UDDI 
> > or ebXML mapping defined by the JAXR spec).
> > 
> > Scout and jUDDI should only communicate using SOAP messages and be
> > completely independent code-wise.
> > 
> > So jUDDI can continue to use its own types (UDDI types?) and Scout can 
> > switch to the more independent XMLBeans, as it should not be using any
> > UDDI or ebXML type internally.
> > 
> > Does that make sense?
> > 
> > 
> > 
> > > -- dims
> > >
> > > On 8/18/05, Fernando Nasser < fnasser@redhat.com> wrote:
> > >
> > >>Hi Anil,
> > >>
> > >>Anil Saldhana wrote:
> > >>
> > >>>Scout 0.5 release will be done the way it is.
> > >>>
> > >>
> > >>0.5 ?
> > >>
> > >>But your trunk/etc/project.xml already says
> > >>
> > >><currentVersion>1.0-SNAPSHOT</currentVersion>
> > >>
> > >>As a result Apache Geronimo and ObjectWeb JOnAS, as well as Red Hat 
> > >>RHAPS and the JPackage.org RPM of Scout have all been labeled
> > >>1.0-SNAPSHOT (+date).
> > >>
> > >>Going back to anything less then 1.0 now will break everybody's
> > >>dependency checks. 
> > >>
> > >>Can't you continue to use 1.0-SNAPSHOT until you are ready for 1.0?
> > >>
> > >>
> > >>
> > >>>Once we add the asynchronous feature  required by the
> > >>>JAXR 1.0 spec, we will do the Scout 1.0 release.
> > >>>
> > >>>Before we do the 1.0 release, we can see if there is
> > >>>really any major incentive in removing the juddi data
> > >>>types and bringing in XMLBeans.
> > >>> 
> > >>
> > >>A major incentive: not bringing the juddi jar into the classloader space
> > >>of anyone who wants to use Scout, perhaps even with some other Directory
> > >>service different from jUDDI. 
> > >>
> > >>I was talking to Guillaume on irc and we think that a complete
> > >>separation between Scout and jUDDI would be ideal.
> > >>
> > >>
> > >>
> > >>>At Scout and jUDDI, we have always fostered pluggable 
> > >>>deployments.
> > >>>
> > >>
> > >>But in this specific case, there doesn't seem to be any advantage at all
> > >>in providing pluggable _internal_ types.
> > >>
> > >>
> > >> 
> > >>>Using juddi data types is an internal implementation
> > >>>detail of Scout.  So there are no issues with using
> > >>>XMLBeans as an internal implementation detail. But we
> > >>>need to investigate and test. 
> > >>>
> > >>
> > >>Right.  We would be willing to help changing the types if everyone is in
> > >>accordance with that.
> > >>
> > >>
> > >>
> > >>>I will have to look at XMLBeans a bit further. 
> > >>>
> > >>
> > >>Thank you.
> > >>
> > >>
> > >>Best regards,
> > >>Fernando
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>--- Fernando Nasser < fnasser@redhat.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>>>Davanum Srinivas wrote:
> > >>>>
> > >>>>
> > >>>>>Fernando,
> > >>>>> 
> > >>>>>then folks who primarily use juddi and want to use
> > >>>>
> > >>>>scout on the client
> > >>>>
> > >>>>
> > >>>>>will have one less library to deal with :) 
> > >>>>>
> > >>>>
> > >>>>Are you saying that you agree with using XMLBeans
> > >>>>and dropping the jUDDI
> > >>>>types (on both sides, Scout and jUDDI of course)? 
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>-- dims
> > >>>>>
> > >>>>>On 8/17/05, Fernando Nasser < fnasser@redhat.com>
> > >>>>
> > >>>>wrote:
> > >>>>
> > >>>>
> > >>>>>>Dims,
> > >>>>>>
> > >>>>>>I may be missing something because I don't know 
> > >>>>
> > >>>>all the details, so
> > >>>>
> > >>>>
> > >>>>>>please forgive me if it is a silly question.
> > >>>>>>
> > >>>>>>If we have APL more or less standard types from 
> > >>>>
> > >>>>Apache XMLBeans, why do
> > >>>>
> > >>>>
> > >>>>>>we need to have the option of using jUDDI own
> > >>>>
> > >>>>types? 
> > >>>>
> > >>>>
> > >>>>>>Why not just drop the non-standard jUDDI types and
> > >>>>
> > >>>>plainly switch
> > >>>>
> > >>>>
> > >>>>>>everything to use XMLBeans only ( a "de facto" 
> > >>>>
> > >>>>standard)?
> > >>>>
> > >>>>
> > >>>>>>Best regards,
> > >>>>>>Fernando
> > >>>>>>
> > >>>>>> 
> > >>>>>>
> > >>>>>>Davanum Srinivas wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>As long as it's pluggable (use XMLBeans OR 
> > >>>>
> > >>>>jUDDI), Am ok.
> > >>>>
> > >>>>
> > >>>>>>>thanks,
> > >>>>>>>dims
> > >>>>>>>
> > >>>>>>>On 8/12/05, Guillaume Sauthier 
> > >>>>
> > >>>><Guillaume.Sauthier@objectweb.org> wrote:
> > >>>>
> > >>>>
> > >>>>>>>>Hi guys 
> > >>>>>>>>
> > >>>>>>>>We want to integrate Scout in JOnAS as a
> > >>>>
> > >>>>replacement for the JAXR
> > >>>>
> > >>>>
> > >>>>>>>>Reference Implementation. 
> > >>>>>>>>With Scout we can get ride of JAXB-RI too (used
> > >>>>
> > >>>>by JAXR-RI) and use OSS :)
> > >>>>
> > >>>>
> > >>>>>>>>Scout has been very easily embed in JOnAS as a 
> > >>>>
> > >>>>ResourceAdapter and seems
> > >>>>
> > >>>>
> > >>>>>>>>to work very well, thanks to your hard work: )
> > >>>>>>>> 
> > >>>>>>>>We can see that Scout depends on jUDDI, and
> > >>>>
> > >>>>jUDDI depends on many
> > >>>>
> > >>>>
> > >>>>>>>>jakarta commons libs. 
> > >>>>>>>>
> > >>>>>>>>Given the JOnAS ClassLoader architecture, the
> > >>>>
> > >>>>Scout RA (and all
> > >>>>
> > >>>>
> > >>>>>>>>depending libs : scout, juddi, common-*, ...) 
> > >>>>
> > >>>>will be loaded in a
> > >>>>
> > >>>>
> > >>>>>>>>'commons' ClassLoader, this is a top level
> > >>>>
> > >>>>Loader. 
> > >>>>
> > >>>>
> > >>>>>>>>So, if a user package his/her application/webapp
> > >>>>
> > >>>>with a lib already
> > >>>>
> > >>>> 
> > >>>>>>>>provided by JOnAS (version can differ) there can
> > >>>>
> > >>>>be a conflict!
> > >>>>
> > >>>>
> > >>>>>>>>More, if a user want to change the jUDDI 
> > >>>>
> > >>>>(webapp) version, he can't do
> > >>>>
> > >>>>
> > >>>>>>>>that (classes in top level loader are always
> > >>>>
> > >>>>loaded first) ! 
> > >>>>
> > >>>>
> > >>>>>>>>As we want to interfere a minimum with the
> > >>>>
> > >>>>classes packaged in our
> > >>>>
> > >>>> 
> > >>>>>>>>user's application, in order to avoid conflicts,
> > >>>>
> > >>>>we want to remove the
> > >>>>
> > >>>>
> > >>>>>>>>dependency on jUDDI. 
> > >>>>>>>>
> > >>>>>>>>To do this, we will have to rewrite some kind of
> > >>>>
> > >>>>RegistryProxy, avoid
> > >>>>
> > >>>>
> > >>>>>>>>the use of jUDDI's handlers and datatypes, ...
> > >>>>>>>>We thought to use xmlbeans as a replacement for
> > >>>>
> > >>>>UDDI datatypes
> > >>>> 
> > >>>>
> > >>>>>>>>I want to know what do you think of this
> > >>>>
> > >>>>proposal ?
> > >>>>
> > >>>>
> > >>>>>>>>I think it can be useful for geronimo guys too 
> > >>>>
> > >>>>(and for the same
> > >>>>
> > >>>>
> > >>>>>>>>classloader reasons).
> > >>>>>>>>
> > >>>>>>>>Regards 
> > >>>>>>>>Guillaume
> > >>>>>>>>
> > >>>
> > >>>
> > >>>__________________________________________________
> > >>>Do You Yahoo!?
> > >>>Tired of spam?  Yahoo! Mail has the best spam protection around 
> > >>>http://mail.yahoo.com
> > >>>
> > >>
> > >>--
> > >>Fernando Nasser
> > >>Red Hat Canada Ltd.                     E-Mail:   fnasser@redhat.com
> > >>2323 Yonge Street, Suite #300
> > >>Toronto, Ontario   M4P 2C9
> > >>
> > >
> > >
> > >
> > 
> > --
> > Fernando Nasser
> > Red Hat Canada Ltd.                     E-Mail:   fnasser@redhat.com
> > 2323 Yonge Street, Suite #300
> > Toronto, Ontario   M4P 2C9
> > 
> 
>  


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

Mime
View raw message