Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Strike It Rich! Reversing the Trend of Web Clients

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

  • Strike It Rich! Reversing the Trend of Web Clients

    IBM has one thing right. The user interface needed to be grounded in the OS, not floating above it as in Swing. So they did that with Eclipse and their OS based GUI interface, and donated their vision to open source, and that was a good thing. Now, what they have wrong. A user interface of the future won't be controlled by Websphere. It will be more desktop portal centric with sockets and other TCP/IP communications like HTTP to a variety of sources. The browser will be just another window in the portal suitable for what it was designed for, content browsing and hyperlinking. So what does this mean for us? I think 5250 emulation written in Eclipse with advanced GUI features that Dave and others have posted here should be the standard AS/400 interface that can be written to from within green screen development. That is, Websphere is not required. This is heresy to IBM and will never be allowed, but it continues to show that IBM sacrificed the AS/400 at the Websphere alter long ago. An AS/400 should be able to run with Apache open source tools with Websphere not required as every other server out there does. Instead, we are controlled by IBM because we are captive, and they can. rd

  • #2
    Strike It Rich! Reversing the Trend of Web Clients

    You don't need WebSphere! Write your business logic as servers. Write your UI in whatever flavor you want. I like simple JSP Model II, which means I can run on Tomcat as easily as I can WebSphere. If you want thick client, use VB or Eclipse's RCP. It's simply stupid to wait for IBM to create a UI for you when there are already so many out there to choose from. Instead, you need to be concentrating on how to write servers. I've been saying this since the 80's, and I watch as it goes through various name changes (not unlike our beloved iSeries). Client/server, message-based processing, remote procedure calls, CORBA, COM/DCOM, and now the ubiquitous SOA -- it's all the same thing! Send a message to a server and get a response back. If you write your business logic THAT way, you can have WHATEVER INTERFACE YOU WANT! Joe

    Comment


    • #3
      Strike It Rich! Reversing the Trend of Web Clients

      An interface has to come with the AS/400 that is the recognizable business processing interface that is currently 5250 green screen. The interface has to take the 5250 data stream as a subset but should be enhanced with an XML keyword superset that is programmably extensible. Web pages and thicker clients than the default client are special cases for customers and business partners or power users. In my opinion the default interface, shipping with the AS/400 and recognizable as the AS/400 interface and something that AS/400 programmers and shops have a clue is the new standard GUI interface, would be able to pop up the browser as a window and render HTML streams and provide a default rendering of the 5250 based stream if it receives the extended keyword stream. If we don't have that, no one much cares what we write as a server. You have to have someone who wants to be served, and that requires a recognizable AS/400 interface again. IBM was insisting it be web pages served by Websphere, and that as I've said over the years isn't going to cut it. I saw where IBM is extending their RoadMap or whatever, Joe. I hope your product is included as a sanctioned option! rd

      Comment


      • #4
        Strike It Rich! Reversing the Trend of Web Clients

        An interface has to come with the AS/400 that is the recognizable business processing interface that is currently 5250 green screen. The interface has to take the 5250 data stream as a subset but should be enhanced with an XML keyword superset that is programmably extensible. I disagree with this premise. The 5250 interface has stood the test of time as the perfect character-based block mode interface. Trying to shoehorn graphics capabilities onto it is lipstick on the pig. If you want to do that, my product is the better way to go. But that's not what I'm talking about. What is needed is a message-based interface that is UI INDEPENDENT. The UI layer, whether it's a 5250 or a browser or a thick client or a Dick Tracy wristwatch, should be completely separated from the business logic. When you design a server program, you should design it from the message, not from a UI standpoint. If I were to design the ultimate IDE from scratch, it would have three very separate pieces. There would be a server designer and a UI designer. But the primary piece would be a message designer which should work directly from a UML diagram. You define request and response messages, including meta-messages which combine one or more lower-level messages. The server designer is simply used to fulfill those requests. It has no UI requirements and is completely UI independent. I'd probably have a few templates that I would use to generate standard servers in the language of my choice. The UI piece, on the other hand, would be solely for designing a UI, whether it be browser, thick client, green screen, whatever. Whenever the UI needed to communicate with the database, it would do it via a message to a server. There are a few other pieces. You might need a configuration module that would identify the appropriate communication protocol, and you might also want an application control piece that handled the basic program flow (depending on whether your application was purely client/server or was more of the traditional server/client model). Design this interface, and make sure one of your server definition modules supports RPG. Package it with a low-end iSeries, and you've got the killer development environment: you can run a green screen interface, a browser interface with either Tomcat or WebSphere, or a thick client interface in either VB or RCP. Sure, you have to design the messages and the templates and eventually write code for the servers. You need to learn how to design your UI. But with that flexibility, you can write ANYTHING. But no, what everybody keeps asking for is a push-button development environment so they don't actually have to program. They want to drag database fields onto a grid and have all the work done by somebody else. They don't want to innovate, they want to replicate. And that's just stupid. Joe

        Comment


        • #5
          Strike It Rich! Reversing the Trend of Web Clients

          I hope others can comment here. Maybe they see something I don't. I just see transaction buffers going in and out, legacy wise through EXFMT but still just a transaction buffer. I see the messaging and user interface as varying, should be independent of the app. A web page, 5250 screen, new AS/400 Eclipse Java interface, or even VB should all be able to handle the transaction buffers from the app with overriding of EXFMT formatting the transaction buffer appropriately based on what the AS/400 determined about the connection at signon including messaging protocol used through what kind of virtual server, etc. I don't see any particular difference based on interface being GUI. More control keywords, fonts, colors, maybe a link for downloading a graphic following a keyword with placement info, also an extra type attribute for text as to what type of control in which to display. All this I see done in a standard AS/400 DDS development, in other words, totally backward compatible to 5250 green screen. Current green screens would get 5250 binary, new interface would get XML keyword equivalent with extra control attributes. I see the 5250 with full mouse, windowing, and menuing as baseline but Eclipse Java new AS/400 interface with additional GUI capabilities such as graphics, fonts, colors, interoperability with desktop apps, perhaps builtin Gecko HTML rendering, etc. The extensible program defined keywords would clue a rich client with what class to use to process following text but a default component would be used in a dumber client. It's just an extension of what we already do, but made interface independent at the EXFMT level. The only reason IBM doesn't do it is because it wouldn't use Websphere and that is apparently verboten. Even when I wrote an interface independent server for JOBS/400, a server for web pages but which I tested with green screens, it wasn't all that complicated. I just read and wrote dataq's, and who read and wrote back the dataq's and what they did with the data was transparent to me. I see the 5250 transaction buffer as being that dataq buffer. There shouldn't be any reason why our programming can't be rendered to several different interface types simultaneously with appropriate formatting by OS/400. I know IBM can do it, they just won't unless they can figure out a way to require Websphere. Plus the IBM marketing hooeys have designated the AS/400 as some kind of SAN or something for lightweights as if they never heard of thousands of huge companies that run their business on OS/400 and RPG. But again, I hope others comment because maybe they see more in your tiered development approach than I do. rd

          Comment


          • #6
            Strike It Rich! Reversing the Trend of Web Clients

            But again, I hope others comment because maybe they see more in your tiered development approach than I do. I advocate a tiered architecture where you can write the UI independently of the back end, with either side using whatever language skills you have most prevalent. You want IBM to extend a 30-year-old architecture to provide a subset of GUI capablities within the old 5250 paradigm. Joe P.S. The latter is already done, by the way. My product does it, and so does WebFacing. The extended keywords are comments in the DDS.

            Comment


            • #7
              Strike It Rich! Reversing the Trend of Web Clients

              Joe Pluta wrote: The 5250 interface has stood the test of time as the perfect character-based block mode interface. I will disagree with this statement from the aspect that the within the confines of 5250-land there is a great deal of room for improvement. I am saying this regarding a character based interface. As far as 5250 graphics are concerned, it was proven over twenty years ago that the 5250 data stream could handle graphics. There was just no follow through, or further development. I suppose that no one at the time thought a graphical interface was important to computing. Dave

              Comment


              • #8
                Strike It Rich! Reversing the Trend of Web Clients

                I will disagree with this statement from the aspect that the within the confines of 5250-land there is a great deal of room for improvement. There's no room for improvement that makes any business sense. By business sense, I mean something that will sell to more people than you and Ralph. I suppose that no one at the time thought a graphical interface was important to computing. If people had bought it, IBM would have sold it. The point is that nobody wanted a graphical 5250 interface, and whether it might make sense now is moot because there are already better, more established graphical interfaces. Joe

                Comment


                • #9
                  Strike It Rich! Reversing the Trend of Web Clients

                  If people had bought it, IBM would have sold it. If memory serves, the price for a dumb terminal was $6,000. There's no room for improvement that makes any business sense. By business sense, I mean something that will sell to more people than you and Ralph. Stick to the issue Joe. If you disagree with a statement say why. Personal rancor will get you into deep smeg, and quite frankly invective is beneath you. Dave

                  Comment


                  • #10
                    Strike It Rich! Reversing the Trend of Web Clients

                    > I hope others can comment here. Maybe they see something I don't. Throwing down the gaultlet, eh Ralph? :-) As you might imagine, I have some thoughts on the matter, and you've provided the perfect introduction: > I just see transaction buffers going in and out, > legacy wise through EXFMT but still just a transaction buffer. The problem is subtle, but it's there if you dig it out. The transaction buffer is an analog for the UI. That is, we have designed the UI and the program to operate in lock step with each other. The buffer exactly matches the DDS, and the RPG program is very intimate with the specifics of that buffer. Change the UI (DDS panel) even a little bit, and the program changes too. What the rest of the webby world is doing dissociates the UI panels from the program logic, in a way that we have never done with RPG and DDS. DDS is a unit-record interface: read a card, write a card. > I see the messaging and user interface as varying, > should be independent of the app. A web page, > 5250 screen, new AS/400 Eclipse Java interface, > or even VB should all be able to handle the > transaction buffers from the app with overriding > of EXFMT formatting the transaction buffer > appropriately based on what the AS/400 determined > about the connection at signon including messaging > protocol used through what kind of virtual server, etc. And they can do exactly that, if you intend to tie yet another generation of panels to the logic in the program. I can hear you thinking 'What IS he going on about? How can you possibly have a display panel that isn't tied to the program logic?' One way is the Java Bean. The HTML asks for a field at will by embedding a bean in say, a Struts page. The panel has no tie to the logic other than saying 'get me the account name.' The program doesn't pass out a pre-formatted buffer; it returns an account name. Or address, or... > It's just an extension of what we already do, but made > interface independent at the EXFMT level. The only > reason IBM doesn't do it is because it wouldn't use > Websphere and that is apparently verboten. IBM already DOES do this exact thing, and they call it WebFacing. We think of DDS as a mere formatter; to make the punches on the card more readily readable. But the output is still a card, with the account name going right here before the address and after the account number. Very much tied to the logic of the program, where you chain to this file to get the address, that file for the credit rating, another file to get the product history and then bundle it all together to write a card. Changing the way the card interpreter runs is not the answer unless you need a grey screen. That is, a 5250-looking display that's browser grey instead of 5251 green. Beans is only one answer; you can certainly use data queues to serve up individual fields if you want to, or even entire buffers. It's a question of just how much freedom to give the UI guy. In our past (and I mean you and me and others who've been doing this for a decade or more) the UI was simple to do because it's just a fancy looking card, but modern apps want real GUI stuff; drag & drop, clickable dropdown thingies, user-adjustable colours and fonts - you name it. They want to re-arrange the screen by telling an intern to fiddle with the page and not have to pay a programmer big bucks. I hope I managed to get across what I'm thinking; that fancying up DDS isn't enough for what the end user expects today. --buck

                    Comment


                    • #11
                      Strike It Rich! Reversing the Trend of Web Clients

                      A good discussion, but I am puzzled. Webfacing is mentioned. I said formatted at the EXFMT level to several different types of interfaces simultaneously based on connection. That at a minimum is 5250 binary, 5250 XML superset, and HTML. It would be done in EXFMT to HTML if the cnnection is HTTP. There are of course a zillion commercial options, which is the whole problem. You have to have a standard interface to write to like we have now with 5250 green screen for the AS/400 to continue to exist. Otherwise the AS/400 and whatever IBM calls it in the future will die when the last green screen dies. I disagree that the full 5250 capability as baseline is insufficient or even marginal. In fact, the full 5250 with mouse, limited colors, windowing, and menuing is pretty much feature complete for an interface. It's just a matter of whether the messaging is formatted in 5250 binary, 5250 XML superset, HTML, or something else. Typical reaction is why not HTML then? Reason is all the things you listed buck. The new interface should be OS grounded Eclipse Java 5250 emulator with all the features you mentioned. They are all independent of the XML keyworded transaction buffer. If someone drags the fields around, the keywords still map to the components. If it's permanent, the new layout would have to be stored with the users profile, but that kind of flexibility is what I'm talking about with a new interface. One thing I mention everytime but which probably doesn't get understood is interoperability with desktop apps or to other systems through sockets. This is critical and the future. Browser HTML is an island from the desktop. So is Java Swing without a JNI infrastructure to write to. The new interface must be drag and drop interoperable with other desktop apps, and an OS grounded UI is critical to that. IBM provided that with Eclipse Java and the new interface would be open source written in that. But all that is irrelevant unless IBM does the formatting in EXFMT. 5250 development has all the necessities of transaction processing. Everything we do can continue to be displayed in 5250 green screen as well as HTML or the new Java interface. It's just a matter of additional user functionality that they can do amidst the transaction processing, in parallel with our transaction logic. And we must not forget, it is that lockstep transaction logic which makes our programming so solid. It should not go away, the user should just have more capability in interacting with other apps to be as productive as they can be on the desktop. The new interface should also include a spreadsheet (IBM had Lotus rewritten in Java modules long ago) that works directly against AS/400 data. There should be no copying of data and working offline. I am not posting against anyone else's solutions. I am saying this is a necessary evolutionary step that IBM must take to keep the AS/400 viable, a standard recognizable AS/400 interface that ships with the system and everyone knows they can write to using current development methodolgy. I doubt that IBM prefers that the AS/400 dies, but they are ensuring its demise with their lowest common denominator cross platform Websphere strategy. They may even be so silly as to not want to cannabalize Client/Access sales, who knows, but the AS/400 requires what I describe for companies to continue to write software for its unique capabilities. rd

                      Comment


                      • #12
                        Strike It Rich! Reversing the Trend of Web Clients

                        Dave, nothing personal about it at all. It's my opinion that you're asking for something that nobody else wants except you and Ralph. Nothing rancorous about it. If you can find people who agree with you, then I'll happily admit I'm wrong, but the reality is that the vast majority of people who want a graphical interface will use a real GUI rather than an extension of 5250. There is no market for a graphical 5250 data stream. Joe

                        Comment


                        • #13
                          Strike It Rich! Reversing the Trend of Web Clients

                          Joe Pluta wrote: the vast majority of people who want a graphical interface will use a real GUI rather than an extension of 5250. This is true, and I will agree with it. How about this now: The vast majority of AS400 programmers if given enhancements to 5250 capabilities will use them. Dave

                          Comment


                          • #14
                            Strike It Rich! Reversing the Trend of Web Clients

                            I don't think so. I mean, we've had graphics forever (remember BGU?) and nobody jumped on THAT paricular bandwagon. And while we've had the "GUI lite" features of DDS for some time now, they're not exactly high adoption techniques. Heck, there aren't that many people using the help text capabilities, and those are really well done, in my opinion. No, I think the most green screen users want is consistent use of colors and command keys, without a whole lot of fluff. The ones who want GUI come frmo the Window world, and to them some half-implemented menus and radio buttons do not a GUI make. But hey, we can agree to disagree on this one. Let's see if anyone else weighs in! Joe

                            Comment


                            • #15
                              Strike It Rich! Reversing the Trend of Web Clients

                              Hi Dave, > How about this now: The vast majority > of AS400 programmers if given > enhancements to 5250 capabilities > will use them. I don't know 5 iSeries programmers who use existing graphical functionality like MOUBTN. I'm afraid that's more typical than not. --buck

                              Comment

                              Working...
                              X