Re: Fast400 Value to iSeries community is less than zero -- MIDRANGE-L

I dont object to the separating of business logic from presentation logic,
it is the use of the dtaq as the interface and the mandatory placement of
the business logic in a separate job that I disagree with. The alternative I
support is the module call interface.

Now if behind the business logic module call interface is logic that
offloads processing to a background job or another system, there would be no
objection by my argument. What happens below the interface is the business
of the interface provider. ( C++ is very good at this type of interface
definition and deliniation )

My objective in all this is to highlight how IBM's underpowering of its
interactive systems causes design decisions which increase system complexity
and limits the use of highly functional but cpu hungry languages like C++.
And I further state that IBM does not have to worry about losing revenue by
taking off the governor because new applications, implementing new
functionality, of which what you have described is a good example, will use
the newly provided CPW.

Steve Richter


----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Saturday, November 10, 2001 10:49 PM
Subject: RE: Fast400 Value to iSeries community is less than zero


> > -----Original Message-----
> > From: Steve Richter
> >
> > The only tradeoff I see that justifies the client/server model is the
low
> > horsepower of a CFINT system.
>
> Just to name a few:
>
> 1. The ability to have services on different machines.
> 2. The ability to have services on different platforms.
> 3. The ability to have different user interfaces for the same business
> logic.
> 4. The ability to offload work to dedicated subprocessors.
> 5. The ability to dynamically assign more resources to critical work.
> 6. The ability to have databases that span machines, platforms and media.
> 7. The ability to incorporate new technology that you haven't even thought
> of yet.
> 8. The ability to broadcast transactions to multiple environments.
> 9. The ability to bridge multiple systems seamlessly.
>
> All of this is completely transparent to the application in a distributed
> programming environment.  The message broker can route transactions
wherever
> they need to go.  Work units can be spread among multiple processors as
> appropriate.  This is nice to allow load balancing that favors data entry
> during the day and batch processing at night.  Jobs can be sent to other
> machines.  This is great when a task begins to consume too many resources
on
> your host (for example, converting spooled files to PDF documents - you
can
> easily offload this process).  A transaction can be broadcast to multiple
> sites (this is especially important when merging multiple systems).  The
> broker can translate a request from one format to another when it
recognizes
> that the data needs to come from an application other than the originating
> application.
>
> A client/server, or distributed, architecture provides the flexibility
that
> allows systems to interact seamlessly without writing all kinds of
> system-specific integration code.
>
> Joe Pluta
> www.plutabrothers.com
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>