incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject RE: [PROPOSAL] CeltiXfire Project
Date Wed, 21 Jun 2006 18:04:50 GMT
On Wed, 2006-06-21 at 13:44 -0400, Sakala, Adinarayana wrote:
> > Trying myself, I've always understood XFire to be a direct alternative
> > for Axis1 (I have yet to get to grips with Axis2, but I assume
> > some of the same is true there), aka a "SOAP stack". Is that somewhat
> > true? And then, is Celtix such a beastie as well?
> Celtix includes SOAP stack capability when needed but it is not simply
>  a SOAP stack.  Celtix is a pluggable infrastructure that allows
>  transports and bindings to be plugged but yet decoupled from one
>  another via configuration files. Best example of this is, Celtix
>  service can be made available via CORBA for communication, this is
>  completely done by configuration. This is achieved by combining Celtix
>  and Apache Yoko. >From my point of view supporting alternative ways of
>  communication is real key especially when talking about a SOA
>  Infrastructure that provides extensibility for legacy integration.

Did you mean "Celtixfire" when you said "Celtix" in the above para? 

I'm a bit confused how if the whole thing is a big pluggable,
multi-proto framework then why its necessary or important for Celtix and
XFire to be in the same project. Isn't XFire a component of that
framework? Is that the plan for how to go forward- that XFire lives on
inside of Celtix and this is an umbrella project structure?

In any case, the framework part seems just like what JBI impls like
ServiceMix are doing and what JBI alternates like SCA (Tuscany) are
doing. Since James is a mentor of this maybe he can explain the
relationship (or lack thereof) between Celtixfire and ServiceMix. It
would be great if Jeremy (or some other Tuscanite) could explain how
this relates to Tuscany as well. 



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message