Brian Leonard has written "Rails to Java via REST," detailing how he used Netbeans to write a REST service for a JPA entity bean, and used it from a Rails application. The REST service exposes full CRUD capabilities, which means you can use Java to manage the data, and Rails to handle the UI - which isn't necessarily a horrible combination. What do you think?

What do you think?

horrible combination.

What do you think?

horrible combination.

Why?

What do you think?

horrible combination.

Why?

Common sense.

In the 90's I saw the same thing happening with Java and C++. Java was used to integrate back-end services and provide a web fron end. The back-end services were written in C++. It looks like Rails is the new EAI technology on the block. What is missing though is the integration capabilities currently available for Java. HTTP is often the lowest common denominator. Given that Ruby builds on C though, integration libraries to messaging systems and the like are sure to appear soon. I think this shift will be driven by economics. Java enabled you to unleash the potential of back end systems that were expensive and difficult to change. Once you had exposed back end functionality as services, you could integrating back end services into new user applications relatively quickly and cheaply using Java. This allowed you to reduce the delivery time and costs for new business applications. Rails is the new high productivity web platform of choice it seems, and Java is now the expensive hard to change back end system. Given the right integration libraries Rails should be cheaper for EAI then Java. BTW I'm not sure whether web-services and REST are the best solutions to EAI. Across the internet yes, but within an enterprise where most EAI occurs, then a messaging bus seems more appropriate. Paul.

BTW I'm not sure whether web-services and REST are the best solutions to EAI. Across the internet yes, but within an enterprise where most EAI occurs, then a messaging bus seems more appropriate.

Paul.

I can agree with that but HTTP is a standard entry point that is almost universally supported while ESBs are fairly proprietary (please correct me if I'm wrong on that.) It's also pretty damn easy to expose an existing XML based service as a REST web-serivce and link it up to a 3rd party component that can post XML to a given URL.

BTW I'm not sure whether web-services and REST are the best solutions to EAI. Across the internet yes, but within an enterprise where most EAI occurs, then a messaging bus seems more appropriate.

Paul.

I can agree with that but HTTP is a standard entry point that is almost universally supported while ESBs are fairly proprietary (please correct me if I'm wrong on that.) It's also pretty damn easy to expose an existing XML based service as a REST web-serivce and link it up to a 3rd party component that can post XML to a given URL.

I agree, which is why REST is great for SOA/EAI on the web. On the web I think they call integration "mashups". For internal bespoke systems though where you get to standardise on anything protocol you like, then I kinda think that HTTP is just too slow and inefficient. Perhaps thats me showing my C programming roots :^). I've used Tuxedo in the past, which was great and has APIs for Java, C/C++ and yes - Cobol. I've heard good things about IBM MQSeries too, but I agree there are few cross vendor standards out there AFAIK. On the serverside there was a lot of noise about ESBs (Mule etc) a little while ago, which AFAIK are just messaging systems re-branded. Not sure if there are any cross implementation "ESB" standards though. It would be interesting to find out. Paul.

I agree, which is why REST is great for SOA/EAI on the web. On the web I think they call integration "mashups".

IMO opinion, 'mashup' is a really dumbass way of saying composition. I'd rather MTV culture not become a force for naming software design approaches. I'm probably showing my age a little.

For internal bespoke systems though where you get to standardise on anything protocol you like, then I kinda think that HTTP is just too slow and inefficient. Perhaps thats me showing my C programming roots :^).

I just worked out some proof-of-concept stuff to link Siebel up to some custom XML based services. I know almost nothing about Siebel but the consultant wanted it this way. I agree that performance could start to be a concern in the long term but we have way more bandwidth and computing power than we need. It's development and support time that we are short on. If there is a performance problem, we'll need to address it, obviously but I tend to ignore performance concerns when (when inconvenient) unless I know there will be an issue. It generally turns out that what people think will be a performance issue is not what turns out to be one. I've often seen people create performance issues in the name of avoiding them.

I've used Tuxedo in the past, which was great and has APIs for Java, C/C++ and yes - Cobol.

Hmmm. We are COBOL-bound here. I'll have to look into that.

I've heard good things about IBM MQSeries too, but I agree there are few cross vendor standards out there AFAIK. On the serverside there was a lot of noise about ESBs (Mule etc) a little while ago, which AFAIK are just messaging systems re-branded. Not sure if there are any cross implementation "ESB" standards though. It would be interesting to find out.

Paul.

