Re: framework questions/Remote data access

Aaron/Joe,

Aaron- We have done several similar projects to your ?mother children?
requirements.

In my opinion, I would not implement a dataqueue / server ? client
architecture for the following reasons.

a)       You would have to save and restore code possibly redundant code to
each child.  The client server era taught us this can be a pain.  Each code
update would have to be placed on the appropriate child, etc.
b)       You would have to ?manage? each child (server startup/shutdown,
etc).  Each child would need a startup process to start a job which services
the dataqueues.  Probably not a huge deal but you now have several points of
failure along with the extra overhead.
c)       It?s not portable.  What happens when Taylor has a ?child? on SQL
Server or Oracle?  Now you have to invent an adaptor, etc.  Acquisitions and
mergers happen all the time.
d)       It doesn?t leverage the power of SQL/JDBC.  Using dataqueues, how
do you get the data back and forth from mother to children?  For example, in
your scenario, how are you going to return the first 10 a/r records and then
get the next 10, etc.  If you have to parse each request and response cycle
and different record structure, how would you ever achieve any productivity?
In addition,  how would you handle these typical requirements:
a.       Customer wants A/R records returned ordered by Month and PO #?
b.       Customer wants Sales data grouped and totaled by Product and
Supplier?
c.       Customer wants to view only fields x,y,z in a list.  As they always
do, then they decide they need to also see field q; how would this
architecture accommodate these requirements in a productive manner?
d.       Many, many other features that SQL provides by default.  If you are
going to architect servers and services with native IO, I wouldn?t
understand how you could even c      ome close in terms of productivity and
flexibility.
e)       Multiprocessing.  Would this architecture restrict us to each child
server program synchronously handling each DQ request?  JDBC would allow a
multi-threaded approach.
f)         Lack of OO model available to your UI/Controller.  It is my firm
experience that OO and inheritance does work very well for business rules.
Let?s take an example scenario:  Let?s say your customers or vendors are
viewing a list of orders.  They are able to change the ship to address as
long as the order hasn?t shipped yet.  Some orders have shipped others have
not.  A typical UI would have a conditional ?edit? feature next to orders if
they have not shipped.  If they have shipped,to  they should not have an
?edit? feature.  I would assume in this case, you would need to have
?business logic? in your beans that are passed to the UI.  For example, your
OrderBean was returned from your RPG server, would implement a method like:
a.       Boolean  isEditable()  { if
(getShippedFlagField().equalsIgnoreCase(?Y?) return false else return true;}
b.       Your UI code would then iterate through your OrderBeans and build
the list dynamically and incorporating edit features only for Orders that
return true from the isEditable method.
c.       Like wise, your UI needs to enforce many business rules such as
required fields, conditionally required fields, conditional pick lists
depending on the state of your bean, read only, zip code fields, ssn?s,
applicability rules  (if the purchaser is from MN they are charges sales tax
so only show this field if they are from MN. Etc?
d.       In a mixed model with Java calling RPG, how do you get these
business rules available to be leveraged by your UI?  Do you have to now
kinda of create a dual business model logic?  One in RPG and one in Java?
Do we have to code this type of logic in our JSPs?  If so, what happens when
the same requirement occurs on a different version of the view / jsp.
g)       Non strategic approach.  IBM and the industry are investing in
SQL/JDBC/Java and much less in native IO and dataqueues.  Long term
maintenance of RPG may be an issue as skill bases become dominated by Java.
You are also not able to fully leverage the growing array of JDBC based
persistence APIs and other Java components.
h)       Productivity or a lack of it.  I may be missing something, but I
don?t understand how a procedural approach to persistence in RPG along with
business rules procedurally enforced can be done in a productive, flexible
manner.  I may be missing something but typically we can create the basic
functionality that Aaron mentions (A/R inquiry, updates, Sales, Security
based on client,etc) in a day or two.  How long would it take us in this
procedural model?


I would recommend:

a)       Usage of JDBC and connection pools.  You would simply use the JDBC
remote driver on the mother to access children databases and also the mother
itself.
b)       This allows you to leverage the full power of SQL.
c)       Your OO model could be defined and available to your UI generation.
d)       You are portable and able to accommodate other databases.
e)       Your processing is centrally located and can be managed, logged,
and controlled from a single code base.  1 node versus 1 * # of children.
f)         You are strategically aligned.
g)       You would be much much more productive being able to leverage OO.
You can develop common routines and components.

My other views/summaries/opinions based on recent posts:   IMHO:

a)        Java works well for business rules.
b)        Inheritance and abstraction and interfaces can work very
effectively for business rules.  Composition does as well.  Again, I don?t
understand how a procedural based approach could even come close in terms of
productivity and flexibility to what a well architected OO framework could.
c)        I agree business rules driven by database fields and records is
the best approach over inheritance.
d)        Java without a framework would be no faster or productive than a
procedural language.  Java takes 3 ? 6 months to learn.  OO takes 3 ? 10
years to truly understand and leverage.  You can leverage and benefit from
the use of OO components and frameworks via Java writing in a procedure
approach if you don?t know OO.
e)        RPG and associated iSeries legacy resources can and often should
be leveraged by toolbox program calls, stored procedures, etc.  I don?t
advocate rewriting the world in Java if there is not a business need.
f)          RPG IO can provide better transactional IO performance than SQL
but the costs are productivity, flexibility, and portability.


Thanks,  Paul Holm

Business: 760-432-0600   Home: 760-432-6550
Cell:  760-415-8830
PlanetJ - Makers of WOW  (AKA... WebSphere on Steroids)