The design of the business logic depends somewhat on your preference for communcations... There are a variety of mechanisms that can be employed on System i that could support this; SQL stored procedure call, Web Services call, Java JT400 program call, DataQueue server, Sockets server, XML-RPC, and so forth. The communications options could influence the business logic design...
In any case, you need to be able to handle three primary interfaces to your business logic: input, output, and exception handling.
Regarding your question about the use of monolithic programs, I believe IBM does offer tooling to allow green-screen applications (complete with DSPF) to be accesses via SOA tooling. This entails the use of HATS to convert the DSPF IO into beans and scripts, then makes these available to the ESB (sorry if I get some of this wrong, it's been a while since I looked at this..).
I would not recommend this unless there is a compelling need to deliver services quickly....
Eric
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Jake Bruster
Sent: Thursday, October 04, 2007 11:32 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Business Logic Servers ( was: MVC in RPG?)
The "how to" of writing an UI agnostic business logic server from scratch is
exactly the process that I'm trying to understand. Although I've seen many
references to the use of these servers, I've not been able to find an
article, book, or CBT course that fully describes the implementation details
and the process for creating one of these servers using ILE RPG best
practices.
My original question was an attempt to derive the scope of the server. Is
there a one-to-one relationship between the server and the traditional
monolithic green-screen program or should the server be more
generic with some type of "controller" program sitting between it and the
UI?
On 10/3/07, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
Yes and no, Jake. While you can take an existing program and turn it into
a
server using this technique, you can also write the server program from
scratch to be UI agnostic. The nice thing about the approach in the
article
is that it provides a quick way to turn an existing monolithic program
into
an interim server, giving you an opportunity to immediately start working
on
the UI portion of the system even before you have your long-term server
architecture in place.
In any event, I'm tickled that you found that old article; it shows that
I've been saying pretty much the same thing for a decade or more now
<grin>.
Joe
As an Amazon Associate we earn from qualifying purchases.