Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
In-Reply-To: <8C18E7D4-C3ED-11D8-83DA-000A95782782@forthillcompany.com>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Subject: [OT] Chameleon  was: looking for project interest
MIME-Version: 1.0
Message-ID: 
 <OF2028E42A.F2FC4120-ON86256EBB.005BA8C7-86256EBB.005D3714@email.zurich.com>
From: Robert McIntosh <robert.mcintosh@zurichna.com>
Date: Tue, 22 Jun 2004 11:58:11 -0500
Content-Type: text/plain; charset="US-ASCII"

I mentioned JMS and a little about being a meta persistence layer. Here is 
one of our use cases where I work: we have a batch process that reads data 
from a relational database, uses Betwixt to serialize that data into XML, 
then sends the resulting XML doc via JMS (which we do a lot of) where some 
other system processes it. What I am going to do with Chameleon would 
require three lines of code:

PersistenceContext ctx = new PersistenceContext();
ctx = ChameleonClient.execute( "load_from_db", ctx );
ChameleonClient.execute( "send_via_jms", ctx );

The same concept would apply to loading from on database and sending to 
another, load from a webservice and send to somewhere else, etc. It would 
even be feasible to load from a JMS Queue and then process that data. 
Obviously something like that probably wouldn't be a real-time, customer 
facing app, but certainly a scheduled backend app.

To expand that one step further, the architecture is such that multiple 
chameleon servers can be accessed from one client. In our case, we have a 
central employee/org unit database where we could have chameleon running 
as a session bean (or webservice) and that data is accessed remotely while 
app-specific data is accessed 'locally'. This will save on the current way 
of copy/pasting config files from one project to another when we need to 
access the same data over and over. The application client would not be 
aware that there are multiple servers in use, it would still say "retrieve 
using query named XYZ" and that query may actually execute on a remote 
server. Of course, binding data across servers is on the list as well.

- Robert


Brian McCallister <mccallister@forthillcompany.com> 
06/21/2004 08:43 PM
Please respond to
"OJB Developers List" <ojb-dev@db.apache.org>


To
"OJB Developers List" <ojb-dev@db.apache.org>
cc

Subject
Re: [OT] looking for project interest


Ignore my previous post -- I am starting to grok Chameleon... maybe.

On Jun 21, 2004, at 12:31 PM, Robert McIntosh wrote:

> It is even feasible to front EJBs or even OJB for that matter.
> Chameleon could execute OQL down to OJB, and bind those results with 
> the
> results of a JDBC-based call, and bind those results with the results 
> of a
> web service call, all into one object graph. A bit over the top for a 
> use
> case I'll admit, but not totally unrealistic.

Very feasible, unfortunately. I once had a series of projects where we 
had to bind data extracted from (multiple) images to relational data 
;-) We didn't use OJB (if OJB existed then, I didn't know about it).

I definitely see the need for good backend glue projects (BEA's Liquid 
Data being my primary example of late).

How would Chameleon handle some bizarre binding like this?

Also, how does it handle updates/inserts?

-Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


******************* PLEASE NOTE *******************
This message, along with any attachments, may be confidential or legally 
privileged.  It is intended only for the named person(s), who is/are the 
only authorized recipients. If this message has reached you in error, 
please notify the sender immediately and promptly destroy it without 
review. Dissemination, distribution or copying of this communication is 
strictly prohibited. Thank you for your help.
**********************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org