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
