This email address issues related to the dynamic creation of objects in
the client
that need to be "moved to run in the server". The use of this "created
at run-time"
objects can improve the flexibility of the systems for details that are
not known
at development time. If there has been any discussion about this
already,
can you please let me know? If this is trying too much at the moment
given the
state of the technology, I will be more than happy to know why so that I
can
provide valid arguments to my collegues. Thanks!
The concept of query object that I use here comes from the following
paper:
Reports by John Brant & Joseph Yoder
available at: http://www-cat.ncsa.uiuc.edu/~yoder/papers/papers.html
The forces driving the query object pattern can be summarized as
* we need to create queries at runtime maybe based on end-user's
input.
* the end-user doesn't need to know details of the representation of
the data
* the end-user "knows" that some particular data is "now" in the DB.
Therefore, we need to provide a way for the user to represent the "kind
of data"
that he needs.
A client would typically call a server asking:
* give me all customers
* give me the customers that bought something before date D
* give me the customers that bought products of type P
Those questions should typically map to methods implemented by a
Customer
interface that could be a session bean, which then asks an entity bean,
which
in turns looks into the DB (an OODBMS in this case) to get the data.
Say that when we were developing the app, the DB did not even have the
concept of Customer. We only had products, retailers, whole-sale orders,
etc.
Now, we need customers and they are being added to the DB by another
app,
by hand, whatever...
Preventing that situation, we decided that we wanted to allow dynamic
creation
of queries. The client (end-user) knows what he wants to ask and creates
a
query object indicating that he wants "customers" and only those that
satisfy
a given "criteria".
In the object query pattern described in the paper, the query object
does "all":
it holds the query details, executes the request and allows "whoever" to
call getResponse() to obtain the results. It's been suggested that a
similar
approach can be used in the scenario of a client calling a session bean.
However, I can see a few issues involved:
* the query object is not a remote object (or should it be?).
There would be many of them in that case and that adds extra
inter-bean
communication that may be not necessary.
* the query object needs to be serialized to be sent by value to the
SB
and back to the client once the query is complete.
* the server only knows that the query object accepts method
"execute()"
It is not involved in the actual access to the DB in the sense
that DB
access knowledge is in the query object, which is created in the
client.
Because of RMI semantics, we can send behaviour in the form
of a serialized object. The server does not even need to know which
class it
is but which class it extends (if there is a "maybe abstract" common
class for all query objects) or which interface it implements (one with
a
method "execute" in it). If that's OK, then the scenario described above
is
"POSSIBLE" using EJB. Isn't it?
Are there any issues with the transactions? Obviously, the query object
needs
to know how to access the entity bean that will eventually talk to the
OODB.
Alternatively, it needs to know how to handle the OODB including its txn
mechanism. That sounds a bit more tricky to me.
It's been suggested that we should implement "all the queries" that way
but that
looks like the "Golden Hammer" antipattern (i.e. a familiar technology
or concept
is applied obsessively to many problems").
I would rather keep "known things" simpler using nice methods like
"getAllCustomers()" to provide a collection
of basic info of the customers, for example. Otherwise, almost every EJB
that we
create would have one method, namely execute(QueryObject). Comments
welcome!
Another approach is to add an extra component (EJB) for unknown queries
once
they are "known". Eventually, we can refactor all the components
organizing them
as we like. It is true that we still need to develope that component
first, but...well,
it looks easier. If there is any major problem with the dynamic approach
(hopefully you can tell me), we would have to go for this or use another
solution
that you may want to suggest.
Cheers,
Javier
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