My understanding of an ESB is a messaging system with standard way of connecting it to different endpoints. By itself, it doesn't buy you much but allows for a tooling which provides a graphical map of the movement of a message. For example, in the little proof-of-concept above, I implemented it as a basic servlet. But I also needed a XSLT portion. So that was another servlet. Then I needed something to dump the messages along the way (to get the consultant to stop bugging me) so that was another. I built some basic forwarding logic but it's very difficult to look at the set up and see how everything is connected. I'd much rather see a picture and I expect to replace this code with something from a 3rd party for that reason.

Not to get into this REST vs. Big Web services debate but in lot of big enterprises, it will take more than moving a mountain to get people to use HTTP vs. MQ or Tibco to do integration. We can get into endless debates around reliability, persistent messages, asynchronicity and what not but at the end of the day, regardless of all this, if you walk into a big bank and tell them to do EAI with HTTP as opposed to MQ/Tibco you'll get laughed out the door. That's just the reality. As for ESBs, mileage varies, as usual. I agree those pretty flow pictures may not mean much in the end but the value-add is in the mediation capabilities - protocol, data format, structure etc. Sure you can build your own infrastructure but as the number of different protocols grows and more domains get involved with ever-so-slightly-different entity structures a mediation infrastructure does come in handy.

Hi James,

My understanding of an ESB is a messaging system with standard way of connecting it to different endpoints. By itself, it doesn't buy you much but allows for a tooling...

OK, you've said enough, so it doesn't look like I'll be trying out an ESB anytme soon :^) Thanks for the heads-up. What Satadru says about MQ and Tibco matches what I've heard too. Never used either of these though. Choices, choices :^) Paul.

Hi James,

My understanding of an ESB is a messaging system with standard way of connecting it to different endpoints. By itself, it doesn't buy you much but allows for a tooling...

OK, you've said enough, so it doesn't look like I'll be trying out an ESB anytme soon :^) Thanks for the heads-up.

What Satadru says about MQ and Tibco matches what I've heard too. Never used either of these though.

Choices, choices :^)

Paul.

We also have MQ but I'm the only person in the organization that (AKAICT) has any experience with messaging so I'm having to play salesman for messaging. MQSeries is interesting to me because it supports synchronous messaging in addition to the normal asynchronous messaging I'm accustomed to. I used Tibco at my last job and we had some issues with their JMS/EMS solution stable on Solaris but that may have had more to do with the outsourcing of infrastructure than the actual Rendezvous software. As far as the ESB goes, don't take my word for it. I haven't actually worked with one. I'm just trying to see through all the vendor blah-blah. We are on rails to get one so maybe I'll be more informed later.

We also have MQ but I'm the only person in the organization that (AKAICT) has any experience with messaging so I'm having to play salesman for messaging. MQSeries is interesting to me because it supports synchronous messaging in addition to the normal asynchronous messaging I'm accustomed to. I used Tibco at my last job and we had some issues with their JMS/EMS solution stable on Solaris but that may have had more to do with the outsourcing of infrastructure than the actual Rendezvous software.

As far as the ESB goes, don't take my word for it. I haven't actually worked with one. I'm just trying to see through all the vendor blah-blah. We are on rails to get one so maybe I'll be more informed later.

I've worked with MQ in the past and just brought on to our current team the guy I worked with who had a LOT of MQ exprience. We have started using Mule and he says that he is finding that all the code that he had to write to hook up to MQ - it is just configuration in Mule.

We also have MQ but I'm the only person in the organization that (AKAICT) has any experience with messaging so I'm having to play salesman for messaging. MQSeries is interesting to me because it supports synchronous messaging in addition to the normal asynchronous messaging I'm accustomed to. I used Tibco at my last job and we had some issues with their JMS/EMS solution stable on Solaris but that may have had more to do with the outsourcing of infrastructure than the actual Rendezvous software.

As far as the ESB goes, don't take my word for it. I haven't actually worked with one. I'm just trying to see through all the vendor blah-blah. We are on rails to get one so maybe I'll be more informed later.

I've worked with MQ in the past and just brought on to our current team the guy I worked with who had a LOT of MQ exprience. We have started using Mule and he says that he is finding that all the code that he had to write to hook up to MQ - it is just configuration in Mule.

Hi Mark, What are you using at the front end? I have been using Rails for a while now and it's a dream. The Ruby language is the key to Rails success, and Ruby just grows on you the more you use it. I have just had a quick look at the Mule website, but didn't see any support for languages other then Java. If you are into Agile development like I am, then I really recommend Rails and Ruby - they fit an Agile mindset really well and make "doing the right thing" easy. Where there is a C API, then it should be relatively easy to come up with a Ruby API. The Ruby community is very active so I'm sure that Ruby API's for things like Mule (if it is well thought of by Railers and Rubyists) will start to appear soon. I think Ruby will become the new "green field" language of choice. With Java becoming the "brown field" language much like C++ was in the past. Paul.

