web to 400 communicaiton methods

[nycsusan@hotmail.com]

web to 400 communicaiton methods

Joe wrote: "Ralph has done an excellent job of outlining the requirements for a server system. " Yes, he certainly has, and I appreciate his help very much. But now I am little confused. I guess I misinterpreted your posts because you seemed to be shooting down Ralph's suggestions. That is why I asked you for more details about your ideas. If you feel that Ralph's suggestions were good, then why all the back and forth between you guys? Or has the debate worn you down and you have given up arguing? :-) Really, I thought you were disagreeing with Ralph most of way, but I guess I misunderstood. Thanks for the clarification, Joe. I appreciate the time that you, Ralph, and David have spent helping me.

[J.Pluta]

web to 400 communicaiton methods

"Yes, he certainly has, and I appreciate his help very much. But now I am little confused. I guess I misinterpreted your posts because you seemed to be shooting down Ralph's suggestions. That is why I asked you for more details about your ideas. If you feel that Ralph's suggestions were good, then why all the back and forth between you guys? Or has the debate worn you down and you have given up arguing? :-) Really, I thought you were disagreeing with Ralph most of way, but I guess I misunderstood." The approach of mapping one or more server calls to a message request is in general a good idea, Susan; it serves to reduce the binding between the client and the server. My problem with Ralph's approach is twofold. First, passing through HTML from one web server through another is an added complexity that just doesn't need to be there - having to run and maintain two web servers where one would do is simply goofy to me. Second, I don't like sticking a proprietary piece of software right in the middle of my business application. If you happen to hit a bug (or "design limitation"), you are STUCK unless the vendor decides to fix it. I became more conciliatory when I realized what Ralph was up against: an entrenched NT bureaucracy with a lack of NT-to-AS/400 connection skills. In that case, the added complexity and overhead of a convoluted HTML approach may be "justified" by the fact that it will keep the NT people happy. However, this is a political, pragmatic solution, and a VERY bad precedent... in effect, you're saying that the NT people decide the architecture of your system. And frankly, NT experts, while often good at network configuration, are rarely very good at business application design. So, I wanted to make sure that it was clear that while the Strategi solution was indeed quick and made the NT guys happy, it was a kludge and architecturally I found it unsound. A little clearer? Joe src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[nycsusan@hotmail.com]

web to 400 communicaiton methods

You? Conciliatory??? I thought that the moon looked a little BLUE last evening! :-) Joe wrote: " ... when I realized what Ralph was up against: an entrenched NT beauracracy with a lack of NT-to-AS/400 connection skills. In that case, the added complexity and overhead of a convoluted HTML approach may be "justified" by the fact that it will keep the NT people happy. However, this is a political, pragmatic solution, and a VERY bad precedent... in effect, you're saying that the NT people decide the architecture of your system. And frankly, NT experts, while often good at network configuration, are rarely very good at business application design." What RALPH is up against?!?! I am up against it too, that's why I am begging for ideas from you guys! For the record, I brought up the "politics of NT" in my 2nd post, and I think Ralph mentioned it a time or two as well. I think we all agree that the politics of the situation stink and they shouldn't drive the solution, but we have no choice. That's life in corporate America. We have to work within the constraints they place upon us! Joe wrote: "A little clearer?" You betcha ... like Waterford crystal! :-)

[Guest.Visitor]

web to 400 communicaiton methods

Richard, I would not recommend that someone do anything until I understand what they are trying to do. Detailing several strategies should help Susan. I personally would rather use our AS/400 for everything, but it is not the best tool in all cases. Shipping the data off may be a viable solution (cheaper, more functional, etc.) Integration with back end systems is certainly the ideal, especially when the flow of data is bi-directional. It seems as though Susan is describing a very simple inquiry, if the next phase adds more functionality, then I would look at this differently. Without all of the facts, which would require more than a few paragraphs in a discussion formum, it is impossible to make an informed decision. The bottom line is that ODBC may work just fine. We have used it for very similar applications and it is certainly simple and worked great. We have also used it for applications where it was not the best fit. From what I have read, the customer may just be looking for an invoice image. If that is the case, nothing suggested fits the need. If the customer needs to analyze the data, an OLAP solution may fit. If transactional integrity needs to be ensured, a messaging layer may fit. "Especially beware the people who try to steer you into trivial SQL result set solutions because you have "view only" requirements...". I would beware anyone trying to sell an expensive solution if all I need is a trivial SQL result set solution because of my view only requirement. David Morris

