× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Paul,



I fully agree that CRUD is one point that should be automated because the
Skeleton of a CRUD service is the same.



There are many ways to do a CRUD service, in RPGLE you can either do like
XMLSERVICE that is a generic service with SQL as input and XML as output or
you can do it like I do, write a skeleton template SQLRPGLE program and a
program generator that inserts code based on the table description (DSPFFD)
and then creates a CRUD service per table.



There are pros and cons in both methods, XMLSERVICE is very flexible but
also very open (you can run a delete from xxxlib/yyytbl) but it lacks a
build in security concept because it isn't a part of a framework and it
lack the ability to include table specific BL such as do updates of parents
if the table is a child unless it is done in stored procedures or in
triggers. The last is that CRUD should have advanced error control such as
handling of duplicate keys and/or advanced field checking and should be
able to echo meaningful messages back to the controller if it failed and if
it succeeded.



I also agree that CRUD services are about 75% of code if not even more. I
have recently done a modernization with 194 CRUD services. The number of
statements that is generated is about 350.000 lines of code and the code
generation and the program compilation is all done in 13 minutes on a
reasonably priced IBM I - a 515.



In comparison the 171 online programs was done in 11.500 line of code, the
connection of 32 existing BL programs to web services was done in 2.900
lines of code and the build in of additional BL in 30 of the 194 CRUD
services was done in 2.900 lines of code.



The CRUD and the BL Webservices can run the whole system so any client that
can issue an URI and a FORM can run the system and these services is
completely unaware of what client type that calls them, it can be a server
acting like a HTTP client, a PC browser, a PAD or a PHONE or whatever -
that is to me what SOA is about and makes it reusable.



In my world CRUD and BL web services are completely separated from the UI
and are just from the Client point of view not even call back services, but
resources. I don't like the word "call back" because it indicates that
there is a deep connection and binding between the programs the launces the
UI and the service that provides CRUD or BL services - in other words and
often seen - if you have a ASP.NET page that may launch a PC browser page
and the page calls back to the same page using AJAX to get data - you have
in fact created an ASP.NET program that is as monolithic as a 5250 DSPF
based program simply because you bind the data source to the program that
delivers the UI and that are in front of the data source.



HTTP based CRUD and BL services has to live their own life on the HTTP
frontier exactly like SOAP and not live their live under a middleware
frontier hidden deep in the server and by that be bound to the middleware’s
ability to provide UI and thereby accessibility for this or that device or
used for this or that in an UI application.



A real SOA based system has no device depend UI, it is as simple as that!
The UI is another application that just uses the SOA services on client
level just like it may use Google Map API’s or streamed data from NASDAQ
from other servers.

On Tue, Feb 7, 2012 at 9:47 PM, Holm, Paul <pholm@xxxxxxxxxxxxxxxxx> wrote:

Henrik,

We had an interesting discussion about this very thing on linkedIn.
We estimate about 75% of code in typical IBM i applications falls into your
CRUD category. The other 25% is process, workflow, and event handling.
Ideally, you don't want to have to duplicate/generate code for each set of
file CRUD service. The code is the same, only the library, table, and
field names change so you can make the file specific code generalized as
well. Regardless, optimizing production of CRUD features is a big time
saver.

The discussion identified the lack of "Inversion of Control" (Ability to
handle Interfaces/Abstractions) within RPG as a primary design inhibitor to
enabling flexible systems.
http://en.wikipedia.org/wiki/Inversion_of_control

-Paul H

--
PlanetJ Corporation
www.planetjavainc.com
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.