RE: MODERATOR ALERT

Joe/Jeff,
Joe in response to request about how to further analyze approaches and
architectures here is an idea from Jeff that I think is good.  Jeff,   I
agree with your idea, lets get a application to use for comparison.  I
suggest even opening it up for the readers of this forum.  They send in real
world business requirements perhaps even supplying "cleansed" data files
that can be used for the exercise, the group choices one or two applications
and we compare results after application creation.  Readers get the benefit
of the comparisons plus the selected business's get a free prototype.

Joe,  I don't want to belabor the point but you asked and I feel strongly
that this issue is critical to the audience since it has huge ramifications.
Choice the wrong approach and pay for it for years!  You have asked for
concrete examples which I have provided to you in past posts.  I have
provided my opinion about your approach and architecture (server-client)
using specific details (See feedback to Aaron Bartell and his mother
children issue) so I feel like I'm following your "rules of engagement".
You have made your claims about productivity and the appropriateness of OO
for business rules.  I respond because I know Java and more importantly OO
work very well for business rules because I have dozens of production
applications running that do that very thing.  Therefore, I feel I may be
able "prove" this assertion and also point out where procedural techniques
struggle to complete with OO.  I don't like to blow my own horn because I
know I have lots to learn but you prefer stated credentials.  I began my
career developing CL and PLMI test programs to test S38 and OS/400 code
before GA as part of the Mankato - IBM Rochester partnership.  I spent 6+
years in the IBM Roch lab developing OS/400 DB code concentrating on
performance, OPNQRYF, SQL, etc.  I spent the last 5 years of my IBM career
in a consulting organization (PartnerWorld) where my job was to assist RPG
and cobol shops as they moved into OO and modern technology.  I specialized
in Smalltalk and OO and taught numerous classes on the subject.  I got a
chance to work with several dozen ISVs assisting them developing OO code.  I
was involved in the creation of one of the larges OO projects which was the
1996 Olympics where we produced a Client server OO project to serve results,
bio, events, etc to the audience in Atlanta.  I moved to Java when it came
along and then to the San Fran project (there are several reasons for it's
struggle besides technical) and then back to Java.  I've written 2 IBM
redbooks on Java , written articles, and presented world wide.  Ever since
then, I have been working with dozens of other companies building OO based
solutions.  I am not a Java bigot (I prefer Smalltalk) but I have witnessed
what OO can do for companies and IT IS COMPELLING.  And YES you can do
business rules and programming in Java and OO and I can prove it.

I know that you have worked with objects and frameworks but for the benefits
of the iSeries community out there that hasn't got a chance to really
understand OO, here some of the concrete possibilities and benefits possible
with OO.

Application development and specifically Web based application develop is
targeted to solve business problems; no surprise here.  Within these
business problems, common patterns emerge and reoccur often.   For example,
the most common pattern is the "Select and Display Pattern".  This pattern
involves selecting data and presenting it to the user.  The problem is very
similar in most business problems however that data is normally different.
For example, insurance companies want to display policies and claims while
manufacturers want to display orders and bill of materials.  This is just a
single example of a reoccurring pattern.  There are numerous additional
patterns reoccurring from application to application.

Object Orientation (OO) and frameworks allow the development of "generic
software" that can effortlessly handle these reoccurring business problems
and patterns.  OO also allows this generic framework software to handle
processing in a custom manner if the business problem is "similar but needs
a little different behavior".  For example, when an Order ship date is set
and updated on an object, we want to also send an ASN email to the customer
and shipping department.

The benefit to the business is that applications can be developed in a small
fraction of the time typically required by procedural programming.  The
precise benefit amount depends on the amount of framework reuse your
particular business problem can leverage.

Following are a subset of the most commonly identified patterns reoccurring
in business applications categorized by architecture level.  (Imagine
development where you didn't need to write any code to solve these
reoccurring business problems!!)

The Data Base Layer

