Thank you and to the others responders as well, this was very helpful.
We're leaning towards JBI at the moment, the primary reason being more
integration related options down the road. However Axis2 is in close second
and we'll be ready to move to that approach if the benefits of JBI (in our
case) get buried by the complexities / glue code / tweaks as you mention.
I have also gotten the same impression about WSDL 1.1 and WS-I being less of
a priority in the JBI realm at the moment. In that regards Axis2 is an
attractive option, since basic web service interop will likely be less
painful. I would say Axis2 gained some ground on JBI for our situation.
Thanks, Rich
On 4/17/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Hi Rich,
I'll go with a more philosophical answer instead of a blow-by-blow feature
list and stipulate that your choice should be based on the architectural
style that best suit your problems and goals. Axis2 as a framework
promotes
the use of {standards-based, loosely coupled, interoperable} web services.
JBI on the other hand promotes tighter coupling and focuses on Java
integration.
In theory, JBI delivers better performance than your average WS stack
because of in-VM invocation, XML streaming and object passing. The
reality
is the performance difference is minimal. XML streaming has limited
performance impact when you're actually processing the data (e.g.
evaluating
business rules) and persisting state such as with BPEL. So far, I have
seen
more Ode deployments where JBI performs worse than Axis2.
In theory, JBI provides as-good-as-anything-else WS interoperability. In
reality, JBI implementations have put end-to-end interoperability as
second
goal, and have focused on WSDL 2.0 rather than the pragmatic WSDL 1.1 +
WS-I
combo. Sadly, few JBI components interoperate without glue code or
configuration tweaks.
In theory, JBI scales better because <insert your vendor> has implemented
this sooper-scalable message bus that does transparent clustering. The
reality is that both JBI and WS stacks (incl. Axis2) provide architectures
that scale very well if you use them wisely. WS stacks leverages proven
internet clustering infrastructure (e.g. HTTP load balancing) while JBI
tends to go down the also-proven JMS route. (Both offer more options but
these are the solutions you'll see most often)
Of course, the theory with WS stacks (incl. Axis2) is that everything
looks
like a web service. If you ain't got that WSDL, you ain't going
anywhere...
so WS stacks gently push you to expose everything as a web service. This
can require significant investments but once you've done it, I think
you'll
be glad you did because all of a sudden everything can talk to everything
(you've followed the WS-I spec, I hope?).
Another issue is that not everything needs to be, or should be, a web
service. This applies to JBI, Axis2 and Ode/BPEL as well. There's a case
for programming-in-the-large (coarse-grained services) as much as for
programming-in-the-small (POJOs, libraries, and native language
components). Regardless of your choice, you'll need more than one tool in
your toolbox.
Personally, I've found JBI to be more apt in integration scenarios and
Axis2
to be better at exposing and consuming business services.
regards,
alex
On 4/16/07, Rich Taylor <[EMAIL PROTECTED]> wrote:
>
> Hello All,
>
> We're planning on using Ode and are trying to understand the pros/cons
of
> using Ode with Axis2 vs. Ode with ServiceMix / JBI. Here is my
> understanding at this point, it would be great if you could let me know
> how
> far off I am and if there is something I'm mixing. This is something
that
> might end up being valuable for others trying to make the same decision
as
> well.
>
> Pros of Ode in Axis2
> - Ease/simplicity of Process deployment (no service assemblies, units,
> etc.,
> just drop your process into "processes" folder)
> - Overall a simpler of an environment to work in
> - Management API is available, at least as web services at this point
>
> Pros of Ode in JBI / ServiceMix
> - Availability of more advanced features such as clustering
> - Availability of more service transports such as JMS, XMPP, email for
> your
> BPEL both receiving message and invoking other services
>
> How have others chosen which Ode distribution to go with?
>
> Cheers,
> Rich
>