[Guest.Visitor]

web to 400 communicaiton methods

I brought up the "politics of NT" in my 2nd post, and I think Ralph mentioned it a time or two as well. I think we all agree that the politics of the situation stink and they shouldn't drive the solution, but we have no choice I think Joe and Ralph actually had the same architecture suggestion, which is to build the AS/400 into a Service Orientated Framework Provider. The diagreement is more over the implementation. If you build the AS/400 to deliver application services then you can quite happily handle other platforms such as NT or UNIX connecting. For instance an NT IIS web admin is likely to be very happy building pages using ASP. And from ASPs you can execute OCX or ActiveX components (such as the DataQueues provided in client access) or ODBC data access. You should also be prepared to deal with the UNIX/LINUX Apache Web Servers who are most likely happy with CGIs or Java Servlets. I believe the majority of the web servers in corporate businesses are UNIX based. My Opinion What you should be looking for is to prevent business functions and data being moved to the web server. You should be looking to put that on the central business server (in this case the AS/400) Why ??? Because what you are building should be re-usable services. They should be able to be re-used as the business expands. Example We had a bank introduce Telephone Banking (Customer needs AccessID & PIN), we expand to introduce Internet Banking, we expand again to introduce Mobile Phone (WAP) banking. Each time we can re-use the Customer Authentication on the AS/400 server, there is a single limit check service that can be reused etc. It allows the front-end (Telephone is WinNT, Internet is AIX, WAP is Solaris) developers to focus on what they know best. It reduces user testing since the business rules servers are not changed (e.g. Invalidate the ID if 3 consective wrong PINs) With no additional software the connections to your AS/400 can be:

1. Data Queues (Client Access APIs for Win32 or Java Classes)
2. Stored Procedures
3. TCP/IP Sockets
4. ODBC/JDBC - direct data access. Something which goes against the concept of a service framework.
5. SNA (Dont laugh !! As additional security I know sites that only allow SNA connection from Internet Web Servers)

HTH David

[nycsusan@hotmail.com]

web to 400 communicaiton methods

Thank you David, I doubt the "e" group will propose UNIX or Apache. They seem to have a cookie cutter, one size fits most approach. I think I even saw an "NT" label on their cutesy little diagrams too, so it looks official to me! :-) Today I almost lost my lunch when I got my mitts on a document with a few of the requirements. Talk about a FLUFFY document, YEESH! Lots of verbiage, but with very little substance. Certain things did make me perk up ... for example, in "phase 4" (don't ask me what happened to phases 2 and 3 'cuz I just cannot imagine) they want to allow customers to view and pay their invoices over the web. I don't know what that changes, if anything, in your suggestions. This is the first I have heard of the update capability being mentioned. For this first phase, a customer should be able to download their file of data (which in this case is rated telephone calls). For large customers, CONNECTirect will be used. "Large" is defined as customers with more than 25,000 records in their file. There is no upper limit to this file, it could be over a million records, and they will have a new file each and every day. I am still waiting for my boss to respond to my questions about the requirements in this document. They are way too vague to do much about. In the meantime, I shall dive into the manuals and research all that you and Ralph have suggested. I want to learn more about this even regardless of this project. Thanks again for all of your ideas!

[Guest.Visitor]

web to 400 communicaiton methods