1. Persistence, the ability to read, write, update, or delete records. At
all these points, a programmer is able to override the default behavior and
veto it or add some additional processing if needed.
2. Paging (subfiling) support.  The ability to read only 10 or 20 records at
a time allowing the user to page through the data in segments.
3. Associated raw data with business knowledgeable objects such as a social
security number, state, zip code, phone number, federal express tracking id,
etc.  Automatically propagate these business objects and their validation to
the user interface.
4. Automatic validation provided by knowledgeable business objects such as a
phone number validating itself or alerting a user if they entered an
improper zip code or date.
5. Automatic validation to the end user for required fields.  (I.E.  You
must fill in your first and last name when creating the order)
6. Auto incrementing a field.  For example, for each new order just add one
to the last order number.
7. Cache support.  Often for performance reasons, you may want to read and
hold selected records in a memory based RAM for a certain period or until
someone changes that data which invalidates the cache.
8. Optimistic locking.  Alert the user or disallow a record update if a
specified field changed from read time to update time.  Also when updating
information (fields), only update the fields that were changed otherwise you
may over write other changes.  Concurrency support allows you to specify if
fields can be updated if they have changed since read time.

The Business Model Layer

1. Leverages information from the database and add the ability to associate
real business objects.  For example, a char(9) field becomes a social
security number.  The social security number field works with framework in
both the UI layer and DataBase layer to ensure an invalid value is not
entered.
2. Associations.  The ability to link business objects together.  For
example, an Order business object is associated with OrderDetail objects.
3. Possible values or pick lists.  Often certain business fields have a set
of possible values.  For example, a WaterPump horse power field may be
values ".5 hp,  1 hp, 2hp, 5hp".  The possible values list may be influenced
by the current user or another field's value such as the water pump
manufacturer.
4. Associative Programming:  The ability for generic objects to instantiated
and to use fields with knowledge of specific field, table, and libraries.
For example a Customer business object can find and use first name and last
name fields generically.  That Customer object can apply to any number of
business data tables.  User interface components (JSPs) can be created
without knowledge of the database that they will be populated with.  For
example, standard Invoice JSPs can be created and used.
5. Default values.  For example, the order country field should default to
"USA" or whenever this record is updated, put the current date into the
last_update_field.

The User Interface Layer

1. Select and Diplay.  Allows for the specification of any selection fields,
allows the user to enter their values with the results displayed.  For
example, a sales agent selects and state and policy expiration date to find
potential new business.  Paging support automatically allows the user to
page through any data returned.
2. Custom field labels.  Usually field names are not user friendly.
3. Sorting.  Allow the user to sort the displayed data based on any field.
4. Persistence, working with the other layers, allows authorized users to
update, delete, or insert new data if required.
5. Convert any returned data into commonly requested formats such as MS
Excel or Word.
6. Security.  Only allow authorized users to see information that they are
entitled to.  Allows field level security, for example, a secretary can see
a customers balance but can't change it or only allow managers to see the
salary field.
7. UI customization.

Multi Layer Patterns:

1. Self service applications.  When customer 5676 signs on to the
application, they should only see transactions for customer 5676 not someone
else's.  This is one of the most common business application requirement in
today's era.  Vendors want customers to see their data.  Vendors want
suppliers to be able to see purchase orders.  Banks want customers to see
their transactions.
2. Regular scheduled tasks.  This provides the ability to run specific user
code at certain intervals.  For example, each night at midnight a process
runs that generates a report on claim status and emails it to insurance
agents.  This pattern requires the programmer supply a class that is called
at the defined periods.
3. Security (Authentication): Many applications need to be secured.
Reoccurring requirements in this area are:
a. Valid OS user profile
b. Intranet users only
c. Only these 3 specified users
d. Based on a database of authorized users.  For example, JDEdwards supplies
an address book with suppliers who may be authorized to use the application.
4. Flyweight pattern.  For performance and memory reasons when presenting a
list, you may only want to return a subset of the list.  When the user
selects a particular item for display or edit, you need to go back to the
database and get several more fields from the selected record.


Again, these are only a subset of the patterns.  We have identified more
than 150 reoccurring patterns that we have found from working with numerous
iSeries and non-iSeries shops and incorporated them into a cohesive
framework using OO techniques.

The benefit is enormous; I don't spend time coding reoccurring functions as
listed above.  I can spend my time customizing behavior if needed only an
exception basis.  More complex applications need more custom code
implemented inheritance.

This is the benefit of OO and patterns and it can enable you create many or
most applications 2 to 1000 times faster than procedural techniques and this
is not code generation.  It is a set of Java classes that provide a
framework (api).
Most procedural approaches involve handling the above business requirements
by coding for each case resulting in highly redundant development and
severely restricted productivity.  Each file accessed and manipulated may
involve a similar amount of effort and coding.

Anyway, that's my experience.  Respectfully, Paul Holm


<MODERATOR MODE

You know what Joe Sam?  You just pissed me off.

