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/"
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
http://gaslightsoftware.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

http://peterbacklund.blogspot.com/2007/07/implementing-activerecord-in-java.html

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
http://gaslightsoftware.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: