Alternative to ActiveRecord for populating model objects??

Hi,

We are using Ruby on Rails for an internal project. The data for our model objects exists in many different data sources (database, mainframe, etc), so we we need to avoid using ActiveRecord. Our development teams built a data service layer in Java that provides access to our company's information. We want to place Ruby/Rails in front of this data service layer and integrate our model components to get populated from that same Java layer.

So, we want to replace ActiveRecord in our model classes and replace it with code integrated with our Java data services framework. Is there an example that demonstrates how to replace ActiveRecord with Java code?

Thank you

active resource with rest api from your java model

or jruby and use natvie java classes Ivan Nastyukhin dieinzige@me.com

Ivan Nastyukhin wrote:

active resource with rest api from your java model

or jruby and use natvie java classes Ivan Nastyukhin dieinzige@me.com

So when using ActiveResource as the base for a model class, it basically populates the model using an external http resource? Like this...

class Person < ActiveResource::Base     self.site = "http://api.people.com:3000/&quot; end

Raf Jaf wrote:

Hi,

We are using Ruby on Rails for an internal project. The data for our model objects exists in many different data sources (database, mainframe, etc), so we we need to avoid using ActiveRecord.

That doesn't follow. ActiveRecord is capable of dealing with multiple databases. What's the point of avoiding it?

Our development teams built a data service layer in Java that provides access to our company's information. We want to place Ruby/Rails in front of this data service layer and integrate our model components to get populated from that same Java layer.

So, we want to replace ActiveRecord in our model classes and replace it with code integrated with our Java data services framework. Is there an example that demonstrates how to replace ActiveRecord with Java code?

Can't you just use ActiveRecord and ActiveResource? You probably don't need the Java framework, unless there's something I don't understand here.

Thank you

Best,

Marnen Laibow-Koser wrote:

Raf Jaf wrote:

Hi,

We are using Ruby on Rails for an internal project. The data for our model objects exists in many different data sources (database, mainframe, etc), so we we need to avoid using ActiveRecord.

That doesn't follow. ActiveRecord is capable of dealing with multiple databases. What's the point of avoiding it?

Our development teams built a data service layer in Java that provides access to our company's information. We want to place Ruby/Rails in front of this data service layer and integrate our model components to get populated from that same Java layer.

So, we want to replace ActiveRecord in our model classes and replace it with code integrated with our Java data services framework. Is there an example that demonstrates how to replace ActiveRecord with Java code?

Can't you just use ActiveRecord and ActiveResource? You probably don't need the Java framework, unless there's something I don't understand here.

Thank you

Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org

The point of avoiding ActiveRecord is because our data sources are disparate, meaning that they include databases, mainframes, and, in some cases, sources that expose only a message-based interfaces (JMS, etc). Furthermore, data from these sources needs to be mapped and processed through rules before being populated in model objects and presented to the client. Our Java data services layer handles all of this, so it's just a matter of integration Rails/Ruby with that interface. We intend to use Rails for our presentation tier only, not as a end-to-end solution.

The Java framework already exists, and we want to reuse what we have available.

Does that make sense now?

Raf Jaf wrote: [...]

The point of avoiding ActiveRecord is because our data sources are disparate, meaning that they include databases, mainframes, and, in some cases, sources that expose only a message-based interfaces (JMS, etc).

ActiveRecord and ActiveResource will have no problem with this.

Furthermore, data from these sources needs to be mapped and processed through rules before being populated in model objects and presented to the client. Our Java data services layer handles all of this, so it's just a matter of integration Rails/Ruby with that interface.

Don't bother. ActiveRecord can handle that too.

We intend to use Rails for our presentation tier only, not as a end-to-end solution.

Then you are making a very poor decision. Stop now. Rails is an end-to-end solution. Either use it as one or go with something like Sinatra or Ramaze that is better suited to your use case.

The Java framework already exists, and we want to reuse what we have available.

Does that make sense now?

No, for the reasons above.

Best,

Raf Jaf wrote: [...]

The point of avoiding ActiveRecord is because our data sources are disparate, meaning that they include databases, mainframes, and, in some cases, sources that expose only a message-based interfaces (JMS, etc).

ActiveRecord and ActiveResource will have no problem with this.

Oh? ActiveResource can have a JMS queue as an input?

Furthermore, data from these sources needs to be mapped and processed through rules before being populated in model objects and presented to the client. Our Java data services layer handles all of this, so it's just a matter of integration Rails/Ruby with that interface.

Don't bother. ActiveRecord can handle that too.

We intend to use Rails for our presentation tier only, not as a end-to-end solution.

Then you are making a very poor decision. Stop now. Rails is an end-to-end solution. Either use it as one or go with something like Sinatra or Ramaze that is better suited to your use case.

The Java framework already exists, and we want to reuse what we have available.

Does that make sense now?

No, for the reasons above.

Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org

Reusing code that exists and WORKS is typically a very sensible idea. Assuming that the others system from which the data comes will remain, creating ruby models that wrap the existing data source is fine. (And avoids duplication!) With the separation of modules in Rails 3, you should even make those models behave sufficiently like an ActiveRecord-based model with relative ease.

-Rob

Rob Biedenharn http://agileconsultingllc.com   Rob@AgileConsultingLLC.com

  rab@GaslightSoftware.com

Rob Biedenharn wrote: [...]

Reusing code that exists and WORKS is typically a very sensible idea.

Quite so. The bad idea here is using Rails only for the presentation tier. If the OP is really dead-set on using Rails and on reusing the Java data access framework, then the right thing to do is to write an AR interface to the data access framework.

