Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

The iSeries: The Once and Future King

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • The iSeries: The Once and Future King

    The unique requirements of your shop make JSP/servlets a bad choice. In your shop, everything must be homogenous, so that you have no points of failure. Thus, you are immediately stuck with whatever all your people can learn. And since they can't learn Java, Java is out! ALso, since you consider Java and a vendor tool the same thing, Java has no monetary benefit. Given this situation, servlets are not a good architecture. Joe

  • #2
    The iSeries: The Once and Future King

    cdr5000, A very astute analysis, my hats off to you. As an extension to your analysis, I add the following points... - All of my iSeries staff of 10 developers are senior P/As. Their BEST attribute is that they are good business analysts first and programmers second. I try to provide the tools that maximize their best skill, the analytical part, and allow them to minimize their coding time. This is probably the case for most iSeries shops. It's a "graying" crowd that has a lot of business savvy that should be exploited. - OTOH, my web programming staff of 11 developers work primarily in code using C# and ASP pages to deliver web pages. Much of the analysis and requirements are created by the end user departments, mostly advertising dept and customer service dept. It's a "young" staff that doesn't yet have the business analysis savvy but are excellent coders. I believe in utilizing the talents that we have and not replacing the talent with "newer and better" talent to support the latest technology. I've been in management for 30 years and if there's one thing I've learned is that the costliest expense to my department, BY FAR, is turnover. It is disruptive and just kills continuity to projects. On my staff there are 5 iSeries personnel who have been here over 10 years, a couple as long as 20. No programmer has left in the 4+ years I've been here. That makes my staff VERY productive and reduces cost. So, that is why Java won't be a part of our company's roadmap. And now that IBM has made clear signs that they are de-emphasizing Java maybe there will be some sense of realism about Java's place in the real world. It's a tool, just as WebSmart is a tool. Choose the one that fits your environment best and makes the best FINANCIAL sense for the company's future and a lot can be accomplished with minimal risk. chuck Opinions expressed are not necessarily those of my employer. "cdr5000" wrote in message news:6b229b3b.29@WebX.WawyahGHajS... > The dialogue Chuck and Joe are having here is, to me, an excellent example > of "Coder vs Manager" or 'Old IT vs New IT". A lot can be learned from it. > > Chuck takes the long view and thinks in terms of quality control and > productivity. Meeting the goals of the company in a way that minimizes > personality or individualism is the rule. To this end, he uses common but > highly effective IT tools and does so in a way that maximizes their > combined strengths and minimizes weak points. > > The BCD tool seems like a wonderment. I suppose if BCD developed a newer > one that allowed even higher productivity with an even more homogeneous > labor force, he would consider it for purchase. > > Joe seems to take a programmer-is-the center-of-the universe approach to > IT. Stick building from scratch in a labor intensive way seems to be an > underlying theme. The programmer seems to be the center of all the spokes. > > Considering we are now in a clearly global economy that is no longer > dominated by U.S.initiative, the prudent approach for success would be to > start with a zero base and build up, when possible and practical. > > Buy vs build is a common idea that now makes even more sense to ponder. > Need to have vs nice to have is another. Reduced head count is another, > even if it involves programmers. (The coders who hack hairballs whenever > unpleasant ideas are mentioned in their presence should feel fortunate to > still be programmers.) > > Off the shelf solutions that can be quickly molded into custom > combinations will rule. Not the 'making it just for you' approach. > > I hope IBM gets it right this time.

    Comment


    • #3
      The iSeries: The Once and Future King

      Joe, Agreed. We're only talking about tools. In fact, the iSeries itself is just a tool. The best IT managers are the ones that understand that IT is a customer service department and NOT a technology department. The technology should always play a secondary role to how well the end users are being served. My job as manager is to maximize the efficiency of my staff and increase their ability to respond to the needs of our customers, internal and external. I only view technology as a method to increasing efficiency. Believe me when I say a smart business analyst with great customer service skills that can piece together components is considerably more valuable than a heads down whiz bang coder who do miracles with a keyboard. If I had a staff of a 100 or so then maybe I'd have room for the coder but, like most small shops, I don't have that luxury. I've managed many programmers in the last 30 years and the one constant among iSeries programmers (not so with PC programmers) is that you can only push them so hard when comes to learning new technology before their efficiency starts to suffer. I push as hard as I can to get the most out of them. There are a few, very few, that will take to new technology and run with it. They will get the special projects. chuck Opinions expressed are not necessarily those of my employer. "Joe Pluta" wrote in message news:6b229b3b.28@WebX.WawyahGHajS... > The unique requirements of your shop make JSP/servlets a bad choice. > > In your shop, everything must be homogenous, so that you have no points of > failure. Thus, you are immediately stuck with whatever all your people can > learn. And since they can't learn Java, Java is out! > > ALso, since you consider Java and a vendor tool the same thing, Java has > no monetary benefit. > > Given this situation, servlets are not a good architecture. > > Joe

      Comment


      • #4
        The iSeries: The Once and Future King

        Joe said: "In any event, I'm done here." And you call me rigid? Joe said: "I am saying that serlvet/JSP architecture is technologically better than RPG-CGI." This may be true. It's entirely possible that a true LCD TV is superior to a plama TV. Did you immediately sell your plasma TV when a large enough LCD was announced? (I assume that you have at least a plasma as that was the latest technology circa 2003. ;-) ) Joe said: "This is not a business decision, this is a comparison of technologies. " Businessmen compare nothing without knowing the impact upon business. Comparison of technologies in a vacuum, as in my large screen TV example, is only interesting for dicussion purposes, not for decision making purposes. Decisions made only on the basis of technology are doomed to failure. Joe said: "Thus, you are choosing an inferior architecture in order to meet your business requirements." Exactly. In essence we are choosing the superior solution which may, in some cases, cause us to use a less cutting edge or less robust technology. We also use Microsoft Office, which many consider inferior technology, for our desktop solution. The fact is that it works and works well. And MS Office is something all my end users know how to use. Joe said: "you have a web development team, they could be using C# and ASP.NET to access the data created by your RPG programmers." Which they do. Joe claimed: "Finally, your constant insistence that your RPG programmers are resistant to learning new technologies simply indicates to me that your hiring practices and mine are very different." Most of my staff was here when I arrived. Unlike many leading edge surfers I'm not in the practice of replacing existing talent and skills to use the latest hyped technology. If that were the case I'd have to replace my staff about every 2 years or so. Java is the hot button this year, what will be the hot button next year? Joe tried to claim that I said: "my people code RPG, won't learn anything else, don't want 'em to" Yet Joe has found no evidence that I ever claimed such foolishness. chuck Opinions expressed are not necessarily those of my employer.

        Comment


        • #5
          The iSeries: The Once and Future King

          Joe said: "We've had a nice civil discussion, which as usual has ended up at the fact that your staff and your business requirements preclude basically any new technology." I will NOT agree to that statement. If, however, you modify it to say the following I will agree with you: "We've had a civil discussion, which ended up with the fact that Chuck and his staff didn't follow the recommendations laid down by Joe Pluta and used technology to best serve his company. The solutions often include the "best practices" and include aggressive use of new technology with a minimized risk factor." chuck Opinions expressed are not necessarily those of my employer.

          Comment


          • #6
            The iSeries: The Once and Future King

            Joe Pluta said the following on 3/29/2005 6:24 PM: > Buck, I hope I was able to make clear in my posts > that I don't think you should have all-Java. No problem there. > But, in my time working with many different > architectures, it's become clear to me that a > JSP/servlet architecture for the UI which then > delegates to an RPG infrastructure for business > logic is by far the best solution, and is most > easily implemented by most companies. Again, I completely agree with you. The issue I was trying to address is that (exactly as you said) you can't upgrade to new tech simply for the sake of new tech. On the other hand, it is very difficult to sell the advantages of new tech if it isn't in your shop for the decision makers to try out. And without them able to kick the tires, they think that us programmer types are trying to spend money just for the cool factor. It can be very difficult to get new technology (even stuff as 'new' as CGI) into a green screen shop sometimes. By that, I mean new tech for the in-house programmers. On the other hand, the tools guys have stuff they can demo, so it can be an easier 'in' for the decision makers. In summary, I'm not critiquing your post; I agree with every single thing you said. I simply don't know how to pitch new tech internally. --buck

            Comment


            • #7
              The iSeries: The Once and Future King

              What if there was a free, relatively low-feature "JSP Starter Kit" taht allowed you to quickly knock together a couple of screens that talked with RPG programs? It could install either as an EAR file with WebSphere or maybe even with Tomcat. It would allow you to write a simple program that communicated with a JSP using a data queue, and instead of EXFMT you did a call to an API to send the data. It would be no-cost, but no support either. It would come with an example program and enough documentation so you could clone one of your own. Total time from download to demo would be under an hour, and creating your own clone would be measured in hours. Would that help get the technology in the door? (Again, this would be a pretty light architecture, not a lot of security or scalability, but just an introduction to the technology.) This is not a pitch for a product, but just something on my event horizon. Joe

              Comment


              • #8
                The iSeries: The Once and Future King

                Chuck, I'm a little confused. The discussion has been about JSP versus CGI because of your long ago question for Joe to cite an example of superiority, which others asked as well, and which he responded to. But your posts refer to your third party product (BCD) primarily. Is that because BCD uses CGI, and of course whether it does or not, we all understand the backend technology used would be transparent in any event. So I think the benefits of using a third party tool for web page generation is a higher level discussion than the underlying technologies used. In fact, the only way it would come into discussion is if the oft noted in the past and unknown to me whether it still exists CGI flaw on the AS/400 of spawning off a job for each page at a much higher cost than spawning a similar process under Unix thus causing performance problems which would be the only reason to discuss it. It's really irrelevant what backend technology BCD uses. It works well for your mission and you're happy. It is not a unique or even rare set of requirements that you have. I disagree with all of the characterizations ascribed to your shop and decision making in this discussion. I have seen millions of dollars thrown away on systems that promised to do a lot more than BCD but the efforts failed miserably, one of the largest was at SSA using their own case tool AS/SET to re-engineer Order Entry, but also some nearly as large using the GUI follow on to Synon, the name changed frequently to protect the guilty. I have also seen efforts that worked, usually when less was more. BCD seems to be one of those less is more successes. In any event, neither your requirements, your staff, nor your solutions including IIS and ASP are unusual or that uncommon. Maybe different third party solutions, but still the same principle. I fail to see how different underlying technology would be more effective, not just for you, but for anybody. Of course I've also seen the limitations as well as power of these products in failure and success, and there are a ton of solutions besides BCD. Too many, in my opinion. I will not rest until IBM provides a standard rich client GUI interface for the AS/400. In the meantime, however, $12k is little to pay for such a robust solution that includes many of the features of tools used in those multi-million dollar disasters. I really don't care what underlying technology is used when it works. rd

                Comment


                • #9
                  The iSeries: The Once and Future King

                  Ralph, WebSmart by BCD is programmed in a pc based ILE. When a program is generated from the ILE it is an RPG ILE program. It is a CGI program. When I look at the free form RPG that is produced it is very clever and very efficient. Does that answer your question? Or did you have something else in mind. Whether it scales or not I don't know since we only have about 1500 internal users. I do know that each web page is presented, as a general rule, in subsecond response time. There is no discernable difference in response time between a WebSmart web page and a green screen. I had my first WebSmart program running within 2 hours of receiving the CD. It's still running in production 2.5 years later. I can't say that about any other web based solution I've tried. We have hundreds of web based programs that have been developed over the last 2.5 years, some of them extremely complex where the JavaScript and HTML are completely built on the fly within the program. Certainly something we would never have thought of doing in green screen. The beauty of web development as I tell my staff is that a web page is just text. Learning to parse that text makes a programmer very powerful . I haven't really mentioned the name of the product in my posts very much because I'm not an official spokesman for them. But, I gotta tell you, BCD and Excelsystems, are the best vendor I've dealt with in my 30 years of management. Bar none. These guys are real pros and know what they're doing. I've yet to encounter anyone that does it better. They know customer service. When I call them a person always answers. And, 99.999% of the time the person that answers knows their product well enough to answer my questions right then and there! And, you gotta believe, when I call it's not a trivial question. I often email with non-WebSmart questions (often relating to HTML or JavaScript.) Most of the time I get a return email with working code to show me how to do what I want to do, often within the same day. Great group of guys. Ok, enough of the advertisement. The bottom line is that we use the tools that work the best for our organization. chuck Opinions expressed are not necessarily those of my employer. "Ralph Daugherty" wrote in message news:6b229b3b.40@WebX.WawyahGHajS... > Chuck, I'm a little confused. The discussion has been about JSP versus CGI > because of your long ago question for Joe to cite an example of > superiority, which others asked as well, and which he responded to. But > your posts refer to your third party product (BCD) primarily. > > Is that because BCD uses CGI, and of course whether it does or not, we all > understand the backend technology used would be transparent in any event. > So I think the benefits of using a third party tool for web page > generation is a higher level discussion than the underlying technologies > used. > > In fact, the only way it would come into discussion is if the oft noted in > the past and unknown to me whether it still exists CGI flaw on the AS/400 > of spawning off a job for each page at a much higher cost than spawning a > similar process under Unix thus causing performance problems which would > be the only reason to discuss it. > > It's really irrelevant what backend technology BCD uses. It works well for > your mission and you're happy. It is not a unique or even rare set of > requirements that you have. I disagree with all of the characterizations > ascribed to your shop and decision making in this discussion. > > I have seen millions of dollars thrown away on systems that promised to do > a lot more than BCD but the efforts failed miserably, one of the largest > was at SSA using their own case tool AS/SET to re-engineer Order Entry, > but also some nearly as large using the GUI follow on to Synon, the name > changed frequently to protect the guilty. > > I have also seen efforts that worked, usually when less was more. BCD > seems to be one of those less is more successes. In any event, neither > your requirements, your staff, nor your solutions including IIS and ASP > are unusual or that uncommon. Maybe different third party solutions, but > still the same principle. > > I fail to see how different underlying technology would be more effective, > not just for you, but for anybody. > > Of course I've also seen the limitations as well as power of these > products in failure and success, and there are a ton of solutions besides > BCD. Too many, in my opinion. I will not rest until IBM provides a > standard rich client GUI interface for the AS/400. > > In the meantime, however, $12k is little to pay for such a robust solution > that includes many of the features of tools used in those multi-million > dollar disasters. I really don't care what underlying technology is used > when it works. > > rd

                  Comment


                  • #10
                    The iSeries: The Once and Future King

                    Joe stated: "Anyway, the only reason I chose to discuss this with you was because you asked a seemingly innocuous question about how JSP/servlet technology was superior to RPG-CGI." Joe, you're in a business that is entirely wrapped around selling solutions based upon Java. I would expect that you must be a Java advocate or it would undermind the message that you're sending. Unfortunately that's a little like IBM telling us that the iSeries should be used for all of our computing solutions. Sure, it can be done, but that doesn't make good business sense. You, like IBM, have have a vested interest in the technology being used. I, OTOH, have the flexibility to choose the best solutions for my organization. I base that on what makes the most sense for the requirements at hand. I don't have a vested interest to protect. The underlying technology is generally not near the top of the list when making that decision. I can tell you that as a manager I'm constantly bombarded by everyone and everybody telling me that their solution is the best. They will often use the same tactic that you use and try to belittle anyone that doesn't choose their solution. I'm much more likely to listen to the vendors that have a great success story to sell without making unbelievable and outrageous claims and insulting potential customers intelligence. I know you believe that I'm the ultimate stick in the mud idiot...that's clear in your posts. But I think of my company's interests first. Always. I'll never jump to the latest and greatest thing because it may enhance me or my staff's careers. That's just irresponsible management. You can go on and on how your solution is best for me. But clearly you have done NO homework on my company or my decision making before making such statements. Is that how you treat any potential customers that disagree with your statements. And, while you make the claim that Java is the best solution, you are a vendor of a Java solution. Vendors who claim that their solution is the one and only are immediately suspect. I imagine if you take a pole of all IS managers you'll find that the minute a vendor makes outrageous claims as facts the manager stops listening. chuck Opinions expressed are not necessarily those of my employer.

                    Comment


                    • #11
                      The iSeries: The Once and Future King

                      I have deleted several comments that I wrote. Their tone was less professional than I would have liked. I am dismayed at how quickly my discussions with some people turn uncivil. Luckily, there are only a handful of such people, and I can usually avoid those discussions. I'm just going to answer the question asked: why do I consider JSP Model II (JSP/servlet) architecture better than RPG-CGI. I am not going to address any particular situation, because every situation is different and I don't have enough knowledge of your company to make any conclusions (I said this in the article). So, if your company's business requirements remove Java as an option, then I feel badly for you, because it precludes you from using the best architecture available. But I'm not going to argue your company's goals. That's the kind of thing that leads to flame wars. I don't consider Java the silver bullet, either! I'm one of the most vocal advocates of RPG in our community. At the same time, I have over the years become convinced that a very thin JSP Model II veneer is the best solution for a web UI, and I have explained why in great detail, both here and in columns and seminars. In specific situations short-term business goals may dictate specific short-term solutions. But barring that, the best architecture from an ROI standpoint, a legacy asset protection standpoint, a human resources standpoint (both existing staff and new), and a sales and marketing standpoint is JSP Model II connected to an RPG back end. Not to mention the fact that it's the best technically, for the reasons I outlined earlier (security, flexibility and so no). And please recognize that I'm talking about complex business applications such as order entry, not database queries. For queries, pick the cheapest tool that meets your needs. Turn a script kiddie loose with PHP and you can get some pretty incredible results. But for real, multi-tiered, web-enabled, transaction processing, nothing beats JSP Model II and RPG. As a final point, I'm not talking about replacing your chart of accounts maintenance program with an Internet-enabled client/server program just for the heck of it. I'm assuming that you've already identified a need for web-enabling as least some portion of your core busniess processes. If you do not have that need, then JSP Model II technology is not required. But if you need to web-enable mission critical core business systems that are more complex than an SQL SELECT statement, then JSP Model II and RPG is the way to go. Joe

                      Comment


                      • #12
                        The iSeries: The Once and Future King

                        Joe, I got to thinking about the underlying technology theme that we've been discussing and I'm willing to concede. You claim that Java is the best technology to communicate to/from a web page. In fact, you go so far as to say that a shop need only one person to manage the java servelets that talk between the user and the back end via a web page on the iSeries. The largest argument for this is because Java seems to scale better. OTOH, for those shops that don't need scale I'd say that native I/O in RPG would have better response time. So, here's the concession. Use WebSmart. At your choice it can generate either RPG ILE or Java. That way you can decide whether you need scale or quick response. And, there's only one language to learn no matter which way you go. Also, if the Java option is used then any file on any server on the network can be accessed, it doesn't have to be on the iSeries. By the way, WebSmart is not a simple "code generator" as you sniped yesterday. I can only assume that you were taking a jab at a competitor or you have a complete ignorance as to how WedSmart works. I think we're on the same wavelength now. chuck Opinions expressed are not necessarily those of my employer.

                        Comment


                        • #13
                          The iSeries: The Once and Future King

                          I got to thinking about Joe's argument that Java is superior technology and, as such, should be the choice for communicating to a web page on the iSeries. I have to say that while I may agree that Java is superior technology, it may not necessarily be the better choice. In fact, this got me to evaluating the choices I've made in my life both personally and professionally. In reflection I realize that we often choose inferior technology over the best technology. Then I reflected on why that happens and the simple answer is that technology is only one component of decision making, often it's only a minor piece of the decision making process. For example... In the late '70s I chose VHS over Betamax. I will be installing an iSeries model 520 on Saturday instead of a model 570. On my business and personal desktops I use Windows XP instead of Linux. We use Good email communicators instead of a Blackberry. I use Paint Shop Pro instead of Adobe Illustrator. My desk at work is particle board with a Formica top instead of oak with walnut inlays. I drive a Mustang convertable instead of a Porsche. I have a Kenwood in-dash MP3 CD player instead of a Kenwood in-dash DVD player. I prefer analog clocks to digital clocks. I use a Garmin GPS Palm device instead of a Pocket PC device. I went to UCLA instead of MIT. I wear dress shirts from Mervyns instead of those from Nordstrom. I live in Southern California instead of Maui. I married a Polak instead of a Swede. I think what I'm trying to say here is that decisions are made with MANY inputs and what may appear to be the wrong choice to an outsider is often the right choice when all of the requirements are measured. chuck Opinions expressed are not necessarily those of my employer.

                          Comment


                          • #14
                            The iSeries: The Once and Future King

                            Joe, You wrote: "For example, you'll be hearing more about RPG-CGI and how it can do anything JavaServer Pages (JSP) can do. This statement is wrong, and it detracts from the reality, which is that RPG-CGI is the only real solution for companies with limited resources, all in RPG." I'm not quite sure I see any proof in your article for these assertions. First, I believe CGI is a solution for any size company. We have done scaleability tests for literally thousands of hits per second on small to medium sized iSeries and i5s and CGI holds up fine. Second, you need to compare tools using CGI to tools using Java, not just the languages- the languages in themselves do nothing special. There are great tools out there (my company produces one of them) that produce CGI applications as well as those that produce Java Server pages. Third, I don't understand your comments about security. CGI programs can be written to be just as secure as any Java servlets. They can do the following: 1. Use SSL connections for secure transport of data 2. Use standard encryption methods such as 128-bit AES encryption to protect stored data on server or client 3. Use unspoofable session ids to maintain secure, persistent connections 4. Use iSeries or i5 user profile security 5. Use standard web server (Apache or original) security (authentication/authorization/protection etc.) 6. Use adoptable iSeries or i5 user profile security 7. Use iSeries or i5 native operating system-level security (objects, locks, etc.) Also- just as a further point of accuracy - CGI is not limited to RPG on the iSeries. In fact, often it's useful to use ILE C routines and incorporate these in CGI applications. Since the iSeries/i5 provide a whole wealth of languages that work in the ILE model, you have considerable flexibility over how you write CGI applications. Certainly, RPG is most often mentioned, but once you have an ILE module or service program, written in any language, you can treat it just like the black boxes you describe for Java Server pages, thus providing you with extensible, reusable functionality. It might be a little disservice to the iSeries programmer community to discount the wealth of programming routines (or black boxes) already available to us that can be used in web programming. Our company has written many web applications for many clients, in addition to producing a web development tool. A minimal amount Some of that work has been done in JSP, but we have NEVER found anything that cannot be written in ILE CGI (I'll avoid the 'RPG' red herring)- usually for a lot less money, in a manner that other developers can easily understand and work with, and with fast, efficient deployment. To reiterate, I'd like to see proof for your assertions. Duncan Kenzie

                            Comment


                            • #15
                              The iSeries: The Once and Future King

                              Joe, Perhaps you could explain this statement for me in more detail (I've probably missed an earlier explanation: "a very thin JSP Model II veneer is the best solution for a web UI" I'm confused because: 1. JSP is server-side technology (isn't it?) 2. A 'web UI' is produced by client-side technologies, such as: - HTML - CSS - Javascript - HTML behaviors (or HTC's) - ActiveX's - XML and various XML technologies such as XSLT So isn't this really an incorrect assertion? ILE CGI can deliver these exact same client-side technologies to a browser as JSP. So how does this make JSP better? I'm still not clear on why Java is the best architecture going, either. Oh, well... Duncan Kenzie

                              Comment

                              Working...
                              X