Re: What multi-tier components to use



Yes. Enterprise Java Beans.

Well, I worked with Java and I didn't like that there were really a lot of
interfaces that I had to keep in sync on client- and on the server-side for
Java Clients to be able to talk to a Java Service. Not to mention that
writing the java client was a p*i*t*a even without this "problem". Anyway
.... being able to use a command-line interface rebuilder with Java, made my
life much easier, even though I still had to rebuild the interfaces every
time I added a method or added another parameter to an existing method.

I also had the "joy" of using some custom-built client/server framework
which mapped each method call to one ID and each parameter inside that call
to another integer ID, where adding a new method or adding a new parameter
wasn't such a problem, but keeping all those ID's was.

I think (I don't want to argue with anyone about this, this is just my
opinion) that the most elegant way of solving the remote
procedure/function/method call is to allow people to pass any structure to a
remote procedure/function/method and to return any structure as a result.
Then, let the procedure itself decide what is good and what's not from those
parameters and let the caller decide if it likes the result. You can always
throw an exception if you don't like the data you receive (which should be
passed over to the caller side). Anyway .. not having to sync the interface
with every change in the parameter list, you could make your new server code
compatible with old clients, while you can still add new features, even if
it's by additional parameters for the same methods being used from your
clients. The "problem" (if you could call it a problem) with that approach
is that there is nothing forcing the client to use the same parameter types
or even the same parameter list as expected from the server. But, as Kim
already said, if you really want to do that (enforce the interface), you can
still define your class which will map your predefined method calls to the
flexible transport model (even use overloaded methods to do that). And when
using interfaces, if your client- and server-side interfaces are out of sync
(this is most likely to happen when you add a method to your existing
remoting class), your client-side code would still compile and "run", but
you would not be able to call the remote methods from the client, since you
would get exceptions (if you're licky, those exceptions would tell you
what's wrong). And every old client would stop working, which could have
been avoided by using flexible structures with careful coding.

Best Regards,
Danijel Tkalcec


.



Relevant Pages

  • Re: dynamic type checking - a pauline conversion?
    ... to actually write the code in Java. ... Is the query handled ... One of the problems with Java typing is small differences in interfaces ... array iteration, List iteration, and database query result iteration all ...
    (comp.object)
  • Re: CLOS Properties Question
    ... In interfaces, you can declare methods, but you ... This mess was the result of the fact that interfaces ... > is even an OOPSLA or ECOOP paper published before the advent of Java ... > Back to the question what this all has to do with multiple inheritance: ...
    (comp.lang.lisp)
  • Re: Python vs C for a mail server
    ... that is mostly unnecessary with Python. ... > I don't have enough experience with languages that provide interfaces, ... > such as Java, to understand how useful they are, but it's my impression ... I can't comment on "most Java APIs", but if you look at established ...
    (comp.lang.python)
  • Re: MRO theory
    ... It creates a Python class to proxy any Java class or Java ... Java proxies go, when it creates a class it can have at most one ... The problem basically comes about because interfaces are not classes, ...
    (comp.lang.python)
  • Re: Java "interface" vs. OO interface
    ... > I think Java uses interfaces instead of classes because the designers ... To think that the designers of Java and .NET couldn't figure out a good ... Enough for a language to adopt a new keyword ...
    (comp.object)