Assuming that the others system from which the data comes will remain, creating ruby models that wrap the existing data source is fine. (And avoids duplication!) With the separation of modules in Rails 3, you should even make those models behave sufficiently like an ActiveRecord- based model with relative ease.

Right. That's the *only* way in which I'd even consider using Rails in the OP's situation: writing an AR interface to the existing data access framework, if AR cannot replace it altogether. But it really sounds to me like the OP is making his own life difficult by trying to shove Rails in somewhere that it doesn't really fit.

-Rob

Rob Biedenharn http://agileconsultingllc.com   Rob@AgileConsultingLLC.com http://gaslightsoftware.com   rab@GaslightSoftware.com

Best,

Marnen Laibow-Koser wrote:

Raf Jaf wrote: [...]

The point of avoiding ActiveRecord is because our data sources are disparate, meaning that they include databases, mainframes, and, in some cases, sources that expose only a message-based interfaces (JMS, etc).

ActiveRecord and ActiveResource will have no problem with this.

Furthermore, data from these sources needs to be mapped and processed through rules before being populated in model objects and presented to the client. Our Java data services layer handles all of this, so it's just a matter of integration Rails/Ruby with that interface.

Don't bother. ActiveRecord can handle that too.

We intend to use Rails for our presentation tier only, not as a end-to-end solution.

Then you are making a very poor decision. Stop now. Rails is an end-to-end solution. Either use it as one or go with something like Sinatra or Ramaze that is better suited to your use case.

The Java framework already exists, and we want to reuse what we have available.

Does that make sense now?

No, for the reasons above.

Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org

According to my research, I have found nothing to indicate Rails/Ruby supports native integration with JMS and mainframes.

It was only last week that we looked at Rails for the first time, simply because we want our client-exposed interfaces to be RESTful. Perhaps Rails is overkill, but do you think Ramaze or Sinatra are better because they are more lightweight? They are still built on Ruby, which puts us back in the boat: bridging the gap between Ruby and Java.

I found this article moments ago which discusses how to implement ActiveRecord in Java. If I can get this to work in Rails with a custom Java implementation that hooks into our Java data services, then my problem is solved.

Rails is an end-to-end solution. Either use it as one...

I don't agree with this comment. In my experience there is nothing wrong with using special aspects of one framework alongside other technologies.

Anyway, thanks for the info.

Here is that article about implementing ActiveRecord in Java

Raf Jaf wrote: [...]

According to my research, I have found nothing to indicate Rails/Ruby supports native integration with JMS and mainframes.

JMS: not sure. Mainframes: sure, if they expose the proper interface.

DataFabric might also help you.

It was only last week that we looked at Rails for the first time, simply because we want our client-exposed interfaces to be RESTful.

Rails is not the only RESTful game in town.

Perhaps Rails is overkill, but do you think Ramaze or Sinatra are better because they are more lightweight?

Not lightweight so much as modular. Rails generally wants to use AR or something similar (though this is less true of Rails 3 than Rails 2).

They are still built on Ruby, which puts us back in the boat: bridging the gap between Ruby and Java.

Easy. JRuby or RJB.

I found this article moments ago which discusses how to implement ActiveRecord in Java. If I can get this to work in Rails with a custom Java implementation that hooks into our Java data services, then my problem is solved.

You shouldn't need to do it that way, if I understand correctly.

Rails is an end-to-end solution. Either use it as one...

I don't agree with this comment. In my experience there is nothing wrong with using special aspects of one framework alongside other technologies.

In this case, you are wrong. Rails is a full-stack framework. If you're not going to use most of the stack, there is no point in incurring the extra overhead of using it in your project.

Anyway, thanks for the info.

Best,

If you look at JRuby rather than 3 year old articles about AR in Java, you might be in a very happy place. JRuby lets you call Java from Ruby and there would be essentially zero cost to it. You can run Rails under JRuby, too.

-Rob

Rob Biedenharn http://agileconsultingllc.com   Rob@AgileConsultingLLC.com

  rab@GaslightSoftware.com

JMS: not sure. Mainframes: sure, if they expose the proper interface.

I am interested in native support. Of course it's possible to integrate Ruby with a mainframe if the mainframe exposed a http endpoint; this is beyond obvious.

In this case, you are wrong. Rails is a full-stack framework. If you're not going to use most of the stack, there is no point in incurring the extra overhead of using it in your project.

No such thing as right and wrong; the world is grey.

Raf Jaf wrote:

JMS: not sure. Mainframes: sure, if they expose the proper interface.

I am interested in native support. Of course it's possible to integrate Ruby with a mainframe if the mainframe exposed a http endpoint; this is beyond obvious.

And what would a native interface be in this case? "Mainframes" can run lots of different DB servers.

In this case, you are wrong. Rails is a full-stack framework. If you're not going to use most of the stack, there is no point in incurring the extra overhead of using it in your project.

No such thing as right and wrong; the world is grey.

Of course there are such things as right and wrong. And that's even more true where it concerns proper development practice than abstract philosophy.

If you disagree with the advice you're getting, that's fine. If you're claiming that there is no right or wrong...well...then I don't want to be the one maintaining your codebase. :slight_smile:

Development and architecture are all about value judgements -- deciding what the right way to do things is for a particular set of conditions.

And with that, let's leave philosophy and return to software development.

Best,

Marnen Laibow-Koser wrote:

If you disagree with the advice you're getting, that's fine. If you're claiming that there is no right or wrong...well...then I don't want to be the one maintaining your codebase. :slight_smile:

I actually write beautiful code, it's sexy too. Relax and have a nice weekend...oh, and thanks for the advice :smiley: