Hi > > 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 > http://bill.burkecentral.com > -- Sergey Beryozkin Application Integration Division of Talend <http://www.talend.com> http://sberyozkin.blogspot.com