You are intimating that *I* said Java is useless.  I suggest you go back
through all the posts in that thread and find out exactly what I said,
and who was the one to first put the "Java is useless" tag on the
conversation.  I did say procedural is better than OO for business, and
I think I've made it clear why I think that, with some pretty powerful
examples.


In case you missed it, here's MY summary of Java and the 400:

"Java is good for many, many things, but one thing it is NOT good for is
programming business logic.  Inheritance is perhaps the single most
overused (and misused) feature of any language ever designed, and it
almost NEVER applies in the business world.  Business application make
far better use of composition than inheritance in well over 90% of the
cases I've ever looked at.  Try to come up with 10 places where
inheritance (especially Java's single-parent inheritance model) makes
sense."

And this:

"No, business rules and OO do not mix.  OO is best used to define
processes that are rarely if ever subject to change (communications
protocols, HTML formatting, that sort of thing).  Procedural languages
are by far better for writing business logic that can change from day to
day based on external circumstances."

And this:

"And in any case, the point is not whether inheritance is good or bad,
but whether it is appropriate for business programming.  My position is
that it is not, and that except for the most trivial applications I can
write business logic much more quickly and flexibly in RPG than any
other language."

And this:

"It's simple for me.  For inquiries on data that isn't particularly
sensitive, JDBC and a framework like Struts is great.  This allows you
to build lots of great enterprise information systems for management
without much overhead.

For anything else, I stick with servers written in RPG accessed by a
controller, also written in RPG.  These send message to a servlet, whose
sole responsibility is creating beans from messages, invoking JSPs, and
then converting responses from JSP forms back to messages."


I tried very hard to be concise and clear and as dispassionate as
possible given the nature of the discussion.  And instead I get attacked
by Dieter, who insists that EJBs are the way to go (perhaps you agree
with that, Sam?) and Marc, who was the one who put the "OO is useless"
tag onto the thread.

NOT ME.

The problem stems primarily from the people who think that programming
issues are philosophical ones, not practical ones.  They get caught up
in an architecture (OO) or a language (Java) or a buzzword (platform
independence) and then they invest their entire personality in it, to
the point that if anyone dares to question the buzzword, they take it as
a personal attack.

Me, I could care less, but I will NOT let someone rant on in this list
about how OO is better than procedural, or how RPG is a "Report Program
Generator" or how Java is the one language to rule them all and in the
darkness bind them.  I'm about solutions, and considering I've been the
number one Java/400 advocate for over five years, I find it ironic that
I'm accused, even through implication, of being anti-Java.  I'm not
anti-Java, I'm simply FOR using the right tool for the job, and IN MY
OPINION (yet to be disproven) Java is not the right tool for business
programming.

Sometimes I'm not particularly smooth about it, but if you take the time
to read the messages, you'll see that the frenetic zealotry is NOT begun
on my side of the conversation.  Instead, I'm trying to create a common
sense environment where people who can only see one answer to things are
not allowed to infect everyone else.  Unfortunately, I get statements
like "quick hack" and "don't know anything about OO", and occasionally I
respond in kind.  But if you're professional, no matter how heated the
initial contact, the conversation can get right back on track as it has
with me and Marc.

You see, I don't even care if you agree with me or not, so long as you
don't answer any question with the thought, "Wow, it's RPG, so it must
be bad."  If you have a thought-out answer that would pass scrutiny in a
real world design meeting (as opposed to an OO 101 class in college),
then I'd love to hear it.  Over the years, I've changed my position on
things like SQL and JDBC, and I'm as amenable to change as the next guy.
Well, almost <grin>.

Yes, this is a Java mailing list: Java on and around the iSeries, and
that includes co-existing with RPG.  This is NOT a mailing list about
writing platform independent code at the expense of security, stability
or performance, although I do let the pure Java folks toss their hats in
the ring.  But they better be ready to back up their ideas with
well-thought positions, because THAT'S what this list is about.

Solutions on the iSeries that happen to include Java.

You want to create a new list about Java programming because I say Java
sucks for business code?  Fine.  Or you could include your comments
here, if you're able to back them up.  The fact is that I don't mind
opposing views, as long as they're backed up by something other than "OO
is better".  Hell, if you can tell us how to get a project like San
Francisco to work, then we're all ears, Joe Sam.

But please don't get on my case about the tone or tenor of this list.
This list is foremost about the iSeries, not Java.  And if it weren't
for me, this list might long ago have devolved into an RPG bashing
forum, and that's about as bad an idea as I can think of.

Joe

</MODERATOR MODE>