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. Thanks! Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
