Since the beginning of the Web, what you see in your browser window depended on what you clicked on on or entered. It’s all been end-user driven – although the choices of what they can click on are predefined by the Web site designer. This is what they call ‘pull’ technology because the information on the screen is pulled from a Web server. But there are times when it would be useful to have push technology – particularly to mobile phones.
Push technology could keep you informed about the latest football scores and results. It could give you the latest news from international sport events. It could give you stock prices, and highlight rising or plummeting shares. It could tell you when a Web site you follow is updated. There are lots of potential reasons for organizations to want to use push technology.
You may have thought that AJAX (Asynchronous JavaScript and XML) made the Web seem a bit more responsive – but it was still client initiated. Another technique that’s sometimes used is called ‘long-polling’. A client requests information from the server, but if the server does not have anything to send when the poll is received, it holds the request open and waits for response information to become available (instead of sending an empty response). The server then sends an HTTP/S response. Of course, each HTTP request means that headers and cookie data are transferred to the server. If large amount of data are sent, this can lead to increased latency.
Another technique is called streaming, which uses a persistent HTTP connection between the server and client. The browser remains in ‘loading’ mode after the initial page load. Then, from time-to-time, the server sends small bits of JavaScript to update the page. There can be problems with browsers timing out with this technique.
What if it were possible to have a full-duplex communication channel that operates through a single socket over the Web? That’s where HTML5 WebSockets comes in – it makes it possible to have real-time, full-duplex, bidirectional, event-driven Web applications.
How it works is that during their initial handshake, the client and server upgrade from the standard HTTP protocol to the WebSockets protocol. Once established, WebSocket data frames (text and binary frames) can be sent in both directions between the client and the server in full-duplex mode. The data has a two-byte frame. Text frames start with a 0x00 byte, end with a 0xFF byte, and contain UTF-8 data in between. They also use a terminator. Binary frames use a length prefix. There is no polling involved.
Enthusiasts say that WebSockets can make your applications run faster, be more efficient, and more scalable. WebSockets started life as a feature of the HTML5 spec known as TCPConnection. Currently, WebSockets are specified in two places: the Web Sockets API is maintained by HTML5 editor Ian Hickson, while the Web Socket protocol is edited by Ian Fette.
So, if it’s so great, why isn’t it everywhere, why don’t we come across it being used all over the place? Well, it works with Firefox; it works with Chrome; it works with Safari and Opera; and it works with Internet Explorer 10 and above. And that’s pretty much the hold up. Many organizations are still running older version of Explorer – Version 8 in many cases. And figures suggest that just under a quarter of users use Internet Explorer (http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Wikimedia_.28April_2009_to_April_2013.29), so why would any company cut itself off from a quarter of its potential clients?
The very fact that there have been workarounds, shows that there is a business need for push technology. WebSockets provides a solution to the problem of how to implement push technology. The fly-in-ointment at the moment is that a popular browser (from a well-known manufacturer of games consoles) doesn’t support it. As more-and-more companies upgrade to IE10 and above, the likelihood is that we will see much more push technology in use, and WebSockets will be the way to implement it.
Showing posts with label AJAX. Show all posts
Showing posts with label AJAX. Show all posts
Sunday, 1 December 2013
Sunday, 9 December 2012
Putting it all together
I was chatting to Tony Amies, product architect at William Data Systems, about the best way to get information from a mainframe (and about what’s happening on that mainframe) out to someone who has access to a browser. He had a number of nifty techniques that I’d like to share with you.
Assuming you want to get the information from your mainframe to a browser, your first really big decision is do you want to go with two-tier architecture, or do you want to go with three-tier architecture? Tony’s advice was that two-tier was enough.
That leads to the second really important decision to be made, which is where should the processing take place? You’ve got to look at what needs to be done and then make a choice about which platform does that work best on. So, for example, and perhaps quite obviously, if you want to monitor what’s going on with IP, FTP, or EE (Enterprise Extender) on your mainframe, you want that processing to take place on the mainframe. That all seems fairly easy!
But what do you want to do with your results from those different monitors (and indeed any other monitoring software you have running)? Do you want to look like mission control and have a 3270 screen for each monitor that’s running. Now, I remember how impressed visitors used to be when they saw something like that, but if my plan is to get the information to laptop or tablet device running a browser, then I probably need to consolidate the different feeds first. And, again, I want to do that on the mainframe, in the same LPAR (Logical PARtition) that the monitors are running in. It makes sense because much less work has to be done than if I choose to send that data somewhere else for processing.
If you’re familiar with WDS products, you know about their ZEN monitor for their other products. They’re written in Assemble and C and they use a little DLL inside each product that talks to a DLL in ZEN and you can see a nice display of what’s going on – on everything. As a side note, using the DLLs allows the products to talk to each other, so that if the IP monitor spots something, then the IP trace tool can be used to investigate further.
So, using the two-tier architecture, ZEN is logically split into two parts. One part is mainframe friendly and one part is Web friendly. Associated with the Web-friendly part of ZEN are the necessary JavaScript libraries and JQuery libraries, and the usual HTML bits. If you’ve not come across JQuery before, it’s like a lot of clever JavaScript that’s been already written that you can use to make your Web site look very modern. Lots of sites use the jQuery lightBox plugin to show photos.
There’s always a problem with busy Web pages in that lots of information has to come from the server to the browser, resulting in lots of network traffic – and if you’re monitoring your mainframe’s network from a browser there can be even more. So the first technique they’ve used is AJAX (Asynchronous JavaScript and XML), which means that only the parts of the Web page that have changed are sent, the rest of the page stays the same. They also use JSON (JavaScript Object Notation) as a lightweight data-interchange format.
But there’s always an issue with any User Interface and that’s how to separate the actual user interface itself from the business logic behind it. In technical terms, these are known as the view model and the data model. To make this work as effectively as possible, they’re using MVVM (Model View ViewModel), which is a framework or architectural pattern coming originally from Microsoft, but now extended to include JavaScript MVVM. You can get a clearer idea of the sorts of things they’ve done – and perhaps the sorts of things you could do from knockoutjs.com. The site describes itself as “simplifying dynamic javaScript UIs by applying the Model-View-ViewModel (MVVM) pattern”. The WDS developers also familiarized themselves with prototypejs.org, a site describing itself as “a foundation for ambitious web user interfaces”. They go on to say: “Prototype takes the complexity out of client-side web programming”.
For WDS, basically an object is requested from the browser by the user. This goes up to ZEN. Using JSON, a data object comes down and binds with the layout defined in the MVVM skeleton. As a user, you see dynamically updated information in your browser. If one new value affects other values, those other values are automatically update appropriately.
I’m not endorsing WDS’s products, I’m saying that they have very effectively made use of the very latest technology at the browser end to make their product work very efficiently. I’m suggesting that the two-tier architecture with really clever stuff on the browser side is definitely worth taking a look at.
Assuming you want to get the information from your mainframe to a browser, your first really big decision is do you want to go with two-tier architecture, or do you want to go with three-tier architecture? Tony’s advice was that two-tier was enough.
That leads to the second really important decision to be made, which is where should the processing take place? You’ve got to look at what needs to be done and then make a choice about which platform does that work best on. So, for example, and perhaps quite obviously, if you want to monitor what’s going on with IP, FTP, or EE (Enterprise Extender) on your mainframe, you want that processing to take place on the mainframe. That all seems fairly easy!
But what do you want to do with your results from those different monitors (and indeed any other monitoring software you have running)? Do you want to look like mission control and have a 3270 screen for each monitor that’s running. Now, I remember how impressed visitors used to be when they saw something like that, but if my plan is to get the information to laptop or tablet device running a browser, then I probably need to consolidate the different feeds first. And, again, I want to do that on the mainframe, in the same LPAR (Logical PARtition) that the monitors are running in. It makes sense because much less work has to be done than if I choose to send that data somewhere else for processing.
If you’re familiar with WDS products, you know about their ZEN monitor for their other products. They’re written in Assemble and C and they use a little DLL inside each product that talks to a DLL in ZEN and you can see a nice display of what’s going on – on everything. As a side note, using the DLLs allows the products to talk to each other, so that if the IP monitor spots something, then the IP trace tool can be used to investigate further.
So, using the two-tier architecture, ZEN is logically split into two parts. One part is mainframe friendly and one part is Web friendly. Associated with the Web-friendly part of ZEN are the necessary JavaScript libraries and JQuery libraries, and the usual HTML bits. If you’ve not come across JQuery before, it’s like a lot of clever JavaScript that’s been already written that you can use to make your Web site look very modern. Lots of sites use the jQuery lightBox plugin to show photos.
There’s always a problem with busy Web pages in that lots of information has to come from the server to the browser, resulting in lots of network traffic – and if you’re monitoring your mainframe’s network from a browser there can be even more. So the first technique they’ve used is AJAX (Asynchronous JavaScript and XML), which means that only the parts of the Web page that have changed are sent, the rest of the page stays the same. They also use JSON (JavaScript Object Notation) as a lightweight data-interchange format.
But there’s always an issue with any User Interface and that’s how to separate the actual user interface itself from the business logic behind it. In technical terms, these are known as the view model and the data model. To make this work as effectively as possible, they’re using MVVM (Model View ViewModel), which is a framework or architectural pattern coming originally from Microsoft, but now extended to include JavaScript MVVM. You can get a clearer idea of the sorts of things they’ve done – and perhaps the sorts of things you could do from knockoutjs.com. The site describes itself as “simplifying dynamic javaScript UIs by applying the Model-View-ViewModel (MVVM) pattern”. The WDS developers also familiarized themselves with prototypejs.org, a site describing itself as “a foundation for ambitious web user interfaces”. They go on to say: “Prototype takes the complexity out of client-side web programming”.
For WDS, basically an object is requested from the browser by the user. This goes up to ZEN. Using JSON, a data object comes down and binds with the layout defined in the MVVM skeleton. As a user, you see dynamically updated information in your browser. If one new value affects other values, those other values are automatically update appropriately.
I’m not endorsing WDS’s products, I’m saying that they have very effectively made use of the very latest technology at the browser end to make their product work very efficiently. I’m suggesting that the two-tier architecture with really clever stuff on the browser side is definitely worth taking a look at.
Saturday, 19 May 2012
Making it look nice for CICS users
Let’s look at an archetypal MVS site. Kenny wrote most of the original Assembler and quite a bit of the COBOL code that drove the business all those years ago. He was a big man and a real hippie. He even came to work in his sandals and decorated his office with album covers. He thought that writing comments in code was just a waste of time. Doug, who took over from Kenny was an absolute troglodyte. Whereas Kenny was fun to go for a drink with – and boy could he drink – Doug was forever under the floor connecting high speed back-up technology that no-one else really understood. He was great because he’d help everyone with code problems, but he seldom turned up to meetings or understood the concept of budgets. But everything worked like a dream and the company made money.
Nowadays we’ve got Ross heading up software on our z/OS CICS system. He does attend meetings – lots of them. He’s on the committee at a local user group and he’s given presentations at SHARE. He’s even got a wife and children! The problem is that much of the code that Ross looks after is quite old and doesn’t have many comments. There was an effort in 1999 to document everything, but it’s now out-of-date since the SOA (Services-Oriented Architecture) project.
The trouble at many sites is that their Ross is kept very busy at the mainframe end of his CICS system and thinks that the bit of AJAX on the Web browser front-end is enough to keep the end users happy. The truth is, end users are never happy! So what if someone at a conference told Ross there was an easy way (well, perhaps not easy, but fairly straightforward certainly) to make the end user experience of his CICS applications look like it was written in 2012 and not 1912!?!? Do you think Ross would be interested?
Before we look at what this amazing solution might be, let’s briefly look at Web design. Back in 1999, a Web site was pretty much made up of static pages. Someone wrote the pages in HTML and, over time, people updated the information on those pages. Then we had PHP and MySQL. This provided a database that users could update as necessary, and the PHP pages pulled out the latest information. They still looked like static pages, but they were easier to update. Then, we had JavaScript that gave us programming capabilities and all the flexibility that goes with that. Then we had JQuery, which was JavaScript with all the hard work already done for us. You’ve seen Web sites with JQuery-like effects – the ability to click on a thumbnail image and see it large in the middle of the page while much of the rest of the screen is covered with a semi-transparent layer. An example would be clicking on a photo in Facebook.
So let’s tell Ross about the Dojo Toolkit from the Dojo Foundation. Now at Version 1.7, the Web site at http://dojotoolkit.org/ says: “Dojo saves you time and scales with your development process, using web standards as its platform. It’s the toolkit experienced developers turn to for building high quality desktop and mobile web applications.” Now, suppose there was some way to plug that into CICS. So while Ross was looking after the CICS applications, Dojo was making sure that the end users had a good experience.
The Virtual CICS user group (www.fundi.com/virtualcics/) heard from Stephen Mitchell, Managing Director of Matter of Fact Software Limited, earlier this month. He gave a talk entitled: “Utilizing the Dojo Toolkit for Web browser-driven applications from CICS”, which really got to grips with how CICS and the Dojo Toolkit could be integrated. The base functionality of the Dojo Toolkit is made available to a Web page by including a link to dojo.js. This includes plenty of features like CSS-based queries, event handling, animations, AJAX, class-based programming, and a package system that makes getting access to the rest of Dojo very easy.
There are additional stable (but optional) components for advanced animations, I/O, data, drag-and-drop, and much more with Dojo Core. Dijit is Dojo’s theme-able, accessible, easy-to-customize UI library. Dijit requires Dojo Base and various Dojo Core modules to use. It allows for the creation of widgets. For the more adventurous, there’s DojoX, which contains a number of sub-projects based on the Dojo Base. Each project has a varying states of maturity – from very stable and robust to alpha.
Stephen’s company recognized a need to control the Dojo Toolkit that was being used by their PlexSpy application status monitor product. And they decided that if it was an issue for them, it was most likely an issue for others. So they created a generic server solution that could be used by anyone with CICS on z/OS. As a consequence, the Dojo Toolkit has been taken into the mainframe environment and is served from CICS out of PDSs. This brings the strengths of the mainframe to sites using the Dojo Toolkit – providing the control over it that those sites needed.
Ross can now put his feet up at home with his family knowing that his end users are happy with their working environment. And the code Kenny and Doug wrote is still doing its job for another generation.
Nowadays we’ve got Ross heading up software on our z/OS CICS system. He does attend meetings – lots of them. He’s on the committee at a local user group and he’s given presentations at SHARE. He’s even got a wife and children! The problem is that much of the code that Ross looks after is quite old and doesn’t have many comments. There was an effort in 1999 to document everything, but it’s now out-of-date since the SOA (Services-Oriented Architecture) project.
The trouble at many sites is that their Ross is kept very busy at the mainframe end of his CICS system and thinks that the bit of AJAX on the Web browser front-end is enough to keep the end users happy. The truth is, end users are never happy! So what if someone at a conference told Ross there was an easy way (well, perhaps not easy, but fairly straightforward certainly) to make the end user experience of his CICS applications look like it was written in 2012 and not 1912!?!? Do you think Ross would be interested?
Before we look at what this amazing solution might be, let’s briefly look at Web design. Back in 1999, a Web site was pretty much made up of static pages. Someone wrote the pages in HTML and, over time, people updated the information on those pages. Then we had PHP and MySQL. This provided a database that users could update as necessary, and the PHP pages pulled out the latest information. They still looked like static pages, but they were easier to update. Then, we had JavaScript that gave us programming capabilities and all the flexibility that goes with that. Then we had JQuery, which was JavaScript with all the hard work already done for us. You’ve seen Web sites with JQuery-like effects – the ability to click on a thumbnail image and see it large in the middle of the page while much of the rest of the screen is covered with a semi-transparent layer. An example would be clicking on a photo in Facebook.
So let’s tell Ross about the Dojo Toolkit from the Dojo Foundation. Now at Version 1.7, the Web site at http://dojotoolkit.org/ says: “Dojo saves you time and scales with your development process, using web standards as its platform. It’s the toolkit experienced developers turn to for building high quality desktop and mobile web applications.” Now, suppose there was some way to plug that into CICS. So while Ross was looking after the CICS applications, Dojo was making sure that the end users had a good experience.
The Virtual CICS user group (www.fundi.com/virtualcics/) heard from Stephen Mitchell, Managing Director of Matter of Fact Software Limited, earlier this month. He gave a talk entitled: “Utilizing the Dojo Toolkit for Web browser-driven applications from CICS”, which really got to grips with how CICS and the Dojo Toolkit could be integrated. The base functionality of the Dojo Toolkit is made available to a Web page by including a link to dojo.js. This includes plenty of features like CSS-based queries, event handling, animations, AJAX, class-based programming, and a package system that makes getting access to the rest of Dojo very easy.
There are additional stable (but optional) components for advanced animations, I/O, data, drag-and-drop, and much more with Dojo Core. Dijit is Dojo’s theme-able, accessible, easy-to-customize UI library. Dijit requires Dojo Base and various Dojo Core modules to use. It allows for the creation of widgets. For the more adventurous, there’s DojoX, which contains a number of sub-projects based on the Dojo Base. Each project has a varying states of maturity – from very stable and robust to alpha.
Stephen’s company recognized a need to control the Dojo Toolkit that was being used by their PlexSpy application status monitor product. And they decided that if it was an issue for them, it was most likely an issue for others. So they created a generic server solution that could be used by anyone with CICS on z/OS. As a consequence, the Dojo Toolkit has been taken into the mainframe environment and is served from CICS out of PDSs. This brings the strengths of the mainframe to sites using the Dojo Toolkit – providing the control over it that those sites needed.
Ross can now put his feet up at home with his family knowing that his end users are happy with their working environment. And the code Kenny and Doug wrote is still doing its job for another generation.
Subscribe to:
Posts (Atom)