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 15:12:12 GMT
+1 :)

On 8/18/05, Anil Saldhana <anilsaldhana@yahoo.com> wrote:
> A good step would be for Guillaume to submit his work
> involving JCA as a contribution to Apache so that we
> can use it in Apache Scout. Then the customer will
> have the choice of plug and play.
> 
> --- Davanum Srinivas <davanum@gmail.com> wrote:
> 
> > 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>
> >
> === message truncated ===
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 


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

Mime
View raw message