Can JADE sit over ORACLE

[ConvertFromOldNGs]

by Teo Yee Cheong >> Tue, 9 Jan 2001 1:01:17 GMT

A project requiring 100 very thin clients stipulates a ORACLE database at the server end. Is there a satisfactory JADE thin client solution for this in terms of Architecture and Speed. Has anybody done it before.

Bizpoint, Singapore

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 9 Jan 2001 18:51:26 GMT

Yes, it's technically possible, but you'd lose a lot of the benefits of working in JADE. You'd use JADE's external relational database connectivity to connect to the oracle database. I'm currently working on a project where a JADE system talks to a DB2 database, so this would be pretty similar to what you're proposing.

But be careful - this functionality was really designed to allow JADE systems to interact with legacy databases, not "sit over the top of" a relational database. Also be aware that if the structure of tables etc. in the oracle database changes then you need to rework the object model generated by JADE for it.

You probably also want to do some very careful feasibility studies as to how you'd need to have JADE interacting with oracle - what queries you need, updates etc. There are probably many hidden traps for you to discover, and I'm not sure that this JADE feature is that commonly used, so you might at some point head in to uncharted waters!

My reaction would be to question why oracle has to be the solution as the database, especially if this is a new system... get out there and sell the benefits of JADE!!! (But I know this can be difficult to do in the real world!!!)

Just my 2 cents worth!

Craig.

[ConvertFromOldNGs]

by Krull >> Tue, 9 Jan 2001 20:54:04 GMT

This is a good response, Craig has covered most of the areas you need to think about. I have half a cents worth to add to Craig's two.

But be careful - this functionality was really designed to allow JADE systems to interact with legacy databases, not "sit over the top of" a relational database.

This aspect is significant when you consider the type of O/R mapping employed. Since JADE's external db connectivity feature was designed primarily to support coexistence with *existing* legacy/heritage databases, the O/R mapping is concieved with that in mind - that is take an exisiting (generally 'flat'/normalised) relational schema and from this create an object model that can be accessed from JADE. If you were coming from the other direction, i.e. you were somewhat convinced on Object technology but still required to persist your objects in a relational database, then the O/R mapping considerations are different. In this case you would most likely design an Object model making use of inheritance and polymorphism - the O/R mapping in this case would need to be quite different to provide support for inheritance, polymorphism and reference semantics efficiently.

My reaction would be to question why oracle has to be the solution as the database, especially if this is a new system... get out there and sell the benefits of JADE!!! (But I know this can be difficult to do in the real world!!!)

I agree, if you want to use JADE to build this solution effectively then it doesn't make sense to use a database other than JADE's integral database as the primary persistent object server; JADE is not architected to be a middleware tool. If the customer cannot be convinced of this, then I would walk away from the deal (as you can probably tell I don't work in marketing

[ConvertFromOldNGs]

by Wilfred Verkley >> Tue, 9 Jan 2001 22:42:51 GMT

But be careful - this functionality was really designed to allow JADE systems to interact with legacy databases, not "sit over the top of" a relational database.

I agree, if you want to use JADE to build this solution effectively then it doesn't make sense to use a database other than JADE's integral database as the primary persistent object server; JADE is not architected to be a middleware tool. If the customer cannot be convinced of this, then I would walk away from the deal (as you can probably tell I don't work in marketing

I think that argument was more true for Jade 4.x but I think Jade 5.1 is now a better choice for "sitting over" a relational database. Jade has a good programming environment, especially for multi-user applications, a good thin-client deployement model, and other tools like JUICE.

The native jade database integration though is not very good however. If I were to seriously access a database like Oracle, i would seriously consider using ADO (through Jade's support for OLE Automation) or possibly another outside API. This is where tools like VB or Delphi have their biggest advantage over Jade in my opinion.

From a selfish point of view, having the persistent data in Jade is much easier, but storing data in (or replicating data to) an external relational database gives you several advantages. You can use proffesional reporting tools, integration with other applications is easier, and the data is much more "open".

Wilfred.

[ConvertFromOldNGs]

by agenda >> Tue, 22 Jul 2003 6:49:47 GMT

Question following these comments...

We might propose using Jade over an existing Oracle DB, even though changing to a Jade DB would be better - the Oracle is a 'standard'....(yawn!)

WVs point about ADO - does this still need the external DB functions to be used or not?
We have developed ADO components as part of a C++ development so reuse would be an advantage ( maybe?!?!) - any examples of use of OLE automation for doing this?

Our real preference would be to redevelop in Jade but that will have to wait a while longer, so we are getting a Jade beachhead established in the meantime

What would be really neat in a case like this would be to be able to develop over Oracle and encapsulate as much as possible, then be able to swap it to a Jade OODB later by just changing a minimum number of methods....but then Santa and the Tooth Fairy would be good too!

Martin Connolly
agenda.systems