David Bye wrote: "Hmmm how is the startup of a CGI any better ?" I agree, David. BusinessLink Strategi does not use CGI. They recognized that the threading process to run CGI under Unix did not translate well to the AS/400 and its job concept, and that CGI job startup on the AS/400 was excessive overhead. As I posted yesterday, response time from one's server program called by Strategi to process a web page to the time it takes to get the page back on an internal network is 2 milliseconds. This is extraordinarily fast, but then BusinessLink isn't pushing a generic product that just happens to run on the AS/400 too, such as Websphere and Domino web servers. I agree that messaging through an AS/400 dataq is extremely fast. My memory is shaky on this, but I think I remember that we can have multiple copies of a program receiving on the same dataq, effectively letting OS/400 manage distribution to available servers instead of Strategi doing that. I have been around large scale implementations of transactions fed to the AS/400 from NT, and they have been very successful as you point out. The downsides are minimal. A third party Windows component must be chosen to read/write the dataq's or IBM's product installed. A messaging format must be laid out and programmed against on both sides. These two downsides are not what you and I and Joe would call downsides, they're normal interoperability requirements, but the political climate that Susan and I faced was not conducive to implementing the solid engineering needed to do this. Whether it seems petty or not, the web page HTML was a non-intrusive, easily understood mechanism for exchanging data with a minimum of cooperative programming required. Just the field names of what data would be exchanged. If you think that an NT IIS CGI programmer would prefer to write a message to a Windows component and handle the response to be integrated back into the web page and delivered to the customer versus posting the same info via HTTP and integrating the response into the web page, then I won't quibble. Given the beligerance of the NT programmers, the point was to avoid AS/400 specific technologies. It just gave them an excuse to say they weren't interested in dealing with an AS/400 dataq communications component or interested in agreeing on a messaging format with the AS/400 people. You have to remember, their goal is to get processing off the AS/400 and into SQL Server. Data exchange via HTTP is innate to their IIS processing, and so is stuffing form fields in CGI. On the other hand, that is dealing with a petty environment, and some NTer's may prefer a messaging format sent through a COM component. As I said to Joe yesterday, the Strategi server programs are written in a RCV/SND dataq like loop and could process through a dataq as easily as through Strategi. Either an internal name would be used which passed the parms on to Strategi when applicable, or Strategi's command name would be used in the library list for a program that read/write's the dataq's on the AS/400. The scalability issue comes up on a home brewed scheme to distribute messages not only to an available instance of a server, but to various server programs. For focused applications, one dataq with a dedicated server that can parse out the work to handle all the message opcodes is sufficient because the scope is narrower. For a web site, whether the pages are served by IIS or the AS/400, the number of opcodes to handle a website of web pages could be extensive. The programming of the servers may be in different languages. The jobs website had servers in ILE RPG, RPG III, and Java. Either a different dataq would have to be established for one or more instances of each server program, or a home grown threaded distribution system for messsage handlers would have to be written. You want to make that argument to others, be my guest. I tried MQSeries for real time messaging within a large corporate environment two or three years ago. MQ bogged down badly. We ended up writing a home brewed DDM distribution system to distribute transactions to all the AS/400's. Fast as lightning and well understood so as to handle failures well, not that we had any that I recall. Delta uses MQ for real time transactions, and had to put an AS/400 dedicated to handling MQSeries at each site, this according to articles on their problems in ComputerWorld at the time. I would no more use MQSeries to message while customers are waiting on their web page response than I would use snail mail. Commit/Rollback? I've never used it. Haven't seen it in BPCS, MAPICS, PMSC, JDA, Infinium, JBA, or JDE as used by Fortune 100's. There is a common perception that MQSeries provides such a thing when in fact the manual goes to great lengths to dispel that myth. What is done in your code around MQ API calls can be done in your code around any API calls. Assured delivery? That stuff is peachy in an offline corporatewide distributed environment. Web sites are funny in that they're both more and less demanding. The speed must be there, but if there's a timeout, resubmits by the user or a CGI program is acceptable in that environment. I myself wouldn't try multiple transactions across more than one web page in a stateless commit environment. A commit to update three files for an inventory transaction simultaneously? Like I said, ERP's have been updating files in sequence since the dawn of time. What, an I/O is going to fail? So we rollback, and tell the customer? I think if we were to go to the troubl e of defining rollback points then a commit can be done regardless of the messaging system. Strategi is mostly just a web server versus an application server. Any state that is desired to be retained must be stored with access by a transaction key, usually carried along in the web page, but Strategi does provide for sign in security, like this forum does, and if used there is identification information and state information available with each web page delivered to a server program. Nothing that couldn't be done with your own files, but they standardized that aspect of it as a way of making it easier to look up where we're at in the process and continue processing. Thanks, David, for some thoughtfil questions. Hope my answers and yours and Joe's suggestions lead to helping us all deliver some great software for the AS/400. Ralph

[Guest.Visitor]

web to 400 communicaiton methods

The revitalization architecture is 100% open-source and works with any web server that support servlets and JavaServer Pages. It will run on a Linux server with Tomcat just as well as it will run on as AS/400 and WebSphere. It requires no third party products, and will run on a vanilla AS/400. And it's free! Can't add anything to the ultimate....... Ralph

[Guest.Visitor]

web to 400 communicaiton methods

""Especially beware the people who try to steer you into trivial SQL result set solutions because you have "view only" requirements...". I would beware anyone trying to sell an expensive solution if all I need is a trivial SQL result set solution because of my view only requirement. David Morris " Websphere is free with the AS/400, I believe. I'm not selling anything, just for the record, David. Regards, Ralph

[Guest.Visitor]

web to 400 communicaiton methods