I have just had a quick look at the Mule website, but didn't see any support for languages other then Java. If you are into Agile development like I am, then I really recommend Rails and Ruby - they fit an Agile mindset really well and make "doing the right thing" easy. Where there is a C API, then it should be relatively easy to come up with a Ruby API. The Ruby community is very active so I'm sure that Ruby API's for things like Mule (if it is well thought of by Railers and Rubyists) will start to appear soon.

Are you ok?

Hi Mark,

What are you using at the front end? I have been using Rails for a while now and it's a dream. The Ruby language is the key to Rails success, and Ruby just grows on you the more you use it.

Have you worked with Python at all? I've done enough Python now to feel I have an adequate grasp of the language and where it works well. But I'm starting to get a little annoyed with the warts and I'm thinking about taking Ruby for a whirl. As I understand it the languages have lot in common. I've never found a really good comparison of the two.

I have just had a quick look at the Mule website, but didn't see any support for languages other then Java. If you are into Agile development like I am, then I really recommend Rails and Ruby - they fit an Agile mindset really well and make "doing the right thing" easy.

Where there is a C API, then it should be relatively easy to come up with a Ruby API. The Ruby community is very active so I'm sure that Ruby API's for things like Mule (if it is well thought of by Railers and Rubyists) will start to appear soon.

I think Ruby will become the new "green field" language of choice. With Java becoming the "brown field" language much like C++ was in the past.

Paul.

What about JRuby? I'm not sure if Ruby on Rails runs on JRuby well but that should be were JRuby is going.

What about JRuby? I'm not sure if Ruby on Rails runs on JRuby well but that should be were JRuby is going.

This helped getting Rails and JRuby to run together: http://www.headius.com/jrubywiki/index.php/JRuby_on_Rails

Hi James, Forgot to say:

It's development and support time that we are short on. If there is a performance problem, we'll need to address it, obviously but I tend to ignore performance concerns when (when inconvenient) unless I know there will be an issue. It generally turns out that what people think will be a performance issue is not what turns out to be one. I've often seen people create performance issues in the name of avoiding them.

I totally agree with what you say about performance. Performance isn't really my issue with HTTP, I just think that there are better (and more productive) messaging alternatives in the enterprise. I like REST, just not sure where it best fits. You may be right, It may make sense to use REST for most things. Paul.

Hi James,

Forgot to say:

It's development and support time that we are short on. If there is a performance problem, we'll need to address it, obviously but I tend to ignore performance concerns when (when inconvenient) unless I know there will be an issue. It generally turns out that what people think will be a performance issue is not what turns out to be one. I've often seen people create performance issues in the name of avoiding them.

I totally agree with what you say about performance. Performance isn't really my issue with HTTP, I just think that there are better (and more productive) messaging alternatives in the enterprise. I like REST, just not sure where it best fits.

You may be right, It may make sense to use REST for most things.

Paul.

I'm not saying it's the best choice. I'd probably lean towards something else if the effort is roughly equal. I suggested messaging to the Siebel consultants (with regard to the story above) but they needed synchronous responses. In the end all I wanted was for them to not leave a huge mess for us to deal with and REST was easy for them so I'm not going to sweat the overhead. It's not always the best solution but it's not a terrible one either. I'd like to get to the point where using REST over HTTP vs. messaging is just an implementation decision and doesn't affect how our business solutions are designed.

I would give a second opportunity to the author to ponder over the insanity of the proposed solution in real application and not just in trivial, misleading examples. Unfortunately, I am not confident it would be useful since the "mother of the fool - here read little thinking - is always pregnant", meaning that there always be, sooner or later, someone coming with a wonderful idea, asking himself why nobody proposed it before. Guido

Maybe Rails is marvelous enough - I do not know it - to lead to such designs but I really consider this own awful ! What about transaction demarcation for your CRUD operations ? What about security considerations ? HTTP is not a good integration protocol. My preferences are: . JMS with XA support . CORBA - maybe too complex And JMS is simply an API for message exchange - any implementation with XA support may suit your needs. If I really have to do such an integration, I would choose ActiveMQ http://activemq.apache.org/ as a message bus and first address transaction and security aspects in the prototype !

Rails doesn't have a good way to distribute across multiple servers besides using the database.  I am working on a site that will have a very complex social graph that I will want to keep in memory due to it's size.  Rails doesn't have a good way to do this, where if I do this in Java I can store the object in memory and the various threads can all access and manage the graph object which will be persisted to a database but is too big by itself to load all the time from the database to do a search.

so to access this graph I will be going from my Rails application to the Java web service for data.  I wanted to do an ActiveResource REST API so I followed the methods in the article to set this up.