^M00:00:13 >> Having completed our discussion of the lower levels of healthcare infrastructure components, such as the servers and desktops, we now start our lecture 3, where we now look at software-based components, and various models of computing, data processing, and applications that are in use. Our learning objectives in this section are to first introduce concepts and models of client-server computing, and we take examples from Internet services, which is where most client-server examples are found. We then take a specific Internet service, the Worldwide Web, and we make sure that we understand how it works, and why it has been so successful in implementing a set of features that have ended up being so useful. And then we look at how applications and data processing models are used in writing applications, so that when we go back to our healthcare applications, we can understand the software components that are part of it, and their implications on performance reliability, and other such quality attributes. So in client-server computing, recall that we have seven layers of networking that we talked about, of which the seventh layer happened to be what network people call application layer. Turns out that there is no single application layer. There are many, many applications in the application layer, and those can actually be layered as well. So the application layer in client-server computing world we would say comprises of many services. You could call them applications -- users may call them applications, and those applications are collections of programs and libraries. These network applications have two components -- a client side program, which we generally would call client, and a server side program, which we typically call a server. So in the picture that you see here, the clients are in blue, and there's a file server that's serving up files. So there's a program on the file server end serving the files, and the client side desktops would have a client component. The server running on the server computer typically runs forever, waiting for a request to come in. And its job is to provide service to a resource that it's managing for which the request comes in. So now example of the file server -- the service that -- the resource that's being managed by the file server are the set of files that are stored on that server. And clients can make various kinds of requests. So the fourth point being clients typically started by user on desktop computer will make a request to the server by sending a request message. And in an example, you see the request messages coming in, one client says get me this file, and a parameter of that would be the name of the file. Client 2 says I would like to rename a file, here is the previous name, here is the new name. And client 3 would like to remove a specific file, and provides a name. File server has a server program that is waiting on the requests coming in, and then it acts upon them. ^M00:04:25 [ Silence ] ^M00:04:29 >> The server receives the request, or set of requests, acts upon them, and returns a reply message to the client. And in this particular way, several messages may be exchanged. They may be different types of requests, and different types of reply messages. And collectively, these message types -- the sequences of message and a reply, and a message and a reply, as with a flow of data across these messages together implement a protocol -- a service protocol, in this particular case the file server service. So in our example, client 1 had requested get me a file, or get me the contents of a file, with a name, file server is responding back, here are the file contents. Client 2 was trying to rename a file, client server comes back with an error message that it cannot find the file that's to be renamed. And client 3, which was removing message, file server comes back -- comes back with a positive acknowledgement, saying the file has been removed. ^M00:05:44 [ Silence ] ^M00:05:49 >> Examples of client-server computing in Internet world are plenty -- are many. Because every service that's implemented on the Internet is essentially a client-server program. The first example we saw earlier was the domain name service, in which there are servers running domain name server programs. And clients send name and expect an IP address back, or they can also send an IP address and get a name back. And there are some other details -- other items that can be queried. There are other examples of naming services that are quite popular on the Internet. One of them is called lightweight [phonetic] directory access protocol, or LDAP. You can use client-server-based authentication, like you can have a client submit a user ID and a password to check against what the directory has stored, and directory can come back and say yes or no. The purpose of the directory, however, is more like a phone directory. One of the things it can model very well are people, and various attributes associated with people, such as the phone numbers, email addresses, their privileges, their names, their titles, affiliations, and so on, so forth. The -- the way the service would be implemented that a client may come and specify -- search for a particular person, or having found the person, provide specific attribute values, such as the phone numbers or email addresses. Next examples are file and print services. Network File Service -- NFS -- is a very popular one. Windows implements Common Internet File Service -- CIFS, and Apple actually uses something called AFB, all of them essentially do as our example shows -- provide files to the clients. Similarly on the printing end of things there's an IPP -- Internet Printing Protocol, or LPR LPD, whereby a printer is sent a job, and the service request is to print it with a positive acknowledgement. Remote access, or access to systems, those are the applications or client-server programs that are terminal and file transfer services. The oldest -- oldest service is Telnet, with which a -- a client program can become a terminal off a server computer. And that's Telnet. FTP is for file transfer, secure FTP is to do file transfer with encryption of the contents. Secure shell and secure copy -- SSH, SCP -- these are examples of secure remote access and secure copying of files again. Email that we all use every day are examples of client-server programs. When one email server forwards email to another email server, they use a protocol called Simple Mail Transfer Protocol -- SMTP. And if that particular protocol uses encrypted payload, or encrypted data, then it's called SMTPS. When we are on our Outlook client perhaps, or Thunderbird client, or Eudora client, and access a particular mail server, we may be using a protocol called Internet mail access protocol -- IMAP, and if it's encrypted it's called IMAPS. And these are examples of protocols used in email. To see email, you use IMAP, to exchange email between two mail servers, SMTP is used. And then of course, the most popular one, the web -- the Worldwide Web, then, you know, the protocol is hypertext transfer protocol -- HTTP, and if it's encrypted it's called HTTPS. ^M00:10:23 >> One additional point to note here is that each service, if you recall, may have a specific port associated with it. It's not that you cannot run server on different port numbers, you can. However, a set of ports are preassigned to some of the protocols, and that's where they would be usually likely to be found. So when we do Telnet, the port number -- it uses port 23, FTP is port 21, secure shell is port 22, SMTP is port 25. You can sort of see they started assigning these protocol numbers from our 21, and these are all the oldest protocols that are in the Internet. HTTP happens to be 80 -- 8 - 0. So we go in little deeper into understanding what Worldwide Web is about. Now Worldwide Web didn't happen one fine morning. It actually came out of many other client-server programs already in place being used in different contexts throughout the Internet. And this was the Internet before the Worldwide Web days. Worldwide Web came out around '94 -- '93, '94, when NCSA Mosaic first released the browser. Before that it was designed in Switzerland and [inaudible] by Tim Berners-Lee. But its popularity started with NCSA Mosaic program -- program. But prior to that, applications such as Gopher from University of Michigan ways [phonetic] as an application or a client-server program which was about library services, and finding -- finding information essentially. Simple general markup language -- SGML, Apple [inaudible] was showing a lot of hyperlink-like activity. Clicked on a particular part of the document, it takes you to another part of the document, or another document all together, that would be hyperlinking. MIME [phonetic] has a protocol of a standard has been around with emails. Since emails typically send text messages from one end to the other end of the world, MIME is a way to encode non-textual data, such as images, such as programs which are [inaudible], and converts them into -- into printable text as -- as an encoding, and then has an attachment method to -- to an ordinary email, and then sends it over. Now that's a way of packaging that Worldwide Web has used. Public and private key cryptography, which gave us the security components, and so on so forth. So let's just look at the features of Worldwide Web, and see how each of those features provide a quality attribute that makes it so attractive that Worldwide Web is so popular. So the first thing is links. Links, or URL which is universal resource locator, basically provides a feature so that one can leverage independent publishers. For the first time with Worldwide Web, you didn't need a dedicated publisher to publish information, you yourself could publish information. And then you could link what others have published to what you are writing, using a simple link which -- which is essentially a URL to another web page. So by doing that, the functionality and the usefulness of that system of looking at one place but having a ready reference throughout the Internet was -- was obviously a very attractive, and successful attribute. The next thing Worldwide Web did was it had multimedia. It not only presented text, but it has simple ways of producing graphics, adding audio, video, creating forms. And instead of just one-dimensional text display, which is the way Ways was -- W - A - Y - S was, by -- by adding multimedia capabilities, and -- and part of the multimedia is that depending upon what the media was, appropriate application could be started at the browser level to -- to act upon that media, also added tremendously to the functionality of the Worldwide Web. The next thing was platform independent rendition. For the first time ever you could write a program -- a browser, once for Windows platform, once for Unix platform, and once for Macintosh platform. But as the data was being sent from the server to the browser -- it's the same data that was being sent to the browsers -- browsers knew how to interpret it and show it on their respective desktop platform. So what comes from the server is platform independent, but what -- when it gets to the platform, the local program -- the client program -- the browser knows what to do with it in that platform. And not only it was simple from the server end of things, but it was highly flexible at the client end of things. Because if you wanted, and you did not know how to deal with a particular multimedia file, you could give it to another program, which would open it up. Then the data that was being sent was used using markup languages, and the HTML hypertext markup language, and current data XML extended markup language, they all derive from what we have written above, which is simple graphical markup language -- SGML. And the beauty of markup languages is A, it's in ASCII, or -- or -- or Unicode if you will, it's not a binary data. You can actually take a look at it and make sense out of it. In fact there is a browser which sort of takes away all the mark -- markers -- all the tags, and just shows you in text what -- what that page is all about. And it's a very simple way to add bold, underline, tabular, tables, paragraph breaks, etcetera. And -- and -- and those [inaudible] of the simple graphics markup language by simplifying it to hypertext markup language. Then as a programming environment, Worldwide Web encouraged dynamic computing. We'll look at this more detail when we look at common gateway interface, or CGI, which is at the server end. But on the client end you could add something called JavaScript, and you can create applets, servlets. ^M00:17:39 >> And by that, what you could do is you could start do computational, take input from the user, send it to the back end, back end could do something intelligent with it, because it has the CGI to start other programs. By doing this one we're then able to not only just see static pages, but now could actually interact with the back end as if they're entering data in the transactional system. Then important security concerns were addressed by using public and private key cryptography in a -- in very clever ways using secure socket layer, two or three things got done. A, traffic could be encrypted, and B, both client and the server could, if required, authenticate to each other, and therefore provide a modicum -- or -- or not modicum, a -- a significant component of trust between the server and the client. And entire rise of companies like Verisign, and GeoTrust, who are the certificate programs -- certificate companies comes directly from -- from security being important on the Worldwide Web to do commerce. And only when the security was addressed properly, the -- the electronic commerce or Internet commerce took off. And -- and -- and it's a significant contribution of the Worldwide Web to assure the business community that this -- this medium can be used for -- for commercial purposes. By adding MIME-type plugin, they added extensibility. So if one were to be sending to the browser a particular type of file that the browser has no idea what to do with it, it could put it -- it would come in the MIME-encoded format, and then referring to a particular table, the browser could choose should I start this application program on the data that you have sent. And these functions continue to grow. People have continued to add since 1996 and '07 when in the last 15 years the Worldwide Web has completely changed the face of Internet, and -- and -- and the computing that goes on the Internet. And new services like web services have been added. You can check the hotel.com [phonetic] website, which has great details and wonderful details on Worldwide Web. So what exactly happens in the Worldwide web, which is the hypertext transport protocol? It turns out that it actually use a layered structure within the application layer to accomplish its tasks. In the simplest level there's a browser, which is the client, and there's a web server which is a server. And the browser is going to say to web server send me a file that I want to render on -- onto my screen. Turns out that hypertext transfer protocol, if you look at the picture to the right, is nothing else but the Telnet protocol. And so you could say HTTP is protocol, or -- or a layer that uses the Telnet. You can go into your PCs and type the command that's -- that's -- that's on the beginning, it's on the top which says Telnet www.hotel.com, and then you have to give a port 80 with a space space port 80. If you don't give space 80, then it uses the default well-known port of Telnet, which is port 23. And I'm quite sure that hotel.com does not open port 23 to the world. It opens the Worldwide Web port, which is 80. So if you just did Telnet directly to them, you won't get any response. But if you do Telnet to [inaudible] on port 80, the way we have typed in here, you will see the respond that comes back, which says trying, then it says connected to ww hotel.com. There's a message which is typical of Telnet, which says escape character is control right bracket. I don't advise you to actually click on that. And then next thing you're going to type is that line which says get space forward slash space http forward slash 1.0, and then you're going to hit Enter twice. But before I go further, I want to point to you that when you look at the Telnet command, notice that it's using a name -- a DNS name. And actual communication of the network layer would require the IP address, because that's how the network layer communicates to the routers, routers communicate to the next machines. So what had to happen when Telnet was invoked, Telnet first invoked another layer of DNS -- domain name services -- to whom it presented the name www.hotel.com. DNS services did not know what the IP address of this particular name was, but looking at hotel.com, it had an idea to ask another server somewhere in the world about hotel.com. So in other words, HTTP which uses Telnet, Telnet that invokes DNS, DNS does client-server -- Telnet invokes DNS in a client-server fashion, DNS invokes client-server programs to go discover the IP address of hotel.com, returns that to Telnet, and then Telnet uses that IP address to connect to port 80. ^M00:23:34 [ Silence ] ^M00:23:38 >> When you type get forward slash, etcetera, and put Enter twice, and it should sort of requires it twice, you will see a response. And that response has two parts to it. First of all, remember HTTP is a protocol, that means it has its own header and its own data. And what you see on the top of the response in italics is all about the data that hypertext transport protocol cares about. When you learn this -- go to www.hotel.com on the browser -- you will never see any of that. It is purely for the consumption of the browser, which is following the HTTP protocol to understand what's being said. A lot of things are being said. It's talking about what the server type is, in this case Apache, date, etcetera. You can see things like cache control -- cache control says no store, no cache, must revalidate. All that basically says is client side should not keep a copy of it, it should always come back to the server to get the latest version. And -- and towards the bottom it says content type text slash html. By identifying that, it's basically saying to the browser that look, what follows after this is going to be an HTML document. And it'll be of the type text, which basically means it's gonna be an ANSII or even code encoded. Following which, the angle of bracket starts, and whenever angle of bracket starts with HTML beginning, you know it's an HTML document. And the entire content of hotel.com comes from an HTML document just like that. And because it is done in HTML, which is a part of HTML, it is purely printable, and you can actually take a look at it. And so every time you go for the first time to any website, this kind of an exchange actually takes place. And when that HTML document comes to the browser, browser's interpretation of that HTML documents translates into a screen with appropriate bolding and titling, and -- and spacing as requested by the HTML. And that in itself completes a set of message exchange -- a client-server message exchange between browser and the web server. In Worldwide Web, naming is done through uniform resource locator, or URL. An example of URL is HTTP colon slash slash www.hotel.com. And the various components on that particular URL happens to be -- first it says what the protocol is. In other words a browser is flexible enough to not just speak HTTP, but it can also speak FTP, it can also become -- if [inaudible] in SMTP kind of communication because of the mail 2 [phonetic] protocol. And so it can be extended. I have seen some of the vendors who -- who provide streaming media to create kind of protocol that's related to streaming media. We have also seen Microsoft creating, with its Office communication systems for web-based meetings, another protocol perhaps SIP -- S - I - P -- which is used for communications. Then there's a name of the server itself, and an example would be dbmicolumbiaedu. One could -- one could actually put an IP address. If the name is provided, then the system -- the browser will automatically use DNS to find the IP address. One could add an optional port number by following the name of the computer -- name of the server with a colon and the name of the port number. So one could run a web services -- a web server program. It doesn't have to be on port 80, that's why many times you see them running on 8080, or 8 0 8 0. And then if -- when that happens, the browser by default will always pick up 80, unless you put colon 8 0 8 0, in which case it will use that other port. And then typically after that there is a path. In this particle example, if education hit program -- HIT program, their HTML brings up the health ID certification details from the www dbmicolumbia [inaudible] system. Now there are other possible protocols, as we talked about, FTP, etcetera. And [inaudible] like FTP, the interpretation of what path actually means would change. So if you would try to do FTP colon slash slash FTP.columbia or adu slash Kermit [phonetic], you will find that it takes you to a directory called Kermit. And there's a bunch of files there that if you want, you can just drag them to your desktop, and it will -- it will complete that activity using the file transfer protocol. The Worldwide Web also added the CGI programs -- CGI interface that was a part of how to make it dynamic. And this is the way it really works. You have the browser on the left-hand side, and you -- you can request to the web server to have a static page, which is essentially a form. So let's say a form is -- it's sitting in -- in browser side, and a user fills in the form and hits Submit. Then the form elements will go from browser to the web server. Web server, looking at the form elements would determine that it cannot do anything with it, all it wants to do -- all it has to do is to start a program, and deliver the form elements that have been passed to it to the program, and let the program do whatever it wants to do. ^M00:30:10 >> To start a program dynamically by passing the parameters, which are the form elements, is the CGI interface -- gateway interface. And any program can be started by the web server using the CGI interface, and passing it the parameters. Now that program, let's assume that it's interactive with a database, and all it wants to do is take the form elements, store them in the database, and give an acknowledgement back. So it could then interact with the database by -- by MySQL commands, and store the data, and pick up the result from the database, and send it back by rendering an HTML document to the web server, which web server would then just simply forward it to the browser. And using this method, what happens is different kind of CGI programs can be written to do different kinds of things. They can be sufficiently flexible that they can themselves be client-server programmed to other systems, or they can actually access databases. They can do any kind of computation that the web server itself does not do. It is a great way to extend the functionality of the web server from just being -- delivering static pages. Over past 10, 15 years, this model has stayed true, and it's worked beautifully. But it is changing, and that's an important concept, that any system, even if it's very useful, will eventually change. And part of the change that's happening in the Worldwide Web is that the old combination of web server with CGI programs actually being replaced by environments -- web application development environments. A typical environment on the open source world would be Apache with Tomcat server, which then within itself allows programs to be written. You could think of them as CGI programs, which origin in Java, and these -- and -- and -- and the language of Tomcat server they would be what they call servlets. These servlets could communicate with the browsers. The browsers are becoming more partners in terms of exchanging information. In addition to just rendering simple HTML, if they received XML they could actually do some computation as well. So in other words, nobody forces the client to just simply be a browser, it can then start to become different kind of a peer program. So SOAP protocol, which is object-oriented protocols that -- that many companies are using now, and creating a partnership between the -- the client end and the server end. And these SOAP protocols with XML data are giving rise to new kinds of interface to the web server, and they are typically -- they are typically called web services. Now you don't have to use Apache Tomcat server. Microsoft op-net [phonetic] environment also has an example such as that. So those are the reasons, and that's how the Worldwide Web works, and has become so popular, because it has provided simplicity, along with extensibility, flexibility, security, and great usability overall all the great quality attributes we appreciate and we have learned that we need to appreciate. And Worldwide Web provides that kind of functionality, and provide those kinds of quality attributes. We now enter the world of distributed computing models. So when we talk about client-server, they're classes of different types of client-server programs. You've already seen some examples with Worldwide Web and domain name services. Now we get to classify them, and in simple, straightforward ways. So we understand communication is the key, we understand that applications must exchange information, which is what gives right to what we call distributed computing. Some computing happens at the client end, some computing happens at the server end. Properties of chosen communication methods do impact overall systems design and efficiency. You will see the models, you will understand what we mean by that. Models of distributed computing to help us understanding at a systemic and a higher level what is it that a vendor's application is doing. And if they're using one particular model, then we understand this has these implications regarding performance and availability. If they use another model, then we can [inaudible] that as a different client. But understanding the model helps us understand what the vendors are doing. Independent, the whole distributed computing discussion that we're going to have now have -- will -- will not avoid [inaudible], will not avoid link layer, will not avoid physical layers. In fact, the beauty of understanding networks in layered structure is to modularize the various components and services in such a way that you can discuss everything at the application layer, which is what we are doing now regarding distributed computing model, but it is not interfering -- it's not interfered by what's happening at the lower layers. That's a great way of isolating and modularizing the understanding, and -- and clarifying how the distributed computing is going to work, without confusing [inaudible] going to work. So the simplest computing model is what we used to know, called master and slave relationship. An example would be you had a PC, and there was a serial connection, and that serial connection I'm talking the old lars [phonetic] 232 serial connections, or a parallel connection, which was a printer cable, and it's connected to a printer. Printer does have a CPU of its own, but it's dedicated towards doing a great printing. But in a master slave relationship, the master happens to be the PC to which this printer is connected. And all the PC is going to do is communicate with the serial line, send it the data, and tell it to print. So typical dumb terminals, dumb printers, there would be no real graphics associated with those dumb terminals. Typically UV directional order, master tells the slave do something and it gets done. And even today we have ICU devices which use [inaudible] to connections to the sensors that are connected to the patient. And when the data comes, ICU the devices just simply capture the data and store it. And pictorially, all you would see is a master with a slave, and a slave [inaudible]. ^M00:37:18 >> The simplest model that we have for client-server computing is the one that we have already discussed. It's simple clients, two tiers. In the beginning, the idea was to be very efficient and useful. The graphics were not involved. Telnet, Secure Shell, FTP, these are all examples of great 2-tier client server programs. And in the picture you can sort of see that a server offers mail, secure shell, and post office protocol, print protocols all in the simple way of 2-tier structure. Over time, we started getting desktops which were very powerful. They got a plaster CPU, and as the operating system itself became graphical -- both Macintosh and Windows became graphical user interfaces, people started adding a lot of logic regarding rendering that graphic, as well as do a lot of computation onto the client side. And that gave rise to not simple clients, but FAT clients with lot of logic into them, which they were using to do advanced graphics and advanced processing. So in an example like this, then you would see that desktop client gets data from the application server, and actually then renders it besides doing a lot of processing on it. So that would be a scenario in which the client became a FAT client. The problems arising in this computing model are quite a few. People actually thought they can run production systems this way, and having run them for years, they found out that there's some problems that are extremely complicated in this model. An example would be the version problem. Because desktop client is significant amount of computational code that resides on it, for both rendering and for processing, as new upgrades come for that pieces of software, how do we push the new pieces of software through thousands and thousands of desktops throughout the institution. So changing the system was one big problem. Another problem was the client power problem. At some level we would never have always the best possible desktops on every desk. So we would always have a mixture of 4 to 5-year old computers to brand new computers. And so therefore when an application is written with an assumption that a client has to be minimally this much powerful, we couldn't provide that across all desktops throughout the institution. The other components -- we talked about the upgrade problems -- the version problem also includes the fact that as underlying operating system changed, the change required us to upgrade all our clients to some other part. And that itself was also a big undertaking, and a difficult problem. Many applications -- as many FAT clients got added, the desktop started to become bloated, because each client-server program wanted a FAT client. And then they started to interfere with each other in terms of their requirements of the version of the softwares on the desktop, and -- and because there are thousands of desktops, each of these problems become very significant and time -- because of the problems with the FAT client, a new model was proposed and followed through, in which the idea was to make use of the graphics hardware that's on the desktop client, and to just use it to render graphics. And that too -- graphics that has been first created and produced in an intermediate place, which in -- in the picture is the Citrix server. So the way it works is that the application server in the back end provides data to an intermediate front-end machine which is a Citrix server, where the logic is executed, the graphics is actually rendered with the Citrix server then, which has no terminals -- there's no monitor connected to those servers, then sends it over to the desktop client using a protocol called Citrix protocol of course. And the desktop client simply takes the data that's sent by the Citrix protocol, and renders it on the screen. By doing this, we first note that it becomes a 3-tier structure -- Citrix becomes a 3-tier structure. If you use the same kind of concept between two Windows machine using Windows remote desktop protocol, it would become a 2-tier protocol. In older times there used to be a system called X-Windows on the Unix, and it first started doing graphics rendering as a client-server program. One of the problems it faces was that it incurred huge networking costs, where the new Citrix clients, and Citrix-based 3-tier structures do not have a network problem. What -- in addition what you do in this particular scenario is that in the Citrix server, which is actually maybe a physical server or a set of physical servers, one actually starts to run virtual PCs on the Citrix servers. And whatever that's being rendered in the virtual PCs is sent over to the desktop client to just render the screen. And that is something that the desktop client can do very fast. So in today's world, these 3-tier structures are very popular. Notice that you take care of the upgrade problem, because all the upgrades have to happen only on the Citrix servers. So in terms of the numbers, if you would say that there are five application servers, and if there were desktop clients of the order of [phonetic] 5,000, you [inaudible] may have less than 50 Citrix servers, which can handle the concurrent load that comes from 5,000 desktop clients. And it's much easier to upgrade and keep track of versions for 50 Citrix servers, as opposed to 5,000 desktop clients. ^M00:44:35 >> So that's why a 3-tier -- 3-tier computing model is quite popular model in today's world. So when we look at this, this is also called a 10-client model, in which the graphics and the client is not really doing much logic, all it's doing is whatever has been rendered and putting it up on the screen. In the 10-client model the exchange of data is typically in the markup language. Worldwide Web is an example of 10-client model, in which the browser gets an HTML document and just renders it. It does create a good uniformity across clients, because the clients can be 3 to 4 years old, or can be brand new, as long as they are asked to do something simple, like either render an HTML page, or just follow the Citrix protocol. Then they can actually do that, even if they are older computers, and therefore uniformity is achieved. It's possible that the 3-tier structures can become 4-tier structures. So what we find out is this 10-client access from all the workstations of the desktops, their intermediate application server, which is a Citrix server, we have FAT client access to the application server. And it's possible that the application server instead of just picking up the data from its discs is actually communicating with the database server which is separate computer, and that gives rise to 4-tier structures in today's day [phonetic]. The new models that are starting up today, they are not just based entirely on graphics, but also exchange of data. Those are the web services model, and in -- in case of HTML and HTTP Worldwide Web, we exchange data using HTML. When you're using web services, in which it's not about just graphics, then you are going to use XML -- extended markup language -- to exchange data. And standard protocols are used nowadays. Web services, which are derived from HTTP, could be SOAP protocols. And those are the various ways today's computing models actually work. We now move on to applications. And in the applications we consider first the simplicity that there are three components to applications -- one, there's a user interface, where data are being reviewed, data are being added, as well as if it happens to be a device, then the device interface is -- is what the user interface is about. The other side of the applications, data being stored, because it -- it -- there are users who are looking at the data and manipulating data, but that data is actually stored in the data store, and the application itself gets the data and then processes it. And the various kinds of processing that are possible in today's applications are transactional processing, batch processing, and analytics. So we want to go deeper into this to see how in healthcare infrastructure these applications interact with each other in typically obviously client-server way, in either 2-tier or 3-tier structures, sometimes even 4-tier structures. And we want to get to a level where healthcare applications are being used to see how we move to even higher [inaudible]. So in an application entry and [inaudible] of user interface, we know that we need today real-time interface, where users are going to be using the system in real-time mode. They have to be graphical in nature, because that's just simply the expectation of this day and age. And it's going to be used in some kind of a client-server communication. But note that the data that are being stored in the applications do not always come from the users. Many times they do, but also in healthcare they come from other applications. And when one application sends data to another application, it's typically independent background activity. That activity can be real-time or semi-real-time. That means a patient has been admitted by registration at 2:00, if that admit registration message flows into other EMR ansillary [phonetic] systems within next five minutes, we would call the system semi-real-time or batch. And in [inaudible] perhaps the five minutes it would be semi-real-time, and if it happens overnight then it will be called batch. And typical standard of exchange of information at that level is going to be HL7 -- help [phonetic] level 7. We have several lectures associated with HL7 and other standards. We have to remember that whenever we're -- we're looking at applications, 80% is read -- users are looking to see what the data says -- and over 20 -- the data store end, we have various mechanisms of storing of a generic application. It could be storing things -- data in the files -- the files could be formatted or simple -- or they're going to be databases, which are collection of files with lots of indexes, and indices, and tools. Important part of data store is what kind of media we are storing it in, and its speed and its availability are all issues regarding planning a system which is going to use discoveries and [inaudible] and -- and NAS, which is network attached storage, replication -- all kinds of media activities based upon how useful is that data. ^M00:50:32 >> The format of storage of data in -- in databases -- they're relational or hierarchical, then there's a concept of learning how to create a schema. What are the various tables? What are the conditions on table values? And how are they modified and improved upon is -- is all part of the data store activities. One has to watch out for the changing [inaudible] should not be statically -- on what to solve for today. But in the rest of this lecture we are going to go look at deeper how data are processed in applications. So the first model of data processing and applications is online transaction processing, or OLTP. OLTP is a kind of activity where the amount of processing is not very large. It is about capturing data from user, and storing it in the database. So it's lightweight processing, but it is very high volume during the work hours. During the work hours when the patients are coming in, and the registration in every -- every place are actually doing this online transaction processing to register as the patients come in. It is somewhat network-intensive, because all communication has to go over the network. And it is obviously dependent on the network. These applications typically enterprise cross-applications, which is registration and scheduling at the highest level with the department systems. And these applications that are transaction processing of course always earn money, because that represents some service that has been provided to the user. Contrast this with batch reporting -- and I -- I presume we don't call them offline reporting, but it could be. In the batch reporting functions, it is possible that your online transaction processing database, instead of being exercising it to create 90 reports, you would automate a replication of data from the database of our electronic medical record into a side SQL server database, where you can then run batch supporting without affecting the original system. So this is a decision you make only when you see and implement a system, and you find that your batch processing is going to be very expensive proposition on the OLTP site. And if that is true, and you have figured that out, then you figure out a way of copying the data out -- out of your OLTP system into a smaller system, where you can then run the batch reporting functions without bothering the OLTP system. When you're doing the batch reporting, it's a heavy database access, because you are going to access patient information across -- on -- on -- on many patients. And it's computer-intensive, because a lot of computational activities happen when the batch reporting happens. Typically towards the end of the month, or year of the -- end of the year, the volume of work goes up. Nowadays in the batch reporting no one really prints the reports onto paper and distribute them. Instead what you do is you take the printer output, and instead of putting in paper you put it in a PDF file, and you distribute using what else but base solutions, whether they're Wikis or otherwise, or share points, where the reporting is a distributed through -- through web-based distribution. The trend of course is becoming more and more on the real-time reporting, because you get better efficiencies and better systems and more business that way, and also to incorporate business intelligence as well as clinical analytics up front, just in time, as opposed to waiting for a month later to actually execute. So if we're in our data processing, then here's an example of our order into results [inaudible] application at Columbia University Medical Center, New York [inaudible] Hospital, which uses all scripts of [inaudible] XA order entry application. So let's look at the properties of this application. It is a Windows application, and has database servers. So it has application servers and database servers. The database servers are serving data from Microsoft SQL server. What we don't tell you is that Microsoft SQL server is working on top of a LAN on the discs, and those LAN -- LAN isn't proper, the phrase is [inaudible] network, SAN, and that SAN is replicated over multiple data centers using software that helps them to replicate that. So even though we're talking at a higher level -- application level redundancy, even if we don't talk about it, we can assume that at lower layers there's additional redundancy available. So storage is on SAN, on -- on the all scripts end of things. The user interface it has is Windows graphical user interface. It also has an iPhone application. And the model of user interface on Windows is a spreadsheet model, with cells having values, as well as spreadsheet itself has tabs to go over different applications to look at different data. We offer all scripts sunrise XA order entry application, using Citrix servers, with a 10-client environment. So because Citrix servers with desktop and application servers already 3-tier, by adding the database server, this is a 4-tier application. The processing is online transaction processing. This is about what tests and procedures have been ordered for patients. And the batch reports that happen happen by taking the -- a replica of the copy of the database to the reporting database, and then the -- the data reporting is distributed through web distributions. ^M00:56:54 >> Another example of data processing is again, at Columbia University in New York [inaudible] hospital registration and billing system. This happens to be a Siemens product called Siemens Eagle Registration System. The storage actually is on mainframe social storage area network. The operating system is IBM ZOS on IBM [inaudible] mainframe, and we are working on recent files that are part of that system. We find that the user interfaces are quite archaic. They're still based upon old IBM 3090 terminals. However, nowadays we use more Telnet or TN 3270, which is a client-server program to sign onto these terminals, and one is about bringing new web-based interface. This processing still online transaction processing as people come in and get registered. Batch reports are generated to Windows servers to distribute out through the web. And -- and it -- how this component of the billing actually works. So when we take the data processing, and we take transaction processing and the reporting, we get a picture in which we have a mainframe, and we have a user sitting on 3270 terminal and Telnet client, and the user uses 3270 terminal to access the data that is still sitting in ZOS. And if -- if we need it, the user could actually Telnet into the application and get to get more information, or help them. We then find that reporting, which is batch bills [phonetic], which is a separate system that can be done in which the ansillary systems are sending the bills over file transfer protocol to Eagle, because it's also chart system. And the reports that generates overnight are actually sent over to the Windows servers to be distributed over the web. So looking at this component, we see that the Windows server that serves the web actually has a web server, IAS, that is used by our user on the browser on the right-hand side. And so user uses Telnet to go into the registration system, and uses browser to look at the reports that come out of the registrations. Then within data processing we come to the component which is called online analytic processing, or decision support systems -- OLAP [phonetic] and DSS. ^M00:59:30 >> Here, the view of the data is not as slow as batch, which is at night, but it is probably not as immediate as a transaction processing system as well. It is within semi-real time, or intermediate term. So one is looking at the views hourly or daily, and you're looking at a multi-dimensional view of data that has come from multiple different applications, not just Eagle. And then the data replicated to OLAP tools, they are typically business intelligence systems. Data comes from multiple sources, time requirement is semi-real time, and what we get out of the system is alerting, which is if there is a concern clinically about a particular patient that can be coded as part of our syntax, which is a way to write rules in the system, then we can find that we can generate alerts out of the -- processing. So when we look at the pictorial form of online analytic processing, we find that our Siemens Eagle system, which does the distribution, has the following analytics programs. There is an all scripts DSI analytics programs in which we actually send data out to an outsourced environment, where data on the analytics and we get reports. We also have created an internal environment of web-based display of data on the business intelligence side that also gets data from Eagle. And then there is a system called [inaudible] by [inaudible] system that is part of revenue cycle processes, so that it can do better revenues coming out of Eagle. And it has a lot of proprietary knowledge on old accounts and Medicare payments, and therefore it works well in trying to recover -- so when we look at the picture, we see that the Eagle has the analytics component in [inaudible] assign, sent to [inaudible], sent to business intelligence services that are running on a Unix system. Now there are applications that also sending that kind of information to business intelligence services. So if we take this picture, and merge it with -- we actually get this, in which on the left-hand side of the OLTP components, and we have just newly added the analytic components. Note that every arrow out here is a client-server relationship. Well what if -- well we find that from Eagle we verify charges or bills, and eligibility. And in order to do that, we're communicating the Blue Cross-Blue Shield, or network recovery service so that we -- our bills get paid, and other insurers. So that kind of communication can now be added to this picture to show the kind of data flow that actually [inaudible] from the Siemens Eagle system into these other business-to-business -- then we notice that we actually have clinical data that are called [inaudible], which is a discharge of transfer events that have to flow out of Eagle, because it's the registration system, into all the ansillary systems, lab, radiology, pharmacy, etcetera, because only then they get the latest information, so that when somebody calls in for a lab test, they already have that information -- people upload it in their system. What else can we add to this picture -- in our final slide here, we have added one last component to our data processing picture, where we're doing online transaction processing, reporting, analytics, b-to-b, movement of ADT data, and then finally we have added systemic data that comes from our credentialing database which [inaudible] our providers, such as physicians, nurse practitioners, physician assistants, which all have to be loaded into these systems for the billing purposes, as well as definition of our users for the purposes of signing on into the systems. And these systems that -- that maintain these databases have regular feeds, typically in the batch mode, sent over to our online transaction processing system. And -- and that -- that -- that adds to the complete picture of how data flows in and out of just the component that's dealing with registration and scheduling. This is -- this -- this part is separate from our electronic medical records data flow, which has far more richer clinical data flow. And we're not gonna show that picture because it is more complex, and it's -- cannot be drawn simplistically the way we have done it here. The goal here for us was to look at various processing of data models -- data processing models, and -- and -- and by adding one component to other component, we show the relationships and how they're interdependent on each other, as well as in the layered structure how they use the lower level communication to actually exchange data. In our next lecture we'll be talking of some specific healthcare middleware applications that are useful in all healthcare applications. And so we'll continue on to lecture 4.