|
> -----Original Message----- > From: Steve Richter > > Changing your appl design as a workaround to IBM's pricing of interactive > CPW is more proof of how CFINT hurts our platform. While I don't much like the CFINT issue, I still think everyone should be thinking client/server anyway. If all of our systems were client/server, we wouldn't be worried about CFINT. I design the infrastructure once, and now I have all the benefits of client/server design. A single point of entry (and change!) for my business logic, a single place for auditing and security, the ability to change my database layout independent of my applications, and the ability to move my database and business logic to other machines, even other platforms. Client/server design provides unparalleled flexibility for what is really a very small cost. Let's review your objections: > When you add a layer ( in > this case many layers ) to any software, you increase its complexity. That > is bad. By separating out the business logic into a called program, you've done almost all the work necessary for a client/server design. > Instead of your "interactive presentation layer" calling a common > pgm to apply the dsply entry to the database, your approach is to fill a > data struct, And how to you send the data to your common program? Unless you either are passing a trivial amount of data, or you like maintaining huge parameter lists, you pass a data structure. No difference. > write to a dtaq, You call a the server API rather than calling the update API. Not a lot of difference there. > hope the server job is running, wait for a > response from the server. This is all part of your server API. Write it once, and forget about it. If you've never written a client/server architecture, it's challenging, but once you've done it, you're done. And this is the bulk of the difference between the two approaches. > And then you have to code and document > the server job. As opposed to coding and documenting the update API. No difference. > Very complex. If you have a good appl design reason to do > this, fine. > But if it is done because of IBM's pricing of interactive CPW > then, that is > not fine. So, in essence, the difference between calling an update API and using a client/server design is that you have to write the client/server infrastructure. Once. Do that, and you have all the benefits of client/server, plus the added benefit of reducing your interactive CPW requirements. So the only thing stopping you is the fact the work involved in designing a solid, robust client/server API. I know it sounds a bit daunting, but I'll be honest with you, it's not that difficult. I teach one in a week that's pretty much usable for any sort of iSeries application; it's currently in heavy use in of all things a COBOL implementation. Joe Pluta www.plutabrothers.com
As an Amazon Associate we earn from qualifying purchases.
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.