RE: ODBC (was RE: Green screen - it's time is over ) -- MIDRANGE-L

Joe, Brad

I've snipped all the previous comments I agree with.


> I've worked in software development for quite a few years now, and during
> that time I've seen many occasions where column names change (a typical
> instance is when two applications are merged and there are collisions), or
> data attributes are moved from one file to another (one case in particular
> was when we added partial shipment records to order entry).  You can argue
> all you want that it doesn't happen, but in the real world, it does.  And
> if your design can handle it, your system is far more flexible.
>

IOW, there are many trade-offs.  Performance vs. maintainability vs. cost
for example.  This applies to design equally well as to code.

In this argument, there are complexities involved with distributed systems.
No doubt.  There are performance and cost advantages involved with
distributed systems.

Is there one optimal approach, to fit all situations.  Highly doubtful.
Sockets seems promising, as well as XML-RPC/SOAP.  If you want to explore a
conservative approach, well..  IBM, M$ and Mr. Dave Winer are investing a
lot in these things, especially SOAP.  SOAP also includes technology, that
Mr. Winer refuses to support, called FDDI (I thin) which supposedly will
allow applications to auto-majically "discover" the right way to
interoperate, regardless of any changes in data structures, on either end.
Have no idea how this CAN work, nor know how it's supposed to work.


But because I haven't signed any trade secret agreements with anybody, I'll
tell what I think the optimal design principle is, or rather what it appears
to be, IMV.  There was a company, 3 or 4 years ago, called Forte Software.
Their middleware allowed the location of code to be dynamically moved from
client to server.  Seemed pretty powerful stuff, but I expected them to
reach M$ size by now...

I like the principle.  I don't know the product, or what became of it.  (May
have come on hard times because C/S, like most programming paradigms seem to
anymore, had a half-life of just a few years.

I think the principle is that identical blocks of small modules can run on
either the client or the server.  Where it executes is accomplished by the
flip of a bit.  THIS IS THE KEY QUESTION...:  If the code is tightly
integrated, it shouldn't require a massive number of bits (ie massive
complexity) to keep track of all this.  Performance favors executing code on
cheap client hardware...  Pure design and flexibility gives the edge to
consolidating code execution on a server.  Being able to do either,
depending, would seem to offer the potential of "the best of both worlds".

This is just a theory, of course.  But, IMV, SOAP is still just a theory.

And that theory, the theory behind "web-services" as I understand it, calls
for renting web-services.  Seems to call for data to be sent to servers, and
results to be returned.  If that's the theory, I don't like it.  I hardly
have a clear understanding of SOAP, to say however.

The Forte approach, or what Joe and I at one time called "the server/server
paradigm" could be implemented "relatively easily".  (Emphasis on /could
be/.)  The original architects of the S/38, as well as the current work on
the iSeries has demonstrated, beyond a shadow of any doubt, that simplicity
CAN BE designed in.  It ("only"...;-) requires both a simple model, and
highly disciplined engineering to implement it.

I don't necessarily view the cross-platform advantage of Java as being much
of an advantage, in the long run.  You end up with least-common-denominator
type of solutions, plus SUN owns the platform and it's not as "open" as even
RPG is.  RPG benefiting from input from the Community that uses it, to an
extent.  They both fall into the category of "proprietary solutions", IMV.

JMHO... Be interested in the views of both of youse, as well as anyone else.

jt