 So, the next part of this talk is basically going to focus on, you know, how is SOI actually come about? We have kind of seen one aspect of it so far, are there any other aspects that drive this, right? The way businesses have changed themselves fundamentally, for example, and then what is SOI? Let us take a look at that. So, what triggers change, right? Three times you are in a situation where a major paradigmatic shift takes place, you know, you went from procedural to object oriented, you went from monolithic to distributed, you know, those kinds of issues, they are all major shifts or changes that have taken place in the way that we do things, right? So, there are three things that, at least three things in my mind that trigger change, right? One is that there is something happening on the side out there that is strangely interesting to me as a business, right? So, example could be that I am a bookstore, I sell books, but the development of the internet is going to make me change the way that I sell books, right? I have had a bunch of stores across the country and these stores are really nice, they have coffee shops in them, you can go sit and read books and buy books and so on, but my sales have been flat in all these bookstores, right? The internet is taking off, people are all using the internet, so maybe can I take advantage of this new medium that people are talking about in order to accelerate my growth, increase sales, whatever, right? So, advancements in a technology that is parallel to what you are actually doing, right? A bookstore has nothing to do with the internet specifically, but today they are kind of linked so intricably that we can't even think about, well, we can, but a lot of people don't think about buying books by going to a store, they just go to Amazon and they go to whatever and buy books from there, right? So, that's one aspect of it. The other thing is that the business needs themselves are changing, it's becoming, we've come to a situation where, one, we have to be very, very agile as businesses, no matter how big you are, this notion of agility is being much talked about, is being much doubted, right? You have to be agile, you have to be able to respond to change very quickly, there's a lot of competition out there, every time the competition releases something, you have to release two new features for every feature they release and for every one of the two new features you release, they release four new features and it's just, this thing is happening all the time. So, there's one, the business, the pace of business is changed, right? I think we understand that and the other thing that is happening is that businesses are becoming more collaborative in nature. It's not possible for one business to do everything, no matter how big you are, right? eBay and Amazon are really big, forget eBay, let's take Amazon, Amazon is quite big, right? As a company, I don't know what its exact turnover is, but should be in several billions of dollars, is what I expect, right? But Amazon cannot control a logistics company like FedEx or UPS, it would be foolish to, for Amazon to buy a logistics company, but Amazon desperately needs logistics, everything that people buy has to be shipped to them, it's a physical thing eventually, right? I buy a CD, I buy a book, I buy a stereo system, whatever that has to actually come to me, right? How will it come to me? Some courier service is now going to get involved, now will Amazon buy the courier service? Probably not, it's a waste of time to own and maintain and operate a courier service, let the courier service do its job, I will hire the courier service in other words, right? As a company, so it means I have to collaborate with this courier service, wherever that may be located, right? Same thing is true for credit card company, so will Amazon own a financing institution? No, no way, right? Visa is a financing institution, master card is a financing institution, I'll go there, let them do the credit card processing handling for me, right? I will use them, so I'm going to collaborate with yet another person, so things are becoming much more collaborative in nature, this is not the way businesses were functioning 20 years ago, businesses are fairly self-contained, the large ones at least, but it's not true anymore, so that's what I mean by changing business needs, right? Finally, when we look at these two things, the first two bullets out here, I will realize that my current technologies are not going to cut it at some point in time, right? A quick example would be that I'm, well actually let's go to the next slide, that's stealing the thunder for my next slide. So let's take the first one of, first of these three bullets, right? So on, we said that advancements in a parallel but related technology can drive a change, what do we mean by that? Right, take a look at connectivity or networking, communication infrastructure that has existed over the last 10 years. The change in this that has happened over the last 10 years, right? Initially, we saw that, initially we had the lands, so we had a very constrained operating space, we had the local area networks within companies, information availability was very local, right? It was maybe within an enterprise boundary, the enterprise itself possibly was physically located at one place, it wasn't spread all over the place, maybe a few offices here and there, business processes were definitely very local, right? It, the business process were confined to my own company, so if I did order management, I would do the end-all of order management myself, right? Now, as things changed, we went to internets but wide area networks, it's still internets within the enterprise boundary logically, but they're wide area networks. Now, I opened offices in Delhi, in Boston and whatever, three or four cities, Minsk in Russia and so on, but they're all still belonging to my company, and business process flowed in between this, but things started getting a little more global in nature, right? That was the next step. The internet kind of really took off somewhere at this point, you know it has been existing long before that. Then the next logical step was what we talked about just before this, which was businesses became much more global in nature, much more collaborative in nature, information availability was global, so I can sit here and for example, access from a research perspective, I can access all the research papers that are published anywhere in the world. I don't actually have to be present at these conferences, right, physically, everything's available online, the e-versions of IEEE and ACM and all of these research organizations exist, and I can sit here in my office and I can access all the papers. That was not true even 10 years ago, right? Even 10 years ago, I had to wait for the hard copy, paper copies for it to arrive by mail, which often took six months to show up after the conference was over. It's not true today, conference is over, the next day I'm able to access all these papers over the web, right? So, same thing with business process, they started becoming more global because of the collaborative nature of business, and my business process itself, which was previously confined to my enterprise boundary, crossed that and started hitting other enterprises as well along the way. So, just my order fulfillment process within a company like Amazon will probably hit my own company first, which is inventory, right, that I maintain. Inventory of what I have I maintain, right? Once I have the inventory, I go to credit verification, somebody else does it, I have crossed my enterprise boundary already, right? Credit verification checks comes back to be positive, I have to contact logistics, have them ship it, tell them which warehouse to go to and pick up the item that somebody has bought and deliver it to a particular shipping address. Get confirmation that you have shipped it and they have received it, send that confirmation back to me, right? That is my order fulfillment process within Amazon today. It's clearly crossing three or four enterprises already, right? And they are much more complex ones which involve manufacturing and so on at this point in time. So, a lot of on demand manufacturing that is going on today, right? Which will involve procurement of raw material and so on. So, the point that is being made is that business processes are much more global in nature, right? Along with this, so I'm going to use the internet, right? For this, because it seems like I don't want to be keeping private networks, it doesn't make sense because that was the initial, initially that's what people were doing, right? So if I collaborated with FedEx and if I collaborated with somebody, I would have a VPN set up between these people. It would be a secure private network for which I transacted business, right? But that's too expensive to do, right? Every time I change a vendor, I tell down a node of my private network, I have to bring another connection to a new vendor. They're really painful things, but the internet is ubiquitous. Everybody is connected to the internet. So let me use the internet for business, right? Great. But there is a problem, right? The problem is that the current software that I have is not built to take advantage of the internet or is going to suffer problems when it runs over the internet. Classic problem is one of latency, right? Now, if I operate a J2EE application or a Corba application or whatever application, Tuxedo application, within my enterprise boundary, it is built to run on the LAN where the latency is of the order of a few milliseconds at most. Even a WAN where the latency maybe of the order of maybe 50, 60, 70, 80 milliseconds. On the internet, what is the latency? It could be anything. It's unbounded. The internet actually crosses several different ISPs. It all depends on how the ISPs are performing, how much load there is on the internet at any given point in time. This is not a controlled network. Remember, it's a public network, right? So I have no guarantee of what the latency is going to look like. In the best case scenario, maybe I'll get a few hundred milliseconds, which is fine, right? So this means that my application, for example, that was built to run in a synchronous request reply manner is not going to work very well. I cannot do synchronous request reply over the internet because if I send a request, every request is going to time off unless I set my time-out value to be in the order of several seconds, which is not the right thing to be done, right? So the inescapable, as I call them, of the internet will force to change the kinds of infrastructure that I have to work over this new medium, if you will. Right? So I have today's technology counter for this. My answer is no. Otherwise, there won't be anything else to do, right? Then there are several other issues. We don't have to go through these seven things specifically, but there's several issues. In a VPN, I probably have gigabit connectivity, not true on the internet because my connection to the ISP is a choke point and there's going to be limited connectivity. So I can't push, for example, huge amounts of GIF files, just in that, as part of my B2B process, I probably have to change my applications to work with textual data rather than with binary data. All of these issues come into play, right? So the next one, businesses have changed. We already talked about this notion of agility, right? Everybody today is talking, every CIO that you talk to today will talk about agility. This is the hot buzzword among CIOs today. Six months ago, I attended a CIO's meet at the Computer Society of India hosts. I think various places, I'm not sure, but certainly there was one in Bombay six months ago and there were like about 75 CIOs of various companies in India would come there. Almost every one of them was talking about this notion of, I am being forced by the business to become more agile. So the CIO is not in a position where they can say, some part of the business comes and asks for some features, they can't say, okay, hold on and wait for a while. I'll get you up to speed on this. No, none of them work, right? The CIO actually has to be a business enabler and they have to be leading the way the business goes. Not, they cannot be behind the rest of the business, right? So this is the notion of agility. Basically, agility is nothing but how fast can it change the software? That's all there is to it, right? If I will give a new set of requirements or if I'm going to be doing a new service, so this is a classic problem in telecom today. So take these cell phone providers. Every few months, you are getting new features on your cell phone, right? Call forwarding this thing, that thing, then they'll give video on it, then you can watch a cricket match on it. Something or the other is coming out on these cell phones all the time, something new, right? Which means the software has to be changing constantly to allow all these things to happen. It is no human feeding you cricket match, this thing, right? So this is a real issue and a survey shows that most CIOs are not very well prepared to deal with this, with the current infrastructure. Why? Because of two things. One is even though the object orientation was supposed to have enabled a lot of reuse, the fact that we have to integrate these different components and write a lot of glue core has caused the problem. It has in fact hampered reuse. And if you take a look at, this is another survey that would be interesting to conduct, right? How much reuse are you actually doing in any applications that you're building today? As an ITR. What percentage of an application is from reuse? What percentage have you built newly? The answer turns out to be actually startlingly bad, right? People are talking about a maximum of between 11 and 20% application being reused, 80% being built from scratch every time. In spite of the fact that object orientation and component oriented software was supposed to have alleviated this problem. It has not. Because of the fact that you have to sit and integrate all this, and that's a pain in the neck. So rather than try to integrate software that is new to me and learn new APIs, I'll build my own stuff. It's the standard answer that you'll get back from a lot of engineers, right? So what we really want to be doing instead of this is we want to be able to have software be running wherever it is running, right? And coordinate the running services that are provided by these different providers, as opposed to getting the software in houses components and sitting and integrating them ourselves. That's the point that I'm trying to make here, right? So integrating rather than coordinating. So what's broken in the current software? So we have this notion of tight coupling, right? Which is really what we don't want. What I mean by tight coupling would be if I use a particular component, for example, the API of that component, there is no standard for it. Let's say there's a PO component in a company, right? Then maybe some bunch of PO components purchase order is what PO stands for that are out there and I buy one of this PO components from some vendor, integrate it. It has some specific vendor proprietary API, right? I integrate it and now I'm tightly coupled to this particular component because I've written to a very specific API on this component. What I really want to be doing is to give a general description of what I want the PO to look like, right? What do you require of a purchase order functionality? It has to have some line items. It has to have some cost, right? You will be running across this all the time. And then I say that any component that satisfies these requirements call it at runtime, right? I don't want to hardwire this which tightly couples me to it, right? Into my application. This is one example of tight coupling. Therefore, if you tightly calculate these applications don't become adaptive in nature, right? So in other words, if I want a different vendors purchase order component, I now have to bring the new component in house, test it, learn the API, put out all the blue code that I've written earlier to call the old component and rewrite code to call the new component, right? That's not adaptive software, right? The human is getting involved in the loop all the time. We don't want that. As far as possible, what we want is, suppose I am using the service of a particular vendor, right? The service is something that is running. Let's say a software that is running somewhere and I'm calling this person through, so standardized API, right? A standard way of discovering its capability and calling it. And if that vendor goes away, let's say they go out of business and there's a new vendor that comes up who provides similar functionality. I should be able to discover that and use it without having to write a whole new code. That's what it comes down to, right? That's adaptiveness. Sir, here business process is re-engineering in the standardization, we have seen in the government that even at the national wide project, if we go to the states, the states requirements are a bit different. They won't want to know what we're doing. So we have to change the whole lot of processes and to make the application learn better. Right, that's true. So I think that's one of the points that I've tried to make here is that what we want in this case is we want the business process not to be embedded, but we want it to be externalized, right? That's one aspect of it, is that we want business processes to be explicitly described in some notation that captures this that is analyst friendly as opposed to having to need a whole army of software engineers to change the business process every time. If it is embedded or built into the rest of the software, there would be an issue with this. Sir, what can we do with the performance of it? I think the problem is for the particular application. For the generalization. So it needs to couple it directly. Yes, I agree with that. I think the more specialized you make a certain application the more performance you can actually bring out of it. Right, so it's like saying, I'll write high level code versus assembly code. It's a very similar notion, right? Assembly code is written for a specific processor in mind. Remember, as opposed to writing code in Java or C or C++. So if I write code for a specific processor, I'm likely to do a really good job of it compared to a compiler who will generally be able to translate a whole lot of things for any processor. So if I have a C compiler on Spark systems, I have a C compiler on Pentium systems, I have a C compiler on whatever the Mac processor has got. Itanium and so on and so forth, right? Now, so it's the same notion. So if I make it very general in nature, you may suffer a performance hit. That's the intuitive notion that you will suffer a performance hit on us, right? We have to see how to address that. Yes, that is an issue, right? In fact, that is one of the single biggest issues that people are complaining about for web services today. Okay, so we'll go pretty quickly. Close not necessarily, but so if you use open systems, standard-based systems, it's okay. So the closed issue may or may not come into play. Right, so the one issue that we do have is that this level of IT abstraction that I call. What is the level of IT abstraction? Is that, so suppose there's a marketing, the chief marketing officer comes to the CIO and says, hey, I want to launch a new promotion campaign. These are the kind of services that we want to provide as part of the new promotion campaign. So please change your software to launch this promotion campaign. Now the CIO is thinking in terms of, I have portal, I have a billing application, I have some inventory application, I have that application, I have this application. He doesn't talk in terms of this notion of services that the company wants to offer. The company wants to offer telecom services. I want to offer call reading to my customers. I want to offer voice mailbox to my customers. I want to offer any kind of services, video on demand, ringtone downloading, whatever to my customers. But the CIO is talking a whole different language. He's talking of some application I have, it has some interfaces. Now the rest of the company cannot understand what the heck this application is and what, they don't even care about it, right? So the question is, can we bridge this gap somehow? Can we talk about the notion of services all through right from the business executives in the company through to the actual software that is executing somewhere on the network? So that's what I mean by a level of IT abstraction. It's a very different language that is talked by the CIO and the IT people versus the CXOs and the rest of the businesses in the company. So here's my five point conjecture, having seen all this. And if you, this is a place where we can have a small discussion if you will. Because I think these are again points that I have made having looked at whatever I have seen so far, right? So this, I don't think there's too much doubt about. Businesses have become more global and have become more collaborative in nature, right? There's no question about that. The internet as a medium for doing business is here to stay. We are not gonna have private networks all over the place anymore. So the age of the VPN still exists if you want highly secure, highly performance guaranteed, no variability in my connectivity type of scenarios, you will have a VPN, no problem. But how many people can afford that is the question, right? The internet is ubiquitous. It is connected to everybody out there. So if I want to collaborate with somebody in Timbuktu, it's very likely that that person has an internet connection. To set up a VPN to this person will probably take you months and you may not have months, right? So that's one point. Then businesses have come to the point where they are going to push this notion of flexibility to its limit. And this is only going to get worse and worse. It's not gonna get any better for us, right? It's time that we quit complaining about how I have to develop so many features in such a short time and try to figure out ways to solve this, right? So whatever existing technologies and methods that we have today, business automation, built with distributed object infrastructures and so on are not going to be able to keep pace with these four, these three other points that we have made earlier, right? So there is a problem there. And finally, the cost of an own and operate approach is not scalable, absolutely not scalable. I will not be able to build and forget build. I will not be able to own and run every piece of software that I will possibly need eventually. And we have to move to a model in which there is sharing of software services amongst multiple consumers, thereby amortizing the costs of some of these expensive service offerings amongst many people. We have to do that. There's no choice, right? And it's not just the cost, but it's also the headache of running everything yourself, right? So this is what service orientation is all about. These challenges that we have just described, right? It is about emphasizing the notion of loose coupling, right? We don't want to be tightly coupled to a specific API, to a specific vendor, to a specific piece of software, to a specific package, right? We want to be loosely coupled. We want to have the freedom to move from component to component. We want to have the freedom to move from vendor to vendor, eventually, right? So it results in flexible business automation, lower cost of maintenance. And it solves those three issues that we talked about earlier, cost of operation and maintenance, and lower time to market. So that we'll see how, but this is the emphasis, right? So web services are nothing but an instantiation of some of the concepts that service orientation puts into play. Service orientation is a concept, right? So it's a way of building applications. It's an architectural style, if you will. So web services give you a specific API to try and realize that. So it's an instantiation. It's something concrete that you can get your hands on. Additionally, web services are built to take advantage of the internet, specifically internet protocols, right? HTTP, XML, things like that. Okay, so what are services? If we think about service oriented architecture as being architectural style that drives loose coupling, now we have to talk about it's service oriented, so what is a service? So first of all, it's like an interface, right? You think of interfaces in object oriented terms. Interfaces as opposed to the implementation, right? So a service is like an interface, an abstract view of a program, right? It's how can I talk to this program, really? What does it do for me, right? It could be an abstract view of data also. So there could be a data service which actually abstracts a database and gives you data services, things like that. And this is defined in terms of five things, right? So it's defined in terms of what does it do functionality? So an interface will actually describe how can you talk to it only in object oriented terms, right? So if you take a look at a Java interface, what does it say? It just says here are methods within a class. The class is named so and so. Each method is named this. It takes these input parameters and gives you back this output parameter. How do I talk to it? That's what it is. How can it be contacted and invoked? It doesn't describe what it does, unfortunately, right? You have to just gain it from knowing or having some documentation about the class itself, right? So that documentation also should be described as part of the service is what we are saying. What it does? How can it be contacted and invoked, right? Any SLAs it can offer, you know, quality of service guarantees that it can offer. What does it cost? Given this cost of the different levels, gold, silver, bronze type invocations that you can do on this. Now that's one aspect of it. And finally, whatever resources that the service itself needs to execute. This is no concern to the client, but what are the resources the service needs to execute? So different characteristics of services. This is important because eventually this is at the heart of when we say what's a good service versus a bad service, you know, this would be what will be used to measure it finally in some way, right? So it has to have a course-grain interface. What do we mean by that? Course-grain is a larger granularity of the interface. So an example may be the current operations, right? So the create, delete, modify type of operations on larger objects, let's say order. Create an order, right? Or actually fulfill an order. Maybe the example of a service. As opposed to change this particular value, change one more value, get one value, read one value. That's not a service, right? That's what we mean by course-grain. It has a standardized interface, right? All implementations of this, no matter what, will conform to this interface that looks exactly like this. It's the notion of standardized, right? The service is self-contained. There is no dependency of the service on that the client would have to be worried about. There are certainly maybe dependencies in the back end, but the client will not be worried about. There are no visible dependencies. That's what we mean by visible, right? So when I call a service, suppose I call a travel reservation service, right? I call it travel agent. The travel agent has put up a travel reservation service. Travel reservation service, my intern have to contact airlines. It may have to contact car rental agencies and all that. I don't care about that as a client. You contact whomever you want. As long as you are advertising the fact that you will make airline bookings and hotel bookings and car bookings, that's all I care about, right? The service is typically always available to me, right? So this is like a seven by 24 notion. It's there until request come, right? And whenever the request comes, it processes the request and serves it. So the service can be offered with different levels of quality for different people. So it's provisionable in different ways, right? So for example, I may say that I have a set of customers who are paying much more than everybody else. So they have to be given a higher priority. So I'm going to provision the service such that customers who log in with some particular gold rating will receive a higher quality of service than people who log in with other ratings than gold. So it is probably the same service, right? The same service of airline reservations. It's like frequent flyers. So if you're a platinum member of Jet Airways frequent flyer program, right? And if you log in and you make a reservation, it should really be able to treat you like a platinum member automatically. So it's provisionable. The same service of reservation. Everybody is making a airline reservation. As if you fly business class or economy class, whether you fly, whether you're a platinum member or whether you're not a member, you're still making a reservation. You're still going to get a seat on the plane. The plane is going to go from one place to another. It doesn't matter. But the service quality is different, right? So that's what it means. There is no notion of integration. I don't have to write glue code in order to use this service. I will be able to call it because it is already running somewhere. I don't have to deploy it myself because it is deployed somewhere, right? That's the next point. So no integration as such would be required. I have to certainly call it. No question about that, right? If you don't call it, you're not going to get any results, so. But there is no integration of glue code that would be needed to be written in order to invoke this, right? Now existing services can be combined to create better value. A classic example again is the travel reservation service. Travel agent does what? Basically what they do is they themselves don't run an airline. They don't run a hotel. They don't run a car agency, nothing, right? What they do is they intern contact other service providers and they will club everything into a nice package, add some value to the fact that they're doing both hotel reservations and airline reservations and give you one nice printout that says, okay, here's your flight, here's your hotel, everything. You can just take that and run with it, right? So that's what we mean by value can be created by combining existing services, right? And finally, the quality of service is in some way quantifiable. So in other words, you can say that a response time of the 90th percentile response time of 10 milliseconds or less or half a second or less on some service. What that means is that 90% of the requests that are sent to this service will have a return value in less than so many milliseconds or seconds, right? So it is quantifiable. So what this allows is that because it has a standardized interface, right? All travel reservations do the same thing. Let's face it, right? Every travel agency does the same thing. How they compete is actually and how well they serve you, right? Do, does it require for me to keep calling this travel agent over and over again before I can get it done? Is he very responsive to my needs and will do it and will call me back automatically all the time? This is what differentiates one travel agent from another travel agent. Not the fact that it's likely that everybody will do airline reservations, everybody will do auto reservations, everybody will get your car, whatever, right? So that's a high likelihood. So that's what we mean by standardized interface, but they end up competing on quality of service eventually, right? This is what is readily amenable to a service. If a person is only, if there's only one vendor who's going to provide that then it doesn't become a service for us. It doesn't make sense because they can create whatever proprietary interface they want for it and you have to use them. So there's no choice on that matter. What we want is something that can be provided by multiple vendors. They all provide the same functionality but they compete on quality of service, right? That way there's a standardized interface that can be created for that. Now services are actually offered by providers, right? This is just like anything else that you buy in the market, right? Travel services, whatever other kind of services, even plumbing services for example, right? Different plumbers will advertise themselves saying I'm an electrician, I'm a plumber, I provide this service for you and then that is the offer that they are making, right? And consumers will express intent. Now what am I looking for? I am looking for a service that will create tax returns for me for the financial year, whatever, 2007, 2008 according to some particular tax law. I am a business with so much of turnover. That's my intent. I'm looking for what is the intent that I actually express and then there will have to be some mediator, some middleman who will look at what's out there, what are you asking for and if something out there be able to provide what you're asking for and if so, I will match your request to this person's offer and give that return that service back to you, right? These are what are called matchmaking services, right? So request response is a very particular case in the sense that you already know whom to contact, you already know which service provider it is and you go directly to that service provider and ask for him and come back, right? Now every time you want to accomplish something, let's say you want to go see a cinema, how would you do it? If you want to go see a movie, you will probably do a search for the movie and the area in which you live to say which theaters are running this particular movie, right? That's one way of doing it, right? And then it will come back to the list of theaters that are running show timings, prizes, whatever, availability and based on that, you'll select something and you'll go for it. Another way of doing it is to say, I want to go to this theater only to see this particular movie. If it is running, I'll go there. So I'll first contact that theater and if it is there, I'll go there. So this is the notion of a white pages search. I will go to a specific person first. I know that person's name, give me the phone number of the person. That's a white pages way of finding out services, right? I want a specific service provider. How and where do I contact this person? So first of all, I need some kind of a directory where I advertise the services and where I can find services from, right? Just like you have the notion of a phone directory to find people. You have the notion of a directory to find services. So service directory. This can be organized along many different ways. It can be organized as white pages. It can be organized as yellow pages. It can be organized as something called green pages that we'll see a little later in the course as well, right? But the notion is that there is a place out there, logical place. It's not a physical location. There's a place out there where the service providers can advertise themselves and service consumers can go search and say, I'm looking for the service. Can you find this for me, right? So that's what we mean. So the notion of service orientation is not similar to request reply. So we are not going to send a request and hang out there waiting till we get a reply back. Instead, it is based on message orientation. I send off a message. It may encapsulate a request. It probably doesn't encapsulate a request. And then I'm going to go off and do whatever it is that I have to do till the reply arrives as another message that I will end up processing. There are like two separate one-way messages as opposed to a synchronous request reply, you know, two messages being tied to one another very tightly. That's the notion of message orientation, right? So every service actually advertises what are the messages it can understand? That is my WSDL description in web services, effectively, right? I advertise what are the messages I can understand? So I may be able to understand the message that says, do you have the temperature of a particular city whom I'm going to give to you as the input? Current temperature. It's a weather service that a weather bureau is providing. And that may have many different messages. This may be a temperature message and maybe a rainfall message. You know, what are the chances of rain? It may be different kinds of messages that you can understand. So that's what it... In fact, the advertisement is a set of messages that it is willing to accept, right? And a set of messages that it will return back, right? Clearly, in order to find services, I have to be able to describe services in the first place. So there's an orientation towards description. Now your classic interface, your class, if you will, in object-oriented terms, is also a description. It's a syntactic description, right? Syntactic description of how can I invoke an object of this class? Basically, what are the methods that it has? What are the signatures of the methods, right? Now, a description orientation can go beyond that. Can I describe semantics? Can I even give an English language description of what this service does associated with that? That's a minimum. The more formal descriptions would be something that will use a language called OLS to describe the semantics of the service itself, right? And this description that I put out there has to be machine-processable. In other words, it has to be formal in some way. It has to be structured in some way. Therefore, I need a language to be able to do this description, which is different from the language of the implementation of the service, possible. It's like IDL for Korba, right? IDL is an interface definition language, an interface description language, where I provide a description of what is it that I am able to do for you, and somebody is able to search based on that particular description, right? And finally, we want platform neutrality. It doesn't matter, you know, whether I'm on Windows, whether I'm on this, whether I'm running SAP, doesn't, all of this should not matter eventually. Otherwise, how can I search for services? If the search becomes too specific, then it becomes very painful to do the search. The number of parameters involved in the search become too many, right? So give me a tax service that is running on an SAP platform. Why the heck would I care? It doesn't matter what platforms it runs on. As long as you're able to calculate tax returns, that's all I care about, right? So it should be delivered in some kind of a platform neutral way eventually. So what is required in order to accomplish this? Now, are there any questions about, you know, what is the notion of a service? Because it's kind of important that we get that as we go along, right? So the standard things like, what do we say? If you're going to get and set values, very often when you write a class in object-oriented terms, there are all these get and set methods, if that we write. Those are not service methods. It doesn't make sense to expose it as a service, right? Mainly because of latency issues, right? Typically, the service is going to be hit over a network. There is going to be a significant amount of network latency that is going to come into play. Why would I want to expose an operation that is going to last 10 microseconds, where it will take me 10 to 100 of my milliseconds to actually access this operation? It would make no sense. That is why we want the notion of course-grained standardized descriptions to fit into this notion of a service, one, and that there should be many possible providers of a standardized description. That's critical because then we can actually program in a way that is independent of the specific provider, right? So that gives me the flexibility of changing providers. If there is another service provided tomorrow, that standardized description will continue to work for me. That is the notion, right? So what is required in order to actually accomplish this? You need a way of description, right? You need a way of finding these services, discovery, and how do I select? If it comes back with 100 different providers, how do I specify which service to select in this? Finally, having selected a service, how do I engage with it? Do I negotiate directly with the service provider? All this is being done machine to machine. Remember, at the end of the day, it's not a human-to-machine interaction that is taking place. It's not like I'm sitting there and doing a search in a browser. It comes back. I am making decisions in real time. This decision-making process is coded. It's embedded in some way, in code, right? And there's machine to machine communication that's going on. And finally, I should be able to string a bunch of services together. So this collaboration should be possible. This travel agent is a classic example, right? I will call the airline reservation service. I will call the hotel reservation service, but I offer a service myself. But I'm going to entree to it that these other independent services collaborate with each other, right? But finally, there has to be an emphasis on semantics. So this is some of the details of description and so on. We don't necessarily have to go through this now, but the key is that it has to be formally stated. All of this description, which is why we use some kind of a structured language to state a description, right? You need a description language of some kind, which is what your web services description language or WSDLS. It is nothing but an XML variant in this particular case. It doesn't have to be, right? It can be something that is unambiguous and formal. That's what we need, right? So discovery and selection is matchmaking, right? So given that there are many services out there which may satisfy this particular description, how do I pick the services that do satisfy this intent that I have expressed as a consumer, right? There are many different architectures for discovery and selection. What we'll study about in a web services context is a directory service called UDDI, which is a standardized specification for web services specifically to be advertised. It finally architecture. So architecture involves, I mean engagement involves many different aspects to it. Can I negotiate the terms of use of the service? Could be one aspect of it. Second aspect of it, what is the protocol that the service actually accepts, right? So maybe the service will accept messages in an email form. This is fine, right? I will send my request through email to this particular service. Maybe the service provider will accept messages only as HTTP messages. So what is the protocol, right? How do I talk to this person? Is something that I need to know. It's like to give an analogy to your day-to-day life, like I have to find the phone number of some provider which is where do I contact the service? Once I contact the service provider, suppose I'm looking for somebody who will deliver flowers in Delhi, I'm sitting here in Bombay, somebody who will deliver flowers in Delhi, right? So I put out this search, some tens of providers comes back. I will finally pick one provider based on some requirements that I've put forward. Then I have to call that provider. The phone number is written. That's the address of where the provider can be contacted, right? Then I call the provider and then I have to know how to talk to this person. What is it, what kind of orders will he take? Will he take orders below 100 rupees? Will he only take orders, 1000 rupees and above? Will he deliver to any part of Delhi? Will he only deliver to some part of Delhi? All this has to now be negotiated and finally I will place an order. Will he take credit cards? We'll have to send him a DD or a check, right? So this is stuff that I, that's a protocol of how do I talk to this person? What are the messages that he will accept? And finally collaboration. We will look into this in much more detail when we study something called business process execution language or BPEL, which is our way of describing collaboration amongst multiple services, tying them together into a workflow or a business process, right? So this is my eventual vision or scenario, right? I will describe my semantics. I'm a client, let's say. I will describe the semantics or whatever it is that I'm looking for, this flower, florist in Delhi, for example, right? Or a travel agent who is going to serve sub-Saharan Africa. I want to make a trip to the desert, something like that, right? So somehow I'm able to discover a provider of this need dynamically, right? I don't know beforehand who is going to provide this but I will do a search, find a provider of this particular need and then I will hook up with him dynamically, understand the protocol that I have to talk to this person, what are the messages he accepts, what are the constraints, et cetera, and then use that service, negotiate the terms of use and then once I started using the service, suppose I'm not satisfied with this person, I have to be able to switch in a very seamless way without changing a whole lot of things, right? That's the notion. Now, our typical comparison point is where we ended our historical perspective, right? So distributed component architectures is where we ended the historical perspective. We said that's the current state of the art and that's the distributed component architecture, right? So that's the current state of the art. So if we just want to do a quick comparison, there the main driver is transparency to the developer. The distribution is hidden, it is made transparent to the developer. So I can access a local object exactly like I would access a remote object. I don't, from a client perspective, I don't even know the difference that I'm accessing object that is local versus remote, right? Because there is something called a stub. Interface, stub, that is a class that is provided in the client side. And it looks like I'm accessing an object that is, which has the same interface as that of the remote object. So that's the objective there. And so it is a very different objective, fine grained interaction is okay because you're on a land environment with very high network speeds. And so even to, even there you may want to avoid it, but chat interaction is okay to have. And in fact, a lot of times you do have it. And the type system is shared across these different environments, right? Typically, even if you use Korba, IDL has a type system that is described for Korba. And that serves as the canonical type system that is common to these two sites, the client side and the server side. That's not true here. So this object actually ignores this notion of a network. We already discussed this with respect to the internet, right? So the latency on the network, especially the internet. And it's typically synchronous request reply, distributed component architectures are synchronous request reply in nature. Although it can be used with message queuing systems, it has been used with a TIPCO or with MQ series to try and ensure that disconnected servers or clients can still be handed, right? There is no shared memory. This we've already seen. There's some quotes that I've put out here. Which is, I'll let you read this rather than me going through this. The second quote is particularly important. I think that is actually the birth of a lot of service orientation came from Jim Waldo's work at Sun, where they worked on the system called Ginny, which was actually a early precursor of service orientation. And Ginny actually came out in maybe the late 90s, early 2000 timeframe. And they realized that objects over a large network such as the internet have to be treated fundamentally differently than objects that may sit on a LAN environment. And your programming models have to be different for that. And they're in kind of started this whole thing. Werner Vogels is the CIO of Amazon, by the way. CIO or CTO, whatever. So the shift in thinking is that when you go from a distributed component architecture to a service-oriented architecture, you go from being function-oriented to coordination-oriented. So you're not calling specific functions. You're calling services and you're able to collaborate amongst these different services. Typically, we'd like to build software that will last for a long time. That's not true in today's world. We want to build software that will change very quickly because the change dimension is upon us and we cannot help that. And that we cannot build large pieces of software and prolonged development cycles no longer exist. The very short cycles, incremental development is the way that things are done today. All right. And we go from tightly coupled architectures to more loosely coupled architectures. We go, so this is going from the left side kind of represents today's distributed component architectures, either with RPC or with objects and the right side represents more service orientation. That's the notion here. And you go from synchronous request-reply call-oriented, that's what I mean by call-oriented. Synchronous request-reply to more message-oriented, asynchronous call-back type of patterns. And we'll see how that works when you actually build an example by hand. And you go from interfaces to more description of abstractions that are semantically richer than what you're used to today with components where it's a syntactically rich description which is not semantically oriented. So summarizing this section, I think distributed objects and distributed components, component architectures and containers are where we stand today. I think most of you agree with that? Is there any disagreement? I think lots of enterprises are building applications, more applications with these technologies. They're also wrapping a lot of legacy applications to work with these technologies because even if they have legacy, what happens is that new development takes place in these newer technologies such as J2E or whatever. And the old systems that they had, legacy systems that they had is typically wrapped so that they can interact with the rest of the system that is being built today. And service orientation does specifically address certain needs, cost of operations and maintenance types of needs, lowering the cost of production deployment because I'm not gonna deploy everything in-house. I'm going to actually use services that are deployed elsewhere now. Classic case being Salesforce.com types of systems, HR systems that are not deployed in-house anymore. They're deployed somewhere else. In fact, entire HR departments are being outsourced to somebody else. I don't even run a HR department in a company anymore. It'll oftentimes, the HR itself is outsourced as a function from the company. So this is a very similar analogy that we can use with respect to the, the computational aspect of it. So the HR system is outsourced. The HR function may remain in-house in this case. Right? Suppose as you have told that HR services then change. This particular service is very popular. Then say many consumers have them. Right. So say instead of distributing, we are centralizing this particular thing. Okay, many, many consumers are using the same services. Logically, yes. Then say problem of load sharing complex. So this is a logical sharing. It doesn't mean that there is, first of all, what we are saying is that HR services are being outsourced. Doesn't mean there is only one provider of HR services. There are many providers of HR services. So. I assume that one provider. There is only one provider. Okay. And say it is a very popular service due to the. Fine. Yes. Fine. The way they provide. So that is, again, so logically you're centralizing. You're correct. Logically, everybody is going to this service provider. Physically, how it is actually set up systems-wise would be very different. It could have many different data centers spread across the country. So suppose you're on the east coast of the country. You might be served out of Calcutta. You might have the west coast of the country. You may be served out of Bombay. So your request may be directed depending on. Hmm? Again, it is a distributed. Yeah. This has nothing to, so this is a conceptual thing. This notion of centralization here is conceptual. That's why I'm saying it's logically centralized. Right. Maybe it is absolutely not. You still have to be able to scale. You have to be able to serve more and more customers. So physically, what will happen is, even if it is located at one place, you probably have a cluster of some kind. Right? Standard IT architectures today are what? There is a web server cluster in the front end with the load balancers sticking in the front. Then there is an app server cluster in the middle tier. Again, with the load balancers in the middle. Then there are parallel databases or there is a centralized database. The three tier problem is still there. Yes, yes. In the three tier problem, load balancing and complexities, all these things is on the server side. That's right. That's right. It is still there. It is still there, but now what is happening is, suppose I am a company. Let's say I am reliance. Right? Now I have two choices. One is I can buy all this HR software and run it in-house. Right? My HR function is completely in-house. That means I have to deploy all these three tier systems in-house, deal with the complexity of that, management complexity, headaches, whatever. Or I can outsource the HR functionality in terms of systems functionality to a HR provider who will provide me with a B2B link that I can hook up my other systems to directly. Now all of that complexity is outsourced to somebody else. Right? So the complexity is getting spread. It is getting distributed amongst multiple providers as opposed to one provider centralizing all that complexity. Right? So that HR provider now is dealing with only the headache of HR. He's not dealing with inventory headaches. He's not dealing with order management headaches. He's not dealing with production scheduling headaches. Nothing. I reliance had to worry about it. Right? But that's why I am trying to reduce my own complexity by pushing the HR function out to somebody else. They will deal with that part of the complexity. It gets amortized over multiple places. That's the notion. Does that answer your question? OK.