For this first phase, a customer should be able to download their file of data (which in this case is rated telephone calls). For large customers, CONNECTirect will be used. Large is defined as customers with more than 25,000 records in their file. There is no upper limit to this file, it could be over a million records, and they will have a new file each and every day. Ekkkk.......(thats my term for they are crazy) Suggesting ConnectDirect be installed on the remote sites....whos paying for that ? Sounds like IT Data Centre solution to me - it makes operations life easier, and bogs everyone down into a piece of software. Security will be interesting - how to ensure client A does not pull client B data. (I know have unique object rights for each file !!!) What if your company accidently send client A client B data ? Other options ?

[*] Pushing the file using email[*] Publish the file onto a webserver allowing clients to pull the file[*] Real Time message feeds to the clients - making the information more realtime and allowing business processes to improve accordinginly.[/list]they want to allow customers to view and pay their invoices over the web. Nothing too new here. This is a standard bill presentment and payment system. Call Oracle, Netscape Sun Alliance. How you link to a bank/s is a number of variations. Sounds like a fun project that needs some more thought in the design stage. David

[Guest.Visitor]

web to 400 communicaiton methods

Richard, I didn't realize that you were suggesting WebSphere as a replacement for SQL. You are correct, the Standard Edition of WebSphere is "free". I have spent quite a bit of time this year working with WebSphere, I can tell you that there is actually a substantial cost. David Morris

[Guest.Visitor]

web to 400 communicaiton methods

Hello Susan, We have a very easy-to-use alternative for you, however it does require a commercial product, so those who don't want to read this message, close your eyes right now :-) We recently introduced a new product called Active Server Pages/400 (ASP/400) which allows you to do the following from an NT IIS web server script: - Read/Write AS/400 Files Directly - Call exising program logic (COBOL, RPG, CL) and pass parms bidirectionally. - Submit remote commands - Communicate with AS/400 data queues Because you're using IIS and Active Server Pages, the AS/400 never touches the Internet. All AS/400 communications takes place between the AS/400 and IIS. Best of all you can continue to create RPG and COBOL code that your web scripts can call via Javascript or VBScript. We also have a live demo on our temporary web site. We're in the process of upgrading to a T1. The demo hits our AS/400 170 system via IIS. The IIS web server is a Pentium 200. Check it out: Link to live demo: http://rjssoft.dyndns.org/scripts/as...les/asp400.asp For more information, contact me via email or telephone or check out our web site. Regards, Richard Schoen RJS Software Systems Inc. "The AS/400 Report and Data Delivery Experts" Email: richard@rjssoft.com Web Site: http://www.rjssoft.com

[Guest.Visitor]

web to 400 communicaiton methods

David Morris wrote: "I didn't realize that you were suggesting WebSphere as a replacement for SQL. You are correct, the Standard Edition of WebSphere is "free". I have spent quite a bit of time this year working with WebSphere, I can tell you that there is actually a substantial cost." I was suggesting HTTP as a faster, cleaner, easier means of messaging from IIS to the AS/400 to process data in real time from the web page in IIS, with no tradeoffs to weigh against other than scorn from the messaging gurus. While the NT people politically manuever to offload processing onto SQL Server, I say just proceed with web development anyway. So what if you're serving to an IIS web server who's serving to the world. All one's development for this on the AS/400 is with e technologies and the company will soon see that an AS/400 can serve as well as or better than IIS as they shove pages back and forth to each other. At some point the company just may move those pretty picture web pages to IFS and be good to go. I recommend BusinessLink Strategi as the AS/400 web server, simply because I've used it extensively and it's tuned to delivering AS/400 solutions by programmers who still care about performance. If someone wants to go with IBM's generic dogs, that's their problem. But I'm not selling Strategi, and I'm not recommending a solution that requires one to buy something. On the other hand, should one choose Strategi, there is no learning curve required to put up a web site and deliver professional web pages with integrated data processed by one's own AS/400 programs... and not those HTML renderings of some green screens or rolling your own HTML code on the fly either. Professional web pages, developed by those your company will choose to do that work anyway and integrated with your AS/400 data by you without modifying their work. I have a thing against Rube Goldberg layers of technologies, and if the others haven't had their eyes glaze over reading a laundry list of technologies that are recommended to serve we b pages, then maybe I'm the only one who noticed... but I doubt it. Ralph

[Guest.Visitor]

web to 400 communicaiton methods

