|
> From: Pat Barber > > I ain't laughing.... I been wondering the same thing. > > Based on the responses, I would say this is a real concern. > > I noted that almost every single reply gave a "different" > way to "move forward", which is exactly what this "no standard" > method I see in this whole thing. > > If you hear of a solid, well documented, proven solution, let me > know. I've avoided this conversation up until this point because it tends to bog down into that semi-religious "mine is better than yours" type of discussion, and I've been involved in too many of those over the years. However, there is a reasonably simple answer depending on one specific business issue. That issue is whether or not you plan to stay with the iSeries, and if so, if you plan to stay with IBM's strategic direction. If the answer to both questions is yes, then it's absolutely clear what your choice of tools should be: WDSCi to develop JSP-based applications to run under WebSphere. Ask any of the development groups at IBM, and the entire focus of the tools teams is on developing for JSPs and WebSphere, and the great majority of the budget for tools development is being dumped into WDSCi (and the rest of the WebSphere development suite, such as WSAD and WSSD). This is not an opinion, not a "nice to have", not a marketing gimmick, not a pet language. All IBM development is geared towards this brave new world, and whether you agree with it or not, any money you spend on other solutions is going to be wasted. This includes screen scrapers, CGI, Net.Data, Python, Perl, and .NET. Just like I'm no big fan of SQL, but I know I have to embrace it as part of the strategic direction, so too is JSP, especially JSP Model II, IBM's architecture of choice. There are still a ton of issues here. Hans' points on XHTML and CSS barely scratched the surface of the web design question; issues such as Section 508 accessibility, JavaScript, and document layout are all still being hammered out at this time. But it is clear that IBM has chosen WebSphere and JSP as the strategic solution to deliver that information to the browser. The only real competition at this point is the .NET architecture. But because of the Microsoft lock-in and the obvious lack of working relationship between the two behemoths, it comes down to a matter of which side of The Force you choose to join - Redmond or Armonk. I leave that choice to you. All of the other approaches, from RPG-CGI to Net.Data to the many Unix-based specialty languages, are little more than stopgaps. None have reached any level of widespread acceptance. This statement might be challenged by some, but rather than rely on zealous advocacy, you should instead do some research to see how many businesses in your particular market niche use any given technology. Also, all of these lesser known solutions tend to be at least somewhat proprietary. Sure, you can run Python on an iSeries, but who's going to support you when your website crashes with an unknown error? Not IBM. On the other hand, all of those niche technologies are very good for learning, for pilot projects, and for non-strategic applications. They allow you quick results with a limited investment, and you can get started immediately. Of course, the cost issue is no longer a big one these days with WebSphere Express and WDSCi; $2000 gets you a working copy of Express and the WDSCi tools come with the compiler. The learning curve is longer, but the strategic positioning is unassailable. And that's my .02. Remember, I sell a JSP based product, so I'm biased. However, I've been selling a JSP-based product for years now, and I'm still selling it, so it must be an architecturally sound choice. Joe Pluta www.plutabrothers.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.