cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: How to consume JMS services
Date Mon, 28 Feb 2011 18:14:39 GMT

> FYI, I've tried very very hard to minimalize, lessen, remove the
> requirement or need for a specific client framework or stack other than HTTP
> to consume hornetq's REST interface.  IMO, anybody writing a REST interface
> should make similar efforts.  Because, otherwise, what's the point?

The point is to provide the add-on and up-sell features which may make the
life of the users simpler in certain cases.
Example, Christian is working on the generic tracing component which will
work for CXF consumers. It's the basic trade-off.

> I also think we have to be very very careful from a REST framework
> perspective to avoid marrying/coupling our frameworks to a developer's
> application.  Once you've created the requirement for a framework to be
> installed both on the client and server, you've done something wrong.
See the comment above. Say CXF SOAP users can download ActievMQ or HornetQ,
and just use JMS API. They will miss on the generic tracing component. They
may not need it or they may end up duplicating the effort. Or they can
'bind' themselves to the use of the CXF api. The choice is theirs. And as I
said in the previous post, the success of CXF depends on how widely it is
being used. We are building the features which will help us convince the
users they'd be better off with going the CXF way.

> All this is why I piped in when somebody asked about JMS integration.
> Because I believe really strongly about the above.  SOAP+JMS is really a
> consideration only for cross-language/platform interoperability.  REST, IMO,
> is a superior approach because of the reasons listed above.

SOAP+JMS does not use HTTP. It uses JMS. CXF JAX-RS proxies may end up
supporting this feature too.

The use of the RESTful interface is interesting as it provides the users at
large with the options to try it in a non-Java environment, and it is
something new.

Is it superior to the optimized JMS over TCP/IP (used directly, or via
proxies) , performance wise, security-wise ? I'm not sure at all.

Would users prefer writing 'JMS-centric' HTTP APIs as opposed to what
proxies provide - it's a different issue but not all users will want to post
to some queue 'explicitly' as opposed to via the proxies.

>  Since CXF is now embracing REST through its JAX-RS implementation,
> alternatives to SOAP-based approaches should be suggested and encouraged, at
> least by the REST guys at CXF ;)
As I said it's not SOAP vs REST but JMS vs HTTP.

I'm convinced JAX-RS is here to stay and that it (the jax-rs frontend) is an
absolutely essential part of CXF for many reasons, but I won't be swaying
existing SOAP users. They will try it themselves once/if they see it works
for them. Just telling them REST is a better option is not something I will
pursue until we have something working for them to go and try. Example, once
we have users coming in to us and asking : I have HornetQ on the other end
and I'd like to try CXF JAX-RS to consume it, then I'll step in (not that I
always wait for the users to describe the actual requirements, but in this
case it may be warranted because we have CXF options too).

Otherwise I'd encourage users to try CXF JAX-RS endpoints with the JMS
back-up - because at the CXF level we can not support the interface you
built for HornetQ.

Cheers, Sergey

>> P.S. Bill - you are welcome to contribute and challenge us on the dev
>> list. Sorry if the previous thread caused you some grief :-). I
>> believe no-one meant anything more than just a protective remark. It
>> is obvious now it turned out to be a highly controversial one but hope
>> such a seasoned professional as you are can accept the attempted
>> clarifications and apologies which followed :-)
> My "grief" usually doesn't last more than 2 seconds

lol :-). Great to hear it, thanks

> and I've received much much worse grief before.  If I was more
> professional, and I'm not, I would have just ignored Glen's comments.
>  Instead, I just couldn't resist the urge to tweak him, for that I
> apologize.
> --
> Bill Burke
> JBoss, a division of Red Hat

Sergey Beryozkin

Application Integration Division of Talend <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message