 So now we'll talk about web services which is a more specific instantiation. When we talk about SOA, we are talking of general concepts. This is where the rubber meets the road, as they say. There's a phrase that is used to say that you have to have something concrete. Don't just keep talking of stuff in the air. Okay, so the notion is that HTML and browsers have now existed for a while. Last decade or so it's become really popular. And they are meant for applications, humans to interact with applications. Every time you go to an e-commerce site, at the other end there is an application. But here you are sitting as a human and ordering something from that site. You are interacting with the application. Every time you have ordered something, three devices have gone by and have not received the item. I want to check the status of it. I can go to the courier company site and check where is the package in terms of delivery. In fact, if people have used FedEx or UPS, they track every leg of that parcel's travel. It's really cool, right? So it says parcel was picked up at this location, delivered to the UPS center location here on this date and this time. It is scanned there and then it was put on a plane at this date and this time. The plane arrived here, it was picked off, delivered to this load. It's really cool how you can track the fine granularity of the movement of goods today. Again, it's human to application, right? It's a universal way for humans to access applications. But what we are going to be talking about today is mainly for program to program, machine to machine communication, right? So humans are not at the other end of this, right? There is another program, a consuming program who is going to access a providing program, right? That is the notion. So this is meant for application to application access and the standards ensure that it is universal or ubiquitous in nature, right? So web services are basically nothing but an instantiation, a specific instantiation of the SOA concepts that go beyond enterprise boundaries. It also is meant to use internet protocols. That's the other thing, right? SOA has no specific reference to the internet. Remember, it's just saying that if there is a high latency network, you should treat things differently. But the internet and internet protocols such as HTTP are specific to web services. So here is the definition by W3C. W3C, by the way, is the, yeah? Is there any specific instantiation of SOA apart from web services? Yes, JAXTA by Sun, JAXTA and Gini, they are Sun-specific technologies. That is Java-based and it's also an instantiation of SOA, right? .NET by Microsoft actually employs web services in its outer shell, right? So it says that interaction with the rest of the world will happen to web services, although internally it can play a lot of games if it wants to. But the most popular instantiation today is probably web services. And the one statement is the SOA and XML based web services. Is there any other kind of web services that are not SOA based? Not XML based, no, but not SOA based, yes, is the answer. So there is something called restful web services. We'll talk about rest on day four and rest stands for representational state transfer. It is a lighter weight version. People claim that SOAP was too heavy weight. It was taking up, the protocol was becoming too heavy weight. And therefore there's a lighter weight version that was proposed and now is actually in the process of being standardized as well, right? So that's called restful web services that are not SOA based, but they're still XML based. XML underlies everything. So W3C is a standardization organization. It stands for Worldwide Web Consortium, has pretty much every country in the world who deals with computer technology is a member of this organization. And they are responsible for protocols all the way from HTTP standardization into web services as well. So here's their definition. So it's a software application that is always identified by a resource identifier of some kind. It's a URI that will identify web services, right? Whose description, right? And whose bindings. The bindings is how do I access engagement notion of it. That's a binding, right? Are all described using XML. XML underlies the basis of how web services operate. So it's basically a document exchange technology at its heart, right? So XML documents are exchanged between each other, right? It's very different from the notion of RPC where a thread of control it gets transferred from one process to another. There's no such notion here. I ship off an XML document to somebody, right? Who understands what's in that XML document and then he may send me a message back. He may not send me a message back. That's okay. You can have a one way call, right? Which is not going to be two and request reply synchronous mechanisms. Right? So that's the notion. Everything is described using XML. Okay. So the third part is kind of redundant. Suppose interactions with other software applications. Also using XML based messages. Finally. So it kind completely wraps itself around using an XML shell. So anytime you want to talk to a web service, either from an internal application or from another web service that sits outside, you have to interact with it using XML as a basis. Right? Via Internet based protocols. Internet based protocols are two most popular ones being HTTP and there's one more very popular protocol. It is used over the internet. Mail, yeah. If the HTTP tool, but the SMTP is probably the more popular one. Right? So there are bindings for both HTTP and SMTP within web services. So SOAP sits above the actual protocol on which SOAP messages travel and that protocol can be either SMTP or HTTP as it turns out. So this is a graphical view of the three core components. That's why you call it base protocols. So these are the core components and every service oriented architecture would have to have these core components. Right? So first of all there is a provider of a service. Somebody who is going to say, you're going to do this for people. Right? I'm a tax consultant so I will prepare tax returns as a provider of a service. Now they have to publish, the first thing that they do is to publish via UDDI. UDDI is another specification for a web service but they have to publish their capability somewhere. So whether registry is the second notion, that registry or a service registrar happens to be UDDI in our case and then there is somebody who will consume these services. That's the third entity. Right? And the consumer of these services will be able to find services from this registry. This is a directory much like a phone directory. Right? Yellow pages, white pages, whatever. Right? Once they find it, they still have to use it. So the description of how to invoke the service comes back from the service provider or it can come from the directory also. It doesn't have to come from the service provider. There are two ways by which they can get the description and then it connects via SOAP and exchanges messages. Finally. Right? Those are the base protocols. Base protocols will then turn out to be visible for description, SOAP for message exchange and UDDI for discovery and for search. Right? So the question is that many people will write services. So what is a good web service? A good web service is one which if I take a look at a description, I can say what it does. Unambiguously. Right? Remember what we had talked about earlier. Unambiguous and formal way of saying what is it that it does. Right? So it's self-describing. So it has an XML schema. Right? Which actually describes the grammar of this. And you can read it too. Human can read XML. It's not. In fact, there are many XML browsers that will really nicely structure XML for you and allow you to read it like a tree. Right? So it's an XML schema for this. So it has to be discoverable. In other words, there has to be some way of advertising the availability of this service. I have to be able to tell the world that this service exists and it's running at display. Please go find it. Right? It has to be coarse-grained. This is a good example of this. The CRUD operations of create order, read order, update order, delete order. When you're talking of it at the granularity of an order, not of a specific data item within that order. Right? So for example, if I have a shopping cart and if I have to add a particular item to the shopping cart, that may not be a service. Right? So that's not how I would have modeled it. So the example given here is set price, set product, set customer. These are all object-oriented type methods. Right? On the server side, you'll probably still build this with object technology. One of the things that you have to realize are web services are basically protocols for people to interact with the services. Service implementation is done using some computational language, Java, C++, whatever it is. You want to write it using Perl and you can write a service using Perl. No problem. Right? More often than not, it is asynchronous. There are synchronous ways of accessing services that are out there. But given the fact that these are going to be accessed over the Internet with large latencies, asynchronous operation is probably the best. So here's a comparison between traditional client-server systems and with web services. Traditional client-server systems are within an enterprise boundary. They don't cross boundaries. It's tied to some set of programming languages. So it's implemented in COBOL, C++, Java, whatever. It's not usually procedural, but it can be object-oriented as well. It is bound to a specific transport. So if I use RMI, I am bound to JRMP. That's my transport, underlying RMR. And there is no choice there. If I use COBOL, I'll probably use IIOP as my underlying mechanism. And it's tightly coupled. And the question that was brought up earlier with respect to efficiency or performance is typically traditional client-server systems are highly performed systems. We've seen it. We've built up systems for many, many years. And these systems have scaled pretty well. Web services go across enterprises. It can be done within enterprises. Not that it can't. In fact, if you take a look at the adoption of web services, the first phase of adoption would be within an enterprise. People don't want to expose their functionality outside initially. But it's typically because the internet protocol is meant to go outside enterprise boundaries. That's the notion. It's programming language independent. Of course, you have to still build your service implementation in a concrete programming language. So what happens is that there is a web service, a container, or an app server capable of understanding a SOAP message. And what it does with the SOAP message is it will go off and on a program somewhere. That is written in a specific language. The results of the program are translated back into XML as results and then shipped back to the person who requested it. It's message-driven as opposed to synchronous request reply. Can be bound to different transports. And we shall actually see examples of it being bound to both HTTP as well as with SMTP. It's loosely coupled. Relatively not efficient processing. It should be obvious why because of the fact that everything has to be translated to XML and back is one big overhead that you're going to have to face. Now this is being awarded. There are different ways of dealing with this. We won't necessarily go into all the ways here. But one of the advances in technology that is happening out there is that people are now beginning to build XML parsers in hardware. Things that can do XML translations are being built in hardware as chips. It's like a math floating point co-processor that you have along with your PC. Every time a floating point operation comes up, you don't want the main CPU to deal with it. You offload it. Somebody else will deal with it and give you back an answer. And that somebody else is optimized to deal with floating point operations. Similar to that, if I want to parse an XML document, I'll ship it off to the XML co-processor who will do it for me and come back. That's the next generation. That's where we're going to next. So that relatively not efficient is true, but that is being dealt with today. So is it a way the application would be often questions... Oftentimes I get that question as well. So it's not a way the application, a web service is different because it is meant for machine-to-machine interaction or program-to-program interaction where the applications are meant for human-to-program interactions typically. So that's actually the single biggest difference. The rest of them are kind of superficial. But we are really looking for a scenario in which you dynamically discover a description of a service and you're able to call it, a program is able to call it without a human having to get involved in the loop. Here are some of the characteristics. The XML base, we've discussed this, we've beaten it to death already. Message-based, programming language independent, dynamic. So I think we've called all of these things. I think the last one is important based on industry standards. It's a very, very open process. The web services aspect of it is very open because it is driven by W3C which is one of the broadest consortiums and it has got industry acceptance, possibly the widest industry acceptance that I have seen of any standard so far. So we talked about Corba a little earlier. Corba was actually a pretty neat kind of technology when it came out. It did most of the things that were plaguing people at that point in time. However, Corba did not survive whereas Java kind of survived. There are many applications built in Corba, especially banking sector applications that are sitting out there. But today nobody would think of Corba's choice technology for building enterprise applications anymore. Why? Do you know why? Anybody dealt with Corba before? If you compare Corba and J2EE, they are actually very similar in terms of functionality, not very different at all. There is hardly anything J2EE gives apart from language-based portability that Corba will not give you for obvious reasons. So why did Corba fail and J2EE succeed? Complexity is an issue. It is also there in J2EE to some extent. I mean it is not that it is completely free from it. Because we are dealing with a single language domain, things become a little simpler within J2EE. One of the main reasons why Corba failed is because there were two companies that managed to scuttle the entire Corba effort. Corba actually, OMG had membership from something like 250 enterprises who were backing it. All the big ones were backing it, Oracle, IBM was backing it. But there were two companies who said, you know, we do not want this Corba business. We are going to do something different and those two companies were enough to scuttle these 250 other companies. Because they were big enough, which is the two big ones. At that time they were big enough. Microsoft was one of them. Microsoft said, no standards, we want proprietary stuff. So, you know, forget all that. We are going to do Decom and .NET after that, right? And Sun was the other one. So Sun said, you know, what is Corba stuff? We want Java stuff everywhere. So we will do a remote in Java and build a J2EE container. These two companies went out there and basically scuttled the standard. So this last point is based on industry standards. It turns out that from what I have seen, web services has very, very wide industry acceptance. Even Microsoft is joined in this time, which is saying a lot, right? And if Microsoft joins in, it's a very heavy weight player. So IBM, Oracle, Microsoft are all behind it. Sun doesn't count as much anymore, unfortunately. So this is what we had seen earlier. We are just putting it slightly differently. A wide variety of devices can access or provide services. In fact, we are already seeing mobile phones that can access services, access not provide. But there's no reason why a mobile phone cannot provide, be a service provider as well, right? They're becoming quite powerful today. There are mobile phones and PDAs which have several gigabytes of memory. They have solid state disks on them. They have CPUs which are quite powerful, which can do plenty of stuff. So in the future, we are going to see mobile devices being service providers as well, right? And so that's going to form something like a service grid. And these devices are going to deliver services onto the grid, and then the registry will hook up to this grid, and then the same thing will occur. You will find services and use them for many other devices. There is an ocean of a service assembly where a business process is nothing but a macro service. So service can be considered to be a workflow behind the scenes, because it may call other services in order to accomplish its functionality. A travel agent exposes a service called travel reservation, which includes airline, hotel, and car reservation, right? So things like that. Or it may advertise a cruise service where you're sitting in Delhi. That means it has to actually fly you to some coastal city and then put you on a cruise ship and then, you know, fly you back to Delhi when you come back. So the travel agent is going to combine services. Now the macro service is nothing but a business process for the agent, right? Because it describes a definitive flow. I have to first find out whether the cruise line is available. If the cruise line is available and if I can get a booking, then I'm going to book the airline reservation. The cruise line is not available. I'll abandon the booking right now. So there is some flow to it. There is a workflow description, right? So every macro service or every workflow is exposed as another service. It's a macro service. And that's what you'll see. When you build a BPEL process, it is exposed as another web service. How do you invoke a BPEL process? You have to have a residual file for that BPEL. You have to expose it as a web service and you can invoke it only then, right? So that's what this is trying to depict. So why web services? We have interoperability because of standardization, right? Everybody who is going to accept a SOAP message, SOAP is universally understood. Therefore, I don't have to worry about the interoperability aspect of it. And since everything is described in XML, the underlying protocol is somewhat redundant, right? That's the other issue. So I can recycle components. This is true of all service orientation. The important thing again is that I have probably already invested in a web server and I've invested in XML technologies. I don't have to throw that away. That's why the economies do come into play here. It's very rare that there is somebody who is not using XML or web servers today. And since we are using HTTP and XML, the web server can receive the SOAP message and then send it off to somebody else. That's the notion, okay? So this is... So one of the things that we'll look at a little later is how do we go about transitioning to a service-oriented architecture, right? Presumably you have some legacy applications with you, now you can wrap all these legacy applications as web services and make them be available to the rest of the enterprise. The same thing that we did when we went from old COBOL applications to J2E or other modern distributed object standards. Right? Now yet another transition is taking place where your J2E applications now have become legacy and they have to be exposed using the newer standards, right? So it is scalable. We have seen many deployments. Actually there are some very large enterprises. Amazon, for one, who has completely transitioned to a web service-based infrastructure within Amazon, right? And Amazon is more of a software company than it is a retailer today, right? Because of the amount of technology that it uses and some of the innovations that they have even made in this technology. So we have proved that this is scalable and it can work even in very, very large enterprises, right? The advantages of open standards are, you know, you can look at it from three perspectives. One is from a developer perspective. One is from a service user perspective and one from a service provider perspective, right? So what do open standards, what is the role played by open standards for developers is that I can pick up any open source implementation that is there, develop to it. I can get the money for development to buy licenses and so on, right? And then I can deploy it on a more commercial platform which may be more robust in nature and so on. So you could do this with J2E as well, right? So you could develop on JBoss and then you could deploy it into IBM, WebSphere, or into BEA, WebLogic. People have done that oftentimes. So you can use any standards-compliant free implementations if they are available in order to do your development. You don't have to invest money in that, right? And the other advantage is that over a period of time, a huge number of community resources get built up who will help you out if you run into problems with this technology, right? If it is open standards-based. If it is proprietary, then, you know, you probably have to pay for help every time and so on and so forth, right? And it also depends on how successful that proprietary technology has become over a period of time, right? So for example, today, if you're using Apache and you run into some problem with Tomcat or Apache, there's message forums, right? You post a message saying there's this problem. It's likely that within 12 hours you're going to get a reply from somebody across the world saying, here's how you solve your problem. It's highly likely because there's so many people who are out there who are involved in this effort. On the other hand, if you have a problem with some Microsoft technology, clearly, and it all depends on how quick they respond to you, right? If you're an important customer, they will respond to you. If you're not, they won't. That's the truth, right? Okay, so then also there may be a lot of reuse that is possible because many people are developing to the standard and they may make their components that they develop also be available in open source and therefore you can reuse that. So for vendors, the advantage is that every vendor doesn't have to reinvent the wheel, right? The standardization process takes care of specifying a particular protocol and every vendor implements that protocol. And now every vendor is free to actually be inventive over and above this, right? So they can provide higher quality containers. They can provide higher, faster, more available containers, things like that. So there is room for innovation that is, that can go on with independent vendors. They don't have to create and maintain appropriate APIs because standardization process is accounting for that. As far as customers are concerned, you have application portability, right? So if people are developing to an open standard, presumably I can throw one vendor out. I can put the same product into our application into another vendor's platform and everything is going to work. Of course, that is, it's not completely true in reality. The ground reality is that there will always be some vendor-specific APIs that vendors provide that you will get hooked on to and then portability is not 100%. Right? But even if you're 90% of the way there, it's not bad. Right? Okay. So there's a large pool of developers that get built up over a period of time because it's an open standard. Right? Almost any graduating college student today probably knows Java well enough. They may not all know CLR and Microsoft technologies, but they will all know Java. It's kind of guaranteed. Right? So that's what I meant by that. So some of the myths that we have seen earlier that I think we should consider carefully here is the same old thing that we are reinventing and packaging. So this is actually two years ago I actually started out with this. I said it's the same old thing. But having looked at it much more closely, I don't think that's necessarily true. Some of it is the same thing, but some of it is not. Right? So here is a table that shows you. For example, you had with Corba, you had the notion of an interface description. We have Vizdel, which is an interface description as well, where RPC support through the ORB. The ORB is the actual underlying application server infrastructure that does message delivery. Right? Then you have SOAP in our case and compilers, except that they're now based on more ubiquitous standards here, which is XML and HTTP. And here it was all binary in nature. Right? The service registry, you had the Corba naming service. For those of you who have programmed this or GNDI, in the case of Java, to go find out things. But UDDI is much more universal. This is more akin to DNS. UDDI is the better comparison as DNS. DNS is any machine anywhere in the world you'll be able to do a name resolution on. Right? So UDDI is eventually meant to be like that, meant for public registries, if you will. And then there were some things, transaction security, messaging and so on, that have equivalent notion and services as well. Right? So it's not a brand new concept. Neither is it completely different than what existed. Earlier. Right? So there are elements of it that are the same. Yes, it is distributed computing. It is only based on open standards now. But it does help you go beyond enterprise boundaries. And the notion of services are different from objects does exist. Right? So it does add value. It brings something to the table that did not exist before. Web services only require a SOAP, crystal and UDDI. Not true. Right? These are only the core protocols. There are things that are required over and about this. Reliable messaging, for example, is one thing because their messages and the internet is inherently unreliable. How am I guaranteed that my message is going to go from one place to another? I need some kind of a reliable messaging strategy in there. I need security. I need asset properties of transactions to be guaranteed and so on. So we need higher level semantics that are coming by ways of different standards. They are based on RPC. Not true. They are asynchronous as opposed to being synchronous. They are basically a document transfer protocol. That's what it is. I mentioned this a little earlier as well. Right? It's a way of transferring XML documents from one place to another is just that somebody knows how to interpret that XML document on the other side. Right? In the case of RPC, you are actually going to have a binary protocol that will call a method that is sitting on another server. Right? So it's not a human readable message that is going across the wire. And it is asynchronous in nature in this case. Sir, which of the standard for segmenting is synchronous? How less is the standard that is being adopted now? So there is Vizdel with Aul is under doing standardization. It is not yet a standard but Vizdel that is WSDL with Aul for semantic descriptions. Web services don't have to be based on HTTP. SMTV bindings have also been defined and can be used. So the current state of web services is technology and standards are evolving. The core standards are fairly stable. Right? So we have 1.2 of SOAP and Vizdel that we will discuss. But some of the other higher level semantics that we talked about are still evolving standards. So WSRF for example, how do you deal with state in a web services environment? We have kept saying that it is only stateless. Which is not true. You can't really build only stateless applications. It would be foolish. Right? So how do you deal with state in a uniform way? So there is a specification called WSRF for web services resources framework that is not complete unfortunately. So there is work that is being done in management. Web services management which is actually been taken over by this organization called OASIS. Right? If you go to OASIS, not OASIS.org. OASIS something.org. I will find out the URL and give it to you. Which deals mainly with QoS and with management. So it will be adopted in phases. So here are some of the protocols. So if this is actually stopped from W3C. So the wire protocols are basically the HTTP at the lowest level SMTP. Under that would be TCP etc. SOAP will sit on top of this for packaging. And then there would be extensions which would be the different SOAP features. So for example, we say SOAP is extensible. What does that mean? What it essentially means is tomorrow if I come up with a new specification for security and I will still work with existing SOAP itself won't have to be changed. That's what we mean by SOAP is extensible. So SOAP features fit on top of the core SOAP itself. Right? So description starts from WSDL. So it's actually XML schema is at the heart of everything. Right? Once you have XML schema you have interface description which is WSDL. Implementation description we don't necessarily need to worry about. Then you have policy descriptions, your presentation descriptions. Other layer descriptions which sits on top of the core WSDL specification. Right? So for description technologies WSDL sits somewhere here at this level. And then policy will be over a particular web service. How do I specify access policies for example? There's a number of policies. We'll actually take a look at WS policy on the fourth day. And how do I do composition? Suppose it's a composed web service. BPE will also sit somewhere there. Right? Discovery, there is WS inspection which is a low level protocol and then UDDI sits above that. So publication and discovery are both UDDI related. Now apart from these core protocols it turns out that there are some parts of it that will cut across all these things. Right? Whether you are doing description, you're still out of this web service governance for example. Service description governance. So suppose it's a directory out there. Who will govern it? Suppose I put all kinds of crap into that directly. Well you know how are you going to actually manage this directory? How will service description expire at what time? Is there a notion of leasing? Now all of these are management concerns. Then there is a quality of service concerns. How do I know that I can trust this other person who is going to put out a service description? Can trust be encoded in some way? Right? So for those of you who have purchased something on eBay, how many of you have seen the eBay interface? Yeah. eBay, some of you have seen it. So if you go to eBay, what happens is that there is a small description there that says somebody is selling something on eBay, right? It could be anything from somebody's clothes to you know, tux and refrigerators and cars. So when I sell something on eBay, I may not be trusted by somebody else. How does the other person know that he can send me money safely and I will actually ship him this? There's no guarantee. At the same time, how do I know that if I ship him this and then expect money, how will he send me money? There's no guarantee. Right? So how do we establish this notion of trust out there? Because we are talking of service providers being available on the internet, right? We don't know this person and we are going to use a service that is offered by this person. We are never going to meet him face to face and we're still going to use a service that this person is providing, right? Can we encode trust in some way is the notion, right? So there is security includes all those issues, identity management, trust, etc. And then there's a quality of service itself. How do I know? How can I capture the fact that my request took fewer than X milliseconds, that he advertise and therefore it conforms to the SLA. Otherwise I want my money back, right? So those kinds of aspects. So these cut across all of these protocols, it doesn't matter whether it is for SOAP or for UDDI, QOS is important, right? So conceptually what happens is if you take those three, the wire protocol, the description protocol and the discovery protocols that we had earlier, those can be layered because you need the wire protocol at the lowest level because you even interact with UDDI with SOAP, right? How you contact UDDI is using a SOAP message. So your wire protocol is at the lowest level and then the description sits on top of this wire protocol and the discovery things. Then off on the side would be these three considerations that apply to everything, right? QOS, security and management considerations. So these core, this layer, right? Everything in the yellow, blue and whatever little bit of green is being handed by W3C, right? That is their domain. A lot of the stuff on the side is being handed by some part of it by W3C but some part by OSS, right? So that's the other sanitization organization that is involved in this, particularly the management aspect of it. So this is what I've been seeing out there. This is the adoption phases that I've been noticing. So first phase is simple web services, right? So its consumer focus is not meant for B2B as much. It is still meant for B2C kind of usages but they are wrapping them as web services and allowing these JSPs to hit the web services behind the scenes, right? Soap over secure HTTP. This is already been happening. A lot of the enterprises have done this already. Then the second phase is really that I am going to integrate all my existing point-to-point integrations I'm going to replace, right? So remember this case of Boeing that I brought up earlier, 1,700 odd applications inside Boeing. They are actually replacing all their point-to-point integrations by wrapping everything as a web service and then using a bus, right? So the notion is, I'll just illustrate it with the means of a figure. So today we have something like this. Let's say it's service 1, service 2. So all the different application packages and these are all integrated with each other that look like this, right? And for 4, it looks like this. You can imagine what it looks like for 1,700 applications. It looks like it's a real mess. And there are some very interesting diagrams that IBM has drawn with some real enterprises, right? It almost looks like a design of a chip. The integration of the applications themselves look like a chip design. There are so many lines crisscrossing each other. The density is staggering. So what we instead want is, we want each of these applications to be exposed as a web service. So this is the actual application. This is a web service interface. So there is some standardized way of dealing with these applications. And then all of them are able to communicate where are some standard and that would be SOAP and XML and HTTP. SOAP version, right? So we are trying to go from here to here, right? This is a notion that all the point-to-point integrations will be replaced by a standardized model communicating over a bus. Now you may have heard the term ESB or Enterprise Software Bus out there, right? So what ESB actually refers to is this bus. This bus actually does numerous things. So it not just is a messaging bus, but it may do queuing and reliable messaging, for example. Queuing plus reliable messaging plus persistence if the queue, right? Plus it may do transformations. So there may be some data transformations that are required to go from one place to another, right? So for example, I have portal which is a billing system. The billing system has a customer record that looks like this, right? Then I have some other system for customer management, what do they call? CRM application. And the CRM application has a customer record that looks different. They contain the same data, the structure of the data is different. So I have to interact between CRM and billing, then I have to transform the customer record as it goes from one place to another. The transformation can be specified as a set of XML transformation rules or XSLT rules, right? And that is enforced by the bus. When it knows that the message is going from a particular source to a particular destination, it already understands that it has to do certain transformations, right? So the ESB is actually just a name for a messaging layer but with certain additional functionalities, some of which are included here, right? Some people have started selling this as a product, ESB product, right? Okay. So this is the second phase. So the registry is private in this case. So it's an enterprise-wide registry but it is not a public federated registry that is sitting out there on the internet. And the third phase is only baby steps are being taken towards this third phase now, which is where we have business websites or BPL processes that are cutting across enterprise boundaries and are automating the B2B interactions that are happening between multiple companies, right? So this is something that we're just starting. So now you need to have public registries. You need to be able to publish your services in a public registry that anybody can see. And so the reason why this is not yet happened is because all these notions of trust and QoS have not been fully formalized yet, right? So we are getting there but we're not quite there yet. So the second phase is where we are and it has been successfully employed because there's no notion of a trust. If I'm within a company boundary, I trust everybody. There's no issue there. Yeah. So what difference it will make in purchasing these services whether these services are in them or in the system? There is no protocol difference in accessing the service. You will access it via SOAP itself. The difference is that can I access such a service? Now can I just randomly go out on the internet, pick a service and use it? I'm scared of doing that as a company, right? Maybe because of several reasons. I don't know whether the service provider will be around tomorrow. Suppose I use this service and tomorrow it disappears. Will there be another equivalent service provider? If he's not there, what will I do? I'm kind of stuck at that point. What is the standardization? The UDDI is a standard. The notion of standardization is I have to add elements to it that will somehow indicate trust. How will I measure trust? What is the measurement of trust? I mean some form of certification of the... Some form of certification. Who certifies a particular service provider? Would men become a question? So these questions have to be answered. Until they're answered, it's not that it's rocket science. It can be done, but it has to be done. So this work is remaining is what I'm saying, right? Service is updated. We are accessing the service. What version of service? Service versioning is also an issue, but that can be dealt with. That's not so much of an issue. Yes, you have to worry about it. So what version of the service am I accessing at this point in time? Right, so if it is completely backwardly compatible versions, then you're okay. It doesn't matter. If it is not, then it's an issue. The free service, then there's liability or... Yeah, so who has a liability if it is a free service? Suppose it doesn't work. Free service. Yeah. So there are many of these questions that make it hard for me to go outside the enterprise boundary and access services. It's like open source software, right? Many enterprises are scared of using open source software. Why? What's the reason? I'm the CIO. I tell my organization no open source. Why? That's right. So I'm going to lose my job if this thing doesn't work, but whom do I sue? There's nobody to sue if it is open source. But if it's IBM, I can sue IBM if that damn thing didn't work, right? So this notion of liability not resting in a specific place is the issue of why open source did not get adopted in enterprises. The open source source is about this. Even you don't have the... There is no source. Who are you going to sue? Apache has been written by 10,000 different people. There's no organization that you can catch hold of, right? So that the liability issues, one of the biggest reasons why open source did not get very widely adopted. It could have been. It's a lot of advantages, but that's one of the single biggest issues. It's the notion of if something is free, I don't value it as much. If something is expensive, then I value it a lot more, right? So that notion. Yes. So I have somebody to go point my finger to... So I can catch hold of red hat and say, hey, they were doing work. You better fix it. And they are liable to fix it because they charge me money. But in a real open source world, nobody, right? Yes. So that they're doing because they realize that the software is good actually. Fundamentally, it's good stuff, right? Java actually beats the pants off of both web sphere as well as web logic in terms of performance. Why wasn't it widely adopted? Because it was open source, right? You couldn't point a finger to anybody. So to go to a public federated registry, some of these issues still remain. But that's my ideal scenario, right? I want to be able to go out there and search the world and find... The thing that this opens up is a scenario where I don't have to be a big software company in order to provide services, right? I can sit in my halls, have four software developers, write up a service that may be really interesting, and put it out there on the web for people to use. That's the notion. Actually, if you take a look at organizationally also, there is going to have to be a change. And I've not discussed that formally here. The change that has happened within Amazon organizationally is that software development is no longer being done in 100 people teams or even 15 people teams or whatever, right? Software development has taken on a whole new paradigm within Amazon where they have these really small software centers, right? How small is it? It's called a two-pizza team. Why is it called a two-pizza team? Has anybody heard of this term before? The notion is that most of these software people are working 20 hours a day. They have to stay through dinner time. And when they stay through dinner time, if you have to order more than two pizzas for these software developers, then the team is too big. So as much, the team should only be as big as can consume two pizzas, right? That's the notion. The notion being that these really small teams that have end-to-end responsibility for conceptualizing services, for developing services, for deploying and running the services also. The data center is now become virtual in some way, right? In other words, you not only develop the service, but you run it. It's your responsibility to run it. You're a profit center unto yourself. If the rest of Amazon uses you, you survive. Otherwise, you're out of there. So they will actually measure the use of a service provider that way within Amazon. That's what their management strategy has shifted considerably to resemble this now within the software development organization, right? So that change in thinking would also have to happen. Because initially we had, okay, I was going to build an application. I need a huge number of people to build this application. There would be a large software development effort coordinated by a program manager. There would be many project managers under this. It's all out the window. It's not the way that things are happening out there, right? So this organizational mind shift to the paradigmatic mind shift also is something that has to take place in order to move to this model.