 So, we start the second session, where we look at some aspects of modern applications and also get an introduction to the performance issues. Specifically, as I mentioned, we look at the multi-tier architecture, we look at enterprise applications. For example, many of you would be looking at currently specific subsets of your enterprise applications. Front-end system, somebody may be looking at data warehouse, somebody may be looking at operational data stores, somebody may be looking at web portal, but they are all or somebody may be doing something in HRMS, somebody in investment. All of these applications need to actually integrate with each other and towards that, we will talk about enterprise application integration and in that context, we will very briefly look at the service oriented architecture. Towards the end, as I said, we will introduce the performance model. So, here is the basics of multi-tier application. First of all, you are familiar with back-end database now and you are familiar with front-end client. That's exactly the environment that you have been using so far. From the front-end client, you connect to the back-end database and execute whatever queries you have, what are database offers? The application logic in such cases is usually split between the two. So, there is some application logic which is coded in the database in terms of procedures, triggers, whatever you may have in terms of basic validation which are buried into your, what you call constraints, something which is not solvable by constraint, you will write some procedure there. There will be some logic which will be put into the front-end. For example, simple validations. So, some codes that you have used and the code tables are small, parameter tables are small, you would like to do the validation locally itself. There may be some logic which is built into the application software which is running on the front. Say, a COBOL program is running on the front-end, then it will validate if you have, let's say, 150 different tables, not the database tables but your tables kind. So, you might want to keep a prescription of those tables in the program itself and that kind of validation can be done locally from the front-end. You don't need to go to the database. However, there are always occasions where frequently you will have to go back to the database. So, some validation may have to be done using the back-end database. So, you will have to read the database. You will have to put something in the database. In general, in a two-tier application, typically you need to hold a connection to the database. So, that is what you call logging on to a database. Right? A connection to a database is actually a slightly costly thing in the sense that whenever you connect to a database, the database server needs to create a context for you as a user. It is not uncommon to require, let's say, 2 to 4 megabytes of memory space for keeping that context alive. More importantly, it is that physical connection, a logical connection that needs to be retained for you. The number of such connections that can be made to the database are often limited. For example, if you have an oracle back-end database, typically you would connect directly to a database to the tune of 8 to 10,000 users. What if you have 20,000 users? What if you have 100,000 users? The database may give up. So, these are some of the problems which do not permit easy scale-up if you continue with this architecture. In that case, what you do is you do some kind of a connection pooling. So, that means you put some intermediate layer before the database to which multiple users log on. So, there are maybe 100 users here. Now, that intermediate layer may maintain only 10 connections to the back-end database. Those 10 connections are maintained full-time and any one of those connections is used to satisfy queries which are executed by any one of the 100 users. So, this connection pooling ordinarily would have to be done artificially by introducing an intermediate layer. As we shall see, in a three-tier architecture, this job is also done by the third tier which is now introduced not merely to take care of connections. In fact, that is not the purpose at all, but the purpose is to take the entire application logic and put it in this additional tier. So, a three-tier architecture separates out the application logic in a tier called application tier. Now, this logic which consists of all the executable programs which do no reading, writing to the disk and which do no user interaction. These things only do computations, calculations, processing, logic. This job is dedicated now to the application server which is not necessarily a physical server, but it is a logical server. It could run on the same physical box as the database server runs. In fact, if you have a high-end PC today, you can actually implement a three-tier application by creating a database layer within the same PC, by creating an application layer and running an app server. Appache is one example of another. There are many app servers, WebSphere or no, sorry, not WebSphere. WebSphere is an app server which can actually take your code for application logic and run it there. The advantage of this additional tier is that you can actually run multiple instances of these servers either on separate physical boxes or even on the same physical boxes. The load which any software can take is not dependent only on the hardware which it runs on. It is also dependent on the certain inherent architecture of that program itself. So, if you try to run 20 users by the same program, there could be problems. If you try to run 2000 users, there could be many more problems. But if the programs are identical, you can actually put a configuration of such programs running on multiple instances and then you can say these 100 users connect to this app server, these 200 users connect to this app server. All may be doing the same. The advantage is that even if one app server instance dies, you can automatically reconnect those users to another app server and the activity can continue with of course break in that particular transaction or particular activity that you have. Further, a lot of load balancing is possible. So, if you have 20 app server instances, then if one particular app server gets loaded more, it is possible to detect that automatically and transfer a few users or some load from this app server to another. Such load balancer software is also available routinely now along with the app server. The biggest advantage of application services is that they can scale horizontally. That means physically you can deploy 20 more physical servers and put app servers onto them and suddenly you can handle more number of user process or more number of data. A database even today typically scales only vertically. So, the database can exploit parallel resources, but within a single environment. So, you have a large database server which may have let us say 16 nodes or 16 processors, 32 processors, 64 processors. So, all of these can actually be enhancing the performance of the database, but it is generally not easy to have 20 different systems connected together, pulled together to enhance the capability of the database performance for transaction processing. For query processing such parallel distribution is possible and that is why you will find that most of the data warehouse implementations use a notion of database distributed a parallel database which is actually physically split on multiple nodes. Such a architecture is called shared nothing architecture for databases. Talking about the app server then, app server can also do the pooling of db connections which I mentioned. In fact in modern applications it is almost mandated that this is the kind of architecture you should construct. You should have the front end user related logic in your front end application which runs on the front end. You should have the complete application logic only in the app server and you should have any data management related activities only in the database. Consequently the app servers will be connecting to the back end database using odbc or jdbc drivers which you would have seen depending on which programming language you use for maintaining app. More importantly this permits you to actually capture even the user front end logic to some extent into another server called the front end processor. So for example today in cobalt you have to run a cobalt program on the end users machine or on a server where the screens etcetera which are displayed to the end user are actually managed by that cobalt application. Your cobalt application is doing two things it is managing the front end user screen it is also reading and writing to files and it is also doing computations and processing pertaining to your application. So today you have actually a single tier application software. Our job is subsequently to move to a multi tier architecture like this. These are particularly important in the context of web enabled applications. You see these instances every now and then applications which basically exploit the web, which exploit the internet connectivity, which exploit the ability to access websites, which exploit the ability to use search engines like Google Yahoo and so on. So a complete branch of applications called e-commerce applications that you would be familiar with have come out because of the web enablement. The e-commerce is nothing but commercial activities conducted electronically. Here are some examples of web enabled applications. Simple advertisements of production services. This particular thing is relevant for our discussion of service oriented architecture so we shall see that later. But executing transactions on web. You can do information collection on web like form filling, registration. You can do payment on the network, credit card payment for insurance premium, any general banking transaction. Many of you would have been doing this. Typically there are multi-party transactions. So multi-party transaction means take a railway or airlines reservation. It's amazing in India today by the way you can actually do a railway reservation and get your ticket printed at your internet. Now look at how this application will be working. If it were only to connect to a railway backend database server, it's one way. So you log in sort of and connect to the backend database server and get. But railway has to collect payment and railway does not have any direct method of collecting payment. So railway will collect payment through your credit card which will be authenticated from your bank. So there is a bank application which must be running at that time. And the bank application, your front end and the railway reservation server or this railway reservation application all must talk to each other in a synchronous fashion or in an apparently synchronous fashion. Synchronous and asynchronous are two very, very important paradigms in life. And synchronous is fastest but asynchronous is more workable. Both are required in life. The comparable thing is a telephone call. So if I call you on a phone and you talk to me, it's a synchronous connection. The problem with the synchronous connection is when I call you, you must be available. If you are not available, then I have to keep trying arbitrary whereas an email is asynchronous. I send you an email. I'm not waiting for response. I'm waiting, but I don't have to wait online. So I can go do my work, come back and whenever you get time, you look at that email and respond. If the asynchronous mechanism is made almost synchronous, in this example, it would be like chat. So chat is my message is going there. But I need not wait for the return message to come. I can read my book. I can do something else. But if that person is online, so online does not necessarily mean that a connection between you and me is occupied always. It is still messaging which is a synchronous mechanism. But messaging done very quickly almost amounts to online real time kind of in general for the railway airline reservations, you require a user, you require the reservation server and you require a payment gateway. Whenever such multiple entities are involved, there are multiple applications. Please note that the payment gateway application might be written in Java and back end database. The railway reservation application might be returned. Guess what? In FORTRAN. Do you know that railway reservation in India was first implemented using FORTRAN programming language? That particular FORTRAN called VAX FORTRAN actually had index files and relative files implemented in FORTRAN, which they use. That is because they did the stupid thing of first selecting a computer and then deciding how to develop the app. And then they found out that the cobalt did not run well on the VAX machines at all. But FORTRAN ran as much as five times faster. So they use FORTRAN. That is of course old times. Now things are different. What I meant was that you could have completely disparate software environments on these different servers. And yet the end user must be given to believe that there is no difference whatsoever. He is using a single access point. There are new issues, however, even when connectivity is guaranteed. Connectivity itself is a problem. You can see now that how do you maintain, for example, a two-phase commit or even a normal commit, a transaction, acid property. I got a reservation, but I have not yet paid. Or I have paid, but I did not get my ticket. Now these problems will have to be resolved. Apart from your database crashes and other things, now the network disconnectivity becomes an additional problem. So you need to provide persistence at every stage for the information that you have already collected and ensure that it is connected by the end result. And then only you get rid of it. Otherwise you must have a mechanism of undoing a transaction or whatever. Transactions in physical space have certain advantages. For example, if I am doing a transaction with you, let us say I am a shop keeper and I sell you something, you and I see each other physically. So I can know generally that you are my customer or I can have other ways of identifying. I can authenticate you because you are ordinarily paying cash and the exchange of cash and goods happens simultaneously. In e-commerce, sometimes the order is placed for say some e-book, let us say or some electronic content to be obtained by, let us say I am purchasing software, which is all computer readable material. So I place an order, after sometime the order is verified and that fellow sends me the software, which I start using. What if I pay him and he does not send me the software? What if he sends me the software and I don't pay him? What if I place an order and later on when he sends me the software, I tell him I never place this order? What if I have arranged for an electronic payment through an account transfer through a bank, where I have said that I am giving an equivalent of bank guarantee. You give me these goods, after I certify that you have given the goods, the bank will give you the money. So after I get the goods, because the goods are electronic, I start using them and later on I say that no, no, no, this was a mistake, I never committed to pay you this much money or whatever. So a whole lot of issues like repudiation, security, authentication, they crop up in a completely different way than they do in normal system that we, even in LIC you can see that the security notion that most of you have in your programs is very minimal, because physical security is guaranteed. Only those people in a branch can access that server, nobody has ordinary. Now you have a wide area network, you have additional security problem. Now you have a portal where extra people can come in, you would have additional problem. All these issues are issues which come into the transactions when they are executed in a digital space. So you have authorization for which you have firewalls, the conventional authorization will not be sufficient. You know excess, you have this password and therefore you can get into my database, it is not sufficient. Confidentiality is to be ensured by encryption. There are two typical encryption algorithms, one called the symmetric key algorithms, these are DES or triple DES, digital encryption standard, triple DES standard and there is a famous RSA algorithm for asymmetric key. I, India by the way is one of the few countries in the world which has through its information act guarantees that if you have a public key encrypted document or a digital signature verified document then that document electronic form is a legal tender in any court of law. It is a major step, many other countries have not yet done it. Going forward then these things will become important. Non-repudiation merely means that the proof has originated from you and you only. Suppose I send my resignation later because I have a fight with someone and tomorrow I say no I did not send this later. There should be a mechanism with my boss to say no this digital signature allocated to you verifies that you have sent it at this time at this date from this machine end of the matter. In general web enabled applications take different forms and they are characterized by funny acronyms. The whole field is full of acronyms so B2B means business to business. Any inter-bank transaction or any transaction between an ancillary supplier to an automobile industry would fall under the B2B. A G2B means government to business so corporate tax returns, company filings, a number of things that you can think of will fall under government to business. G2C a government to citizen or B2C from business to citizen are of course the more important parts of the more predominant and more widely used parts. For example you permit me to get a insurance policy on web and you are actually permitting a business transaction to a end consumer. It's a B2C kind of application. Distributed applications that means an application which is partly working here partly working there partly working there is not new. What we talked about earlier were distributed applications where one part of the application was with one organization another part was with another organization but within the same organization also you could have applications which will work at different places different. In real world organizations will have multiple applications and organizations will have multiple sites each one of which will be nearly autonomous. Consider LIC situation today exactly like that. Each branch is nearly autonomous entity. It has its own server it has its own transactions it carries out. It reports to you of course it gives you all the data etcetera. But if somebody else wants to control those transactions then that access will have to be given. The access that we give through a semi-centralized mode today you do a transaction on web then I take that transaction and somehow post it into the branch or I collect the branch transaction information and post it into ODS. These applications not only exchange data with each other they exchange they will in coming years will have to exchange data with other organizations as well. In our case take regulatory information required. So you are required to interact with the regulator who might have a different set of application. You might be required to interact with other countries in which the information is exchanged in a different form. For all of this the notion of distributed databases has evolved. There is another beautiful book on distributed databases also fairly old book in the context of time for the computers. The authors are Ceri and Palaghati or Ceri and Palaghati C-E-R-I and Palaghati the Italian people. The book on distributed databases is a beautiful book opens up a Pandora's box and the issues. Very briefly a distributed database will have a single logical schema but the data may be spread across servers at different locations. So you might have part of the data in Madras, part of the data in Kolkata, part of the data in Pune, wherever. You can actually do this schema partitioning either horizontally or vertically for storing the data. So you might decide that certain rows of this table will be in Chennai, certain rows in Kolkata etc. In a way if you consider the LIC's present application very very crudely it maps into a distributed application where data slides horizontally. So you have data pertaining to customers of a particular region in one branch, data pertaining to customers of another region and another branch. But the schema is identical across. So if you just merge all the rows of all the tables you get a master table for the country. That is what in fact makes it relatively easier to integrate your branch information into a single operational data store today. Life need not be that simple. For example even in the branch system today you might have certain branch specific tables, certain parameters etc which are specific to that branch only, which are loaded in that branch. Combining all of them together will not be very easy. So there that is an example where the partitioning is not unnecessarily horizontal. There is a particular table which exists only in three branches and not in the remaining 1900 whatever. Then you have done actually vertical part. In general a distributed database can have both vertical and horizontal parts. Why you, what you have today is not a distributed database is you don't have a database at all. You don't have a logical schema. The schema is buried in your COBOL program. But going forward when you have the schema even if you implement that schema in a branch keep in mind to have a single logical schema for the whole organization. So that tomorrow when you centralize the operations it should it should be just a automatic shift without having to do anything. If we don't take that care now and since we have 2000 branches we could have a lot of job in just integrating all the data from various places. In general when I have a distributed database and not autonomous 2000 systems like we have but a truly distributed database then I also want to ensure that if one of the site fails I should have some availability of data. Because if particularly if I have some data in one site some data in other site some data in third site typically this problem is solved through data replication. So you replicate data. You say that the data for this particular table will be stored at Kolkata and Chennai. The data for this will be stored at Delhi and Nagpur. So even if one place the site is not accessible exactly the same replicated data is available at other place. Data replication is also the preferred mode of ensuring what is known as business continuity through a disaster recovery site. So if you have a main site you have a disaster recovery site. You can regard disaster recovery site in the main site to together constitute a distributed database. Here the database is at both the places it is replicated. So it is identical thing replicated at both the places. But whenever you have replication the issue is of maintaining consistency that to a one table replicated at five places how do you ensure that a change happens in one table in let's say Kolkata it must happen in all the five places. The problem is not as simple or trivial as you might imagine. For example you might say alright the transaction which is updating my Kolkata database in the same transaction I will write SQL carry open database in Chennai and update it. The problem is if it is a single part of a transaction that you make then two things will happen. A the transaction will take longer now. They will have to go to Chennai also and update. B if for some reason even the link to Chennai is down the original Kolkata transaction will not go through because all of this is part of the same time. So replication cannot be handled in a synchronous fashion and therefore to guarantee replication in an asynchronous way where the link may be down etc etc is a non-trivial task. Of course there are very good pieces of both the technology and methodology to resolve this problem. I am just mentioning that it is a problem to ensure consistency in replicated database. Then there are multiple applications as I mentioned which must talk to each other preferably in real time online. Let me give you this example of the academic institution we are this problem here. If you come as a student and register in the academic office you give all your information name, hostel number, address whatever whatever whatever and you pay the fees. Next day you go to the library to issue books. The library has a different system that application is written in our case the application in the main building was I think in Kobal and the application in library was in Foxspace, Foxpro. So these two applications did not talk to each other. So the Foxpro fellow had a complete design for capturing of user information etc. So poor me would go to the library again fill up another form again they will capture the data. We had a separate system in the accounts office also. We realized the problem when one of our professors late Professor K.C. Mukherjee whose son was studying here. He wrote a letter to me I was in charge of the application cell then saying Professor Fatak my son who is a student here has his name spelled in three different ways in three of your applications all three of which are wrong. The Mukherjee was spelled by him in a very peculiar way and Mukherjee can be spelled in a number of ways. So these three applications had picked up three different piece of this inconsistency. More important than that the trouble to the end user. End user everywhere has to register him. So what would you like to have? You would like to say that the moment the person registers in the academic office that information should be made available to that library application either instantaneously which may be difficult because I might have this problem of breakdown and things like that. But as early as possible at least at the end of the day. End of the day kind of reconciliation many of you would have done. Lot of information your case would come in files at the end of the day from branch to your place which you sort of absorb. But ideally if you could do a distributed transaction which is executed in a non synchronous fashion. There are pieces of middle layer that we shall talk about for the application integration where you have persistent messaging through which you can ensure that even if the connectivity is lost whenever it comes up without losing any data the transaction will be updated at the other place. All this is part of the enterprise application integration which is the fundamental nomenclature for considering all issues of making multiple applications talk to each other. An ERP is an example of an integrated application which is integrated right at the definition point. However no organization in the world can survive only with an ERP package because now the ERP package has to interface with this application that application that application etc. In general integrating application functionality is a is a important problem. The enterprise application integration is usually built around a middle layer framework. A middle layer is like an intermediate. You have application one on that place, application two on this side, both people have to talk to each other and talking to each other is difficult. Why talking to each other is difficult because if you have to basically call one program from other place. Now that program may be written in a language for which I have no environment here. So I can't call it by writing a program. So I have to do what is known as a remote procedure call. Now how do I do that remote procedure call? I have to know all parameters, how to call that program everything here. Same thing for the other field. In general if two applications have to talk to each other there has to be a communication between the builders of these two applications and this communication will lead to understanding of each other's program and building of an interface which is peculiar to application when an application. Consider there are three applications. How many such communications and work will have to be done? One to two, two to three, three to one, three. So three times problem. Two applications, one problem. Three applications, three problems. What about four? If you have four applications, one to two, one to three, one to four. Two to one you are counted. So two to two, two to three, two to four. Sorry, two to three, two to four and then three to four and then what about if you have ten applications? You will soon realize that the problem increases factorial. That is an exponential increase. So if you have n problems in general the communication is equivalent to what we call a connected graph. You have n nodes. Each node is connected to every other node. Each line represents the problem that you have to face in integrating that. So it's a factorial n problem and that is nonsense. To resolve this factorial n problem what people said is why not I prepare a central framework. It's like a ring road. So all applications are sitting separately. No application will talk directly to any other application. Every application will talk to that ring road. The interface between ring road and that application I am defining. So if the application wants to execute something and give data it must tell that ring road how that data is being given. If the application wants to execute somebody else's program it will find from that ring road how that application is going to be executed. It will give the data in its own form converted to the ring road format. The ring road will give back the data in the same format. The ring road in turn may collect the data in a different format from some other application and convert it here. This ring road conceptually is nothing but the middleware framework. So this middleware framework can either work on what we call remote procedure calls or it can work on what we call persistent messaging. Meaning even if the connection breaks it can actually maintain things. Korba was one of the earliest such piece of middleware, what we call distributed objects. Tuxedo was a system which was built on this. There are many pieces of good middleware that you see today. MQ series is one of them. Tipco is another. We are all using Tipco. So there are multiple pieces of middleware which are available now which permit you to connect to different things. Whenever you use a middleware, the legacy applications which means old applications, they are required to be integrated with new applications, they will be integrated with middleware. So take our own case. We have let's say an operational data store which is on Oracle, right? So it is a Oracle database and the data must go into it. The data that goes in of course is our own domain date. But the data has to come from branches which run COBOL systems. If suppose somebody from a portal does a registration, the data first comes to ODS and it has to go to the branch. So they are clear case of two completely different applications running on different platforms having to talk to each other. So what we have done? We have connected or integrated the Tipco middleware with our COBOL programs and we have connected the Tipco middleware with our database. Once the COBOL programs have been connected to the middleware, today it is for the purpose of feeding into the ODS. But tomorrow if that same similar kind of thing is to be fed into some other application, you don't have to do much more additional Godagiri. Where the fundamental in what should I say contact points in your program have already been exposed through Tipco. Which contact point should be exposed is the then a requirement during design phase going forward. You would have exposed only those interfaces of your COBOL programs which are relevant for feeding data into ODS or collecting data from ODS or updating transaction on some other remote branch etc. But going forward you may discover additional interfaces which may be required. What is guaranteed however once you use a middleware is you build an interface only to the intermediate middleware and nothing else. Applications across businesses pose more problems. Why? In this case for LIC the people who wrote the programs for branch and the people who wrote the programs for ODS are either the same team or they are controlled by the organizers. Complete information is available about the software. But your railway reservation system wants to influence how the bank payment gateway should affect by transaction. It has no control over the bank. The bank will say go fly a kite. Suppose railway reservation system says give me some information about your application they will say no it's confidential. So the problem is much greater there and the people who intermediate between these different organizations for integrating applications across organization have a much greater task. Traditionally this is not a new problem by the way. Traditionally this problem has been solved using enterprise data interchange or EDI. I am talking about times when nothing like middleware or anything existed and the only way was to make that factorial n kind of corresponding. So the EDI vendors made a lot of money because they were required factorial n times. So for every pair of applications they will look at this data, they will look at this data. Somehow some standardization emerged in this EDI. In fact the standardization emerges whenever you see disparate systems wanting to share similar data. One of the best examples of this standardization coming out not as a part of software system but as a part of data standardization is the mechanism of SWIFT. Have you heard SWIFT? SWIFT is the messaging system that is used by all banks in the world for any interbank transfer across borders. So dollars have to be remitted from New York to Delhi or marks have to be remitted from Kolkata to Germany. All of these transactions between different banks happens through a messaging standard called SWIFT. All security transactions that is transfer of shares, purchase of shares, sale of shares, they all happen through SWIFT. The SWIFT handbook defines message formats are hundreds of types. The appropriate message is to be used for a appropriate activity. So when somebody sends money from Europe or Australia to an old mother in India that money invariably comes through the SWIFT messaging system. SWIFT is actually a cooperative sort of the banking system itself but they are an independent commercial organization. Curiously, although the SWIFT was designed to be an interface between different banks across the world, banks within a country also find it easier to use the same SWIFT messaging to exchange information. So for securities that is stocks there is a separate manual. Today you will notice there are two depositories in India NSDL and CSDL. Between NSDL and CSDL whenever they have to exchange information they use the same SWIFT standard messaging. This is important because we are going to say that whatever is relevant for integrating applications across organizations should also be relevant for integrating applications within the organization and that is how use of the new standards will be relevant to us. The proprietary formats and protocols which existed earlier in case of EDI for example are giving rise to generalized standardized protocols which are openly available. And the culmination of this effort particularly which goes much beyond just standardization of message formats etc to the level of software standardization or software interface standardization is coming out today in the form of what we call the web-based application development standards. The service-oriented architecture notion that we had comes out of this. The new standards are XML, WSDL, UDDI we shall see these very briefly very soon. Here is quickly an example of a future transaction just to illustrate what kind of transactions you will have to plan for even though you are only LIC. This is a rather funny example but interesting to read so let's go through that. There is one fellow called Anand Deep Singh Pannu who lives in Ludhiana is a high net worth client of a stock brokerage firm. High net worth client means what? Very rich man. Anand wishes to sell 12,000 shares of Infosys on national stock exchange. Now you know why he is rich right? A lot of shares. And wants to purchase 1,000 shares of Siemens AG on Berlin exchange and 5,000 shares of Cisco on Nasdaq. He'll still be left with a lot of money agreed? So he further wants the remains of the proceeds to be disposed of as follows. So you understood this transaction that he wants. This looks like a pay from the bank and get a ticket kind of thing. So sell 12,000 shares here by 5,000, 10,000 there but he also wants the following to be done. His daughter studies in IIT Bombay so he wants to credit 50,000 rupees in her account in State Bank of India. His son is in New York and papa he has said give me some money and he wants to transfer $1,500 to his son's bank account. His wife suddenly announces that no no no I feel very uncomfortable with my daughter in Mumbai. I'm going to Mumbai so send me a whole lot of luggage and send me to Mumbai. So he has to book a wagon to transfer some of the household goods and we presume that by that time wagons can be booked online. He also wants to pay annual premium for a life policy at LIC Ludhiana. He also wants to pay a car policy premium for New India assurance in Delhi branch and if any amount still remains and I hope lot of it remains he wants to transfer it to a charitable trust to his alma mater. Naturally this Arun Deep Singh Pandu belongs to IIT Bombay so this is what he wants to do. There is nothing new in this by the way. High net worth individuals have been doing these kind of things for ages okay even five hundred years ago also people did that but people did each of these activities as a separate transaction. You sell shares in Mumbai you collect money from Mumbai. You send somebody to Berlin to buy those shares. You send a check to your daughter which she deposits in State Bank of India. That check goes back to the clearing to Ludhiana after one month she gets one. You want to book a wagon you send somebody to railway station get into haggle with that station master whatever then you book a wagon. So you did all of these things independent. What Anand Deep Singh Pandu is asking all of you is look that was old times but you guys are smart programmers. You understand modern technology. Please do something so that I can do all of this as a single transaction. After all the world has given me a single transaction the purchase of a railway ticket you're also permitting me to get a life insurance policy so permitting me to pay premium from my bank account so I can't you do all this. Realize that all of this requires integration of applications running at various places. Now suppose tomorrow netcorp comes to you and says that look I need your interface to pay the premium for one of my clients I'm not paying my premium for one of my clients through a transaction which I am going to control. Can you say no no no this is not permitted you have to enter data in this form and then only we'll take it. Then what if we do he will get go to Bajaj Allianz or somebody else. Five years ago he could have said okay I do it because there's nobody else doing it. So this is what the competition will force us to permit all of these and in fact to permit these proactively means we'll get more. But that's the business side look at the technology side that means that I must I do not know what other applications in the world would like to access me online I have to be prepared for it and in turn I have to be prepared to extract useful information from other applications which are written by others whom I do not know and which are running somewhere else. Not only that each of these applications could have an implication on my own activity which earlier I had not thought of for example imagine the netcorp has a customer relationship management system which has to automatically evaluate the portfolio net asset value of that Anand Deep Singh Pannu and is required to inform implications to Anand's car loan provided. He doesn't buy cars like you and I he would have a Mercedes high end or something like that and no rich person buys a car by paying money. They always take a loan from a bank to buy a car only the middle class people purchase things from one savings you know the rich people purchase things from future man anyway that's a separate philosophy however that Mercedes which cost let's say crore rupees has been given to Anand Deep Singh Pannu against that car loan because he's supposed to have this net network. Suppose he sells 10,000 shares of infosys and that's the only thing he had then he is not solvent anymore. Now that information has to be automatically updated by the netcorp internal system and that NAV has to be informed as a standing instruction to the car loan provider and preferably this should happen automatically online at least this is something which can happen tomorrow. Okay this guy will not fall down. Look at other implications look at the trust that IIT Bombay it has to execute a standing instruction to forward different percentages of the donation for identifying activities also copying the action to relevant professors and deeds. Let me explain why such a thing is necessary. Suppose I have a donation account and from that donation account I give scholarships to people I support research or whatever and let's say I had met Anand six months ago and I told him that look I have these five bright research scholars okay but they want some support because their parents are saying there's no fun in doing PhD at this miserable stipend you better do a job. So we have a scheme by which if external donor supports will give them as much scholarship as they get in salary outside. So would you please help me you'll ask me how much do you require is about sixty thousand sixty lakh rupees or something like that. So all right Fadak I don't have money now but whenever I get it I will give it to you and we forget that. Six months later when he executes this transaction okay he knows that he has transferred money to Bombay suppose he calls me in the night or whatever saying so Fadak are you happy now and suppose I have no clue about it what will I tell him depending upon whether I have had fights with my wife that day or not I will say I'm happy or I'm not happy but I will have no clue about when I tell him that I'm completely ignorant on what he is talking about do you think he will be interested in coming back to IIT Bombay in future. So what should IIT Bombay have? IIT Bombay should have a linkage that whenever that netcorp application running transfer the funds to IIT Bombay system the IIT Bombay system automatically executes some kind of a stored procedure or it triggers an event which says okay this is the money that has come out of these 2.5 crores which have come to IIT 60 lakhs are meant for Professor Fadak students it should send me an email it should send me an SMS what should that SMS contain not just information that Anand 60 lakhs are like it should say these are the five students who are eligible to receive the extra stipend and this is Anand's mobile number what is the purpose I should call Anand proactively and I should say Anand thank you he may not even realize because he's not sure his transaction has executed he will ask me why I said well you have done such a great thing 60 lakh rupees have come incidentally these are the five students who are going to be eternally indebted to you how how nice you will feel this kind of action and triggering of action has to happen with modern applications so when you talk of a multi-tier distributed application you are actually talking about ensuring not only seamless integration with external applications but ensuring a richer functionality within take this Alice's case there's a payment made in Lodhiana he's a high net worth individual probably buying a five crore policy is a huge chunk of premium that he has paid how long does it take for that information to come to your treasury today for investment decision today's 48 hours for 48 hours loss of interest on the investment how much is the money and sigma that 48 hours is a generic thing so it moves throughout the time interval so throughout the year you take the total sum that you have invested you are lost interest for two days on the total sum so humongous waste no foreign investment department of these multinational's permit that so typical what should be the mechanism the money comes there to close up is a whatever you have a filter saying anything about this whatever the system automatically calculates this money comes there the information doesn't go only for accounting purposes there is a filter which calculates that out of this premium so much money is investable and that information goes to the trading section in your treasury department in exactly five seconds flat so the money is invested on the same day this may not happen even tomorrow because this conceptualization is not happening even today so you realize how you have to prepare your application functionality for tomorrow by thinking ahead of time okay I hope you appreciate this point just an example but a very very real example the web services model forms the crux of system integration today the application integration and the background for these web services model is the normal services which are provided consider this I want to buy some sorry for my wife or furniture for home or a television or something like that how do I discover where these things are available typically I discover these through advertisement or by looking at yellow pages or by looking at notices okay who gives these advertisements who makes entries into yellow pages or who makes these notices the service providers who are the service provider those who sell the goods people who sell TVs advertise those who sell TVs advertise in yellow pages also so my my address shop address is this I put this this this kind of TV that's the first information about the service so I can know what is the contact point I can know what is the modus operandi what time to time that what morning to evening that fellow is available which day is holiday I know what the pricing is all the information related to that service I am discovering without talking to that person and I am discovering it through the announcements that has been made on the yellow pages or something what are yellow pages yellow pages are nothing but something like an intermediate broker you can think it is like a registry so imagine that all service providers or good providers are going to that registry and registering with them I sell TV I sell pins I sell whatever computers I sell televisions whatever one so they all register all the end users who want to use these services they don't go hunting around individual they go to the registry saying do you have any TV fellow do you have any this fellow do you have any this fellow if he is there how do I use that service if such a registry is extremely useful in conventional life why can't we build a model for interaction between applications around the same notion what is the notion the provider publishes in the directory and user subscribes to that direct I am subscriber of yellow pages so every time I'll get a number so publishing and subscribing are two fundamentally important thing somebody publishes others use users will subscribe the users now have a discovery mechanism so when the user discovers a service that user wants he will send a request to the provider and the services provided by the so please notice that the registry is not doing anything about execution of a transaction between the registry is providing information ultimately is the end user who goes to the provider as for service gets the sun if this model the simple and elegant model works so well across the world for many services why can't I use it for my actual application integration this is what has resulted into three standards which together comprise the backbone of service oriented architecture the first one is called UDDI or universal description discovery and integration UDDI is a new standard that has emerged it's a platform independent XML based registry for businesses worldwide to list themselves on the internet and this is designed specifically designed to manage business and service related information there's a taxonomy or a classification of the service just like you have yellow green and white pages you have yellow pages green pages white pages so UDDI now is emerging as a standard for registry of your applications what functionality applications have so imagine your cobalt programs in the front end okay publish or register in a registry saying I offer these services it is not sufficient to say I can collect premium I can print receipt or I can update this data for this customer it is also important to say how I do it that information is not directly available in the registry registry will only say this service is provided so you have another standard for that this is some more information about UDDI by the way there are public registries which are run by IBM Microsoft and X methods these are public registries are being closed down but private registries for use amongst a close user group so there are UDDI nodes across the world or you can have them across the organization these nodes excess and manipulate only UDDI data and each node has a set of application programmer interfaces so for any application I know how to register my service or my my program with that particular registry so this is basically for inter UDDI communication also there are API as a fairly advanced state now accepted as a standard word over we talked about service being registered but we also need to describe that service in which way my customer address could be changed in which way my payment transaction for premium could be received and updated this information I don't want him to call my cobalt program that I will do but what information is required for me to call that cobalt program and how he could invoke it without my personal intervention is to be described this description comes out of WSDL is another standard is actually web services description language so this is a service description language this is a XML description on how the service is created the service is described service is registered how the services discovered and how the service is invoked in fact you will use WSDL to prepare specification for creation of the service describing the service and registering it with UDDI also once you register with UDDI any user of that service will invoke that service using the description that you are given in the invocation how that user discovers is also described here fairly comprehensive standard and in a very mature state already typical XML elements of this WDL we have not discussed XML I presume that you will be familiar with it you are all familiar with HTML okay so HTML is about a markup language which describes how the how a document will appear on the screen XML or extended markup language is about semantics of what appears so in an HTML if some strings are there some picture is there some values are there the program is unaware of the significance of those values for example if somewhere you say Fartex policy premium 1,252 rupees 1,252 will appear as a number but HTML will not be able to understand that this is premium for policy XML goes one step further and describes the semantics of the contents of your document so is an extended markup language it has now become absolutely the medium of exchange of information between two disparate system in fact if I want to send some data to you and I have a cobalt program data you have completely different fox pro or database whatever whatever I actually take my data out convert it into XML send it to you once I give it in XML you are able to decipher which field means what and you are able to put it in the reformatted in the way that you want and use it so XML has become something like a middle where for data something like a middle where for data and XML is now further extended many schemas are defined using XML and so on so forth suffice it to say that web services description language is an important standard which has emerged which is used to do all of these okay so there are these are there are special XML elements even if you don't know the XML you can see what all WSDL permits you to define it can it can define types messages operations port is actually a notion in a network paradigm so you do programming for network that when you have to write something onto a server which is at a remote place you actually open a socket and socket has two ports this is a programming convention those of you have done network programming would know that but you can define port type you can define binding give the port number and give the service specific and it's an extensive set again there are very good textbooks actually available on this there's one very good book written by some researcher in the Infosys set labs in fact that book may be very nice for you to have let's see next course when we do you might want to have that book this is a book on web service and the example he gives is a large mainframe cobalt legacy application and how in that application web services have been used and described using these standards and how they can be connected to a completely different new front-end system