Susan, My first thought after seeing your request was, why don't people get a clue and just let the AS/400 - the best web application server on the planet provide the solution. But, then Ralph introduced an innovative solution that I had never considered, and over the course of a debate was able to iron out most of the confusion. Its too bad the people he worked with in Chicago weren't here to give more details about their IIS CGI work. Actually, it was a surprise to hear that Windows CGI was being used under IIS since Microsoft highly recommends Active Server Pages or their ISAPI interface over CGI. CGI starts a new process under Windows and is considered to limit scalability and performance. One point of confusion for me was Ralph's terminology about client programs sending web pages to a web server. To be more precise, web clients send HTTP requests as opposed to web pages to the web server, and the web server usually responds by sending a web page back. But don't let that detract from what is probably a great idea - to pass the request from the NT web server to the AS/400 web server and let an AS/400 program respond. Joe raised his concerns about an extra layer of overhead with a middleware product like Strategi, but Ralph did a good job of justifying it in his discussion of Stragegi's features and scalability. Besides, we tend to think that a strait data queue interface between NT and AS/400 is less overhead, but we forget that they require an installation of Client Access on the NT server (has a de-stablizing effect), and a queue server on the AS/400 that is itself a middleware layer which forwards the entry to a user written application. Not to mention that the NT guys probably want nothing to do with them. Dave Bye made mention of the WININET.DLL. You should probably look into it. It provides a high level interface (easy) that would enable a Windows program (VB, Foxpro, etc.) running under IIS to forward HTTP requests to the AS/400 and receive the response. The response may then be passed on to IIS. Both ASP and Window's ISAPI interface provide an easy way to extract the HTTP request (including form variables) from IIS. And, WININET.DLL provides an easy way to forward them to the web server on the AS/400 - be that Stragegi, or the default HTTP server that comes with the box - which BTW can forward to Websphere if you like the idea of a Java Servlet rather than an ILE program responding. The key thing to remember is that the AS/400 web server gets a standard HTTP request by this technique. One point that was not clear to me was whether the AS/400 in Ralph's scenario should respond by returning HTML, or should it return records? I know Stragegi provides an easy, although somewhat restricted means of returning strait HTML. I think either HTML or records are both viable solutions. If the NT guys want to take records and transform them into HTML, that's no big deal. I'm glad objections were raised about the performance and scalability of ODBC, JDBC, RPC, and Database Triggers. Anyway, thanks to all for the great ideas discussed and debated in this thread.

[Guest.Visitor]

web to 400 communicaiton methods

I tried MQSeries for real time messaging within a large corporate environment two or three years ago. MQ bogged down badly. Just because you couldnt get MQ to work effectively that does not mean it doesnt ! I really hate this type of comment I cant get it to work therefore it does not work. There are a number of sites using MQ on the AS/400 in realtime in an effective manner. My experiences have not been the same. Ive seen some bad implementations but by correcting the design and code the performance issues went away. Delta uses MQ for real time transactions, and had to put an AS/400 dedicated to handling MQSeries at each site, this according to articles on their problems in ComputerWorld at the time. I would no more use MQSeries to message while customers are waiting on their web page response than I would use snail mail. Interesting I've not heard of the MQ problems at Delta. I couldnt find any negative reference on the Computerworld web site. Do you have any more info ? Not that it makes a difference since of course every technology has bad implementations and exceptionally good implementations. The mix of a project has not changed over time its still people, process and technology. IMNSHO its the mix that makes the difference not just one aspect. There is a common perception that MQSeries provides such a thing when in fact the manual goes to great lengths to dispel that myth. What is done in your code around MQ API calls can be done in your code around any API calls. Yes you could write your own middleware but is that an effective use of programmers and technical peoples time ? Would not their time be better spent on helping program business solutions. This debate all comes down to worth and need for middleware. Sorry but I never mentioned commit/rollback its about transactional control. MQ is a message transport it is not a distributed transaction processer. It can be included in a distributed transaction environment (opps AS/400 doesnt have one of those !!). Using MQ features such as COMMIT/ROLLBACK, Confirm of Delivery, Expiration Times,Exception Message Processing you can build a close to complete solution. Most of this is not for application programmers so the code is wrappered into a simple interface. Most old (and even some newer) AS/400 solutions are built in a traditional manner with traditional users (internal staff) so the need to for additional transactional control is limited. However when building decoupled systems where the users are the general public....you want to implement in same way ??? Well I dont think this is going anywhere. But I did feel a need to put up a balancing view is case someone else reads this forum looking for feedback of MQ.