Re: Creating multiple instances of objects

First, addressing the exception, the stack trace is the result of
trying to invoke the data.nTables() operation. Since nTables is
declared as an attribute in your IDL hptDBdata interface, the IDL
compiler maps this to a method in the corresponding Java interface:

public int nTables();

The BAD_OPERATION exception occurs when there's no corresponding
implementation of the operation on the server side. I assume you
implemented this method in the hptDBservant class? (Note: Class names
should be Capitalized). I assume you have since the class wouldn't
compile cleanly without implementing the corresponding methods in the
interface. Can you post your hptDBservant class?

Can you try invoking one of the operations that's not tied to an
attribute, e.g. DoQuery()? You'll probably want to stub-out the
implementation of the method to ease testing, i.e. hardcode the method
to return zero so we can test that the round-trip call is successful.

When you recompiled your application, did you delete all jar and class
files first? The compiler may have been confused and failed to
recompile a class, or the compilation of the servant class may have
failed, leaving the previous incompatible class file behind.

Other design notes:

In your main, you should call orb.run(), rather than sleep()

//for(;;) {java.lang.Thread.sleep(50);} // Wait for
clients
orb.run();

In my opinion, based on years of experience with CORBA, you're using
CORBA incorrectly. Your interface is much too fine-grained. It appears
that you're simply using CORBA as a transport for SQL-based
client-server interactions. CORBA should be used to *shield* the client
from the underlying implementation.

struct SomeLogicalEntityStruct {
long id;
string name;
// etc
};
typedef sequence<SomeLogicalEntityStruct>
SomeLogicalEntityStructSequence

interface MyService {
SomeLogicalEntityStructSequence getEntities();
};

If you simply want to expose a database schema to the client, why not
simply embed JDBC in the client? If you decide you want to stick with
the current approach, you should at least provide a handful of
composite methods that allow the client to set all the necessary values
in a single call (using multiple parameters), rather than having to
invoke multiple operations across a network.

Also, your IDL is hard to read due to the use of abbreviations. IDL is
an expression of a contract that should be readable by everybody. The
need for comments in IDL/Java is a sure sign that you're using poor
names

// Number of columns in current table
readonly attribute long nCols;

Why not simply name the attribute numberOfColumnsInTable, which would
eliminate the need for the comment?

Also, the use of IDL attributes is brittle. I'm not sure why they were
added in the first place. I don't see what's so hard about defining an
operation or two if that's really what you want to expose in the
interface.

long getId();
void setId(in long anId);

As for my "_" comment, Java naming conventions do not use underscores.
Method and variable names take the form newHptDBData, rather than
new_hptDBdata. Along the same lines, the operation names should be
lowercase. Debugging code is made more difficult when names standards
and idioms are not followed.

'Sorry to harp on this, but I've been teaching distributed
object-oriented programming for nearly ten years, and learning a
technology goes way beyond simply getting a program to compile and run.
:-)

Mark

.

Relevant Pages