On Fri, Jul 1, 2011 at 4:28 PM, Guillaume Nodet <gno...@gmail.com> wrote:
> I guess you missed in my first email one important fact. To build the
> added value I've been talking about, we don't really need the NMR
> imho. I'm convinced we can do it directly on top of camel without the
> need for another layer, mostly using Camel interceptors. That way,
> OSGi is not really needed anymore, though it's still the best way to
> deploy Camel routes using Karaf and would remain the main and
> standlone ServiceMix distribution.
>
>
I have read this thread regarding rebooting SMX and departure from the NMR,
and I've wondered if my experience with SMX 4 would help the discussion. I
think this may come across as a "dissenting opinion" on this proposal, but
please know that I am a HUGE SMX fan and am forwarding these opinions in the
best possible way I know how.
My experience with SMX has been 100% positive. In the business area I
worked
with SMX, and previously OpenESB, the use-case was much less
messaging-oriented
and more orchestration-oriented. Thus, we relied heavily on Apache ODE. It
turns
out, that Apache ODE is really good for one thing, and perhaps if Apache
Camel did
this one thing well+hassle-free, we would have used it and my experiences
would
have been different.
My worry with the proposal for SMX 5 and it's Camel-centricity is that I
have had
a great experience with SMX but I have never used Camel. We just didn't
need
what it had to offer.
The architecture looked like this:
- inbound requests secured with WS-Security. We used CXF binding
components
with a lot of Spring-DM configuration to allow externalized
configuration.
Really happy with all that.
- outbound external requests were also CXF, although we'd have a mixture
of authorization models where some components were using basic auth,
others
soap with custom auth, etc.
- some requests were directly routed to Java services if they were
small and synchronous-oriented (ie. call/response). We used cxf SE for
this.
- we used cxf proxy constructs to call from java to anything else. This
worked
well as we prototyped a bunch of stuff at times in java, and then when
we
needed asynchronous, long-running behavior, we moved those prototypes to
ODE.
- because everything was talking over the NMR, we could add intereceptors
to
the bus and monitor everything. We even had a policy-based audit
function
over the NMR that was very clever.
- we created a visualization mechanism for understanding the wires over
the NMR,
with an Apache Felix plugin. Alas, while I wanted to contribute that
work
back to the community, it can't happen now.
- "The main work" of the project was to orchestrate long running
processes.
Involved in this orchestration was wait-states for human interactions,
such
as approvals, escalations, remediations, etc. Apache ODE was a good
choice
here, because a persistent BPEL process instance that lands in a <pick>
construct has some nice qualities (ie. resilient to server restart).
Our
main process could have 10 or so steps in it, each one which may take
anywhere from seconds to days to run. All of these steps talked to
external
systems.
- a significant effort was involved in creating a normalization of
identity
concerns over the bus. I think in retrospect much of our work would
have
been alleviated had we taken the approach to patch certain components
instead
of relying on message exchange interceptors to do things "the hard
way".
Nevertheless, it's important to note that SMX provides an avenue for
dealing
with identity concerns, but doesn't quite get things right. Even so,
having
CXF and NMR sources around help you a lot, and you can glue things
together
with interceptors. I submitted a few patches here and there to ODE and
CXF
component (SE proxy, for example) that propate subject/identity
materials
better and I think it's getting there.
In all, I'd say the solution component demographic was as follows:
10% CXF, File, Quartz, non-Java components (ie. Spring-DM config)
20% Apache ODE
70% Java components (transformations, logic, policy-based routing, some
karaf commands, etc.)
Now, about the Java components, sure some of it could be message
transformation.
But the issue with that is that when you need to have mid-level programmer
talent
join a project, start contributing right away, and have no ESB background,
writing
something in Java many times is the right choice, simply because of the
debugger
support. To me, tooling is a much bigger issue than maybe the SMX and Camel
community realize. Writing a camel route would be applicable in some cases,
but
probably only 30% of this overall solution would fall in this category.
The main orchestration processes being done with Camel have some merit. I
think
this would be interesting, in that if Camel had a persistent equivalent to
BPEL
"<pick>", with message correlation, fault tolerance/resliency to system
restart,
that worked hassle-free and without too much assembly, it would be really
useful.
In talkingto James this I believe this is possible, but it's not obvious to
me how,
so it is really academic at this point.
I am no longer involved in this solution, so I'm not trying to entertain
"how would
I do all this in SMX 5 with Camel only?". What I'm trying to do is
highlight a
different, completely positive use case with SMX that doesn't involve Camel.
On
paper, I really like Camel but I haven't had any deep involvement with a
project
using it, so I just haven't formed an opinion on it--I'm positive but not
informed
I guess. In a world where the NMR goes away and Camel is at the forefront,
I'm
not sure this use-case would have been obvious and we may have not
considered
SMX at all, which would have been a shame.
As an aside, the positive reaction I had to all of this was experienced
while
learning OSGi, Karaf, etc., which was a steep curve, because we ended up
having to
create a fair number of bundles ourselves for libraries that SMX didn't
provide. That
being said, to me the SMX bundle repo is a HUGE salvation and should be
perhaps
spun off from SMX and made an Apache project of its own, similar to the
older
Spring Enterprise Bundle Repository (call it Apache EBR). Since Apache
maintains
so much build infrastructure and maven repos anyway, it would make sense to
have
the "bundlization" happen from an Apache project. I would think that as
projects
want to peel off the work from the Apache EBR, they should have a way to
manage
removing their components from the EBR and stamp their project as "OSGi
Ready".
Just a thought.
Hope this helps all and good luck,
Kurt
