 during the course of the morning, an example of a few SOAP messages that are sent to retrieve information back from UDDI, that is all. Okay, so why UDDI, like I said there are many registries out there, there are also some proprietary registry notions, you can build your own registry very simply if you can come up with a model of how to store information, right, A&I is a registry, right, the Java naming, the Corba naming service is a registry so on and so forth, they are all registries of some kind of the other, right. What we are interested in is certainly platform independence, so the fact that it is based on HTTP implies that we do not care about how this is being stored and there is a very nice abstract model that is defined for UDDI as a result of which everybody has to conform to that abstract model no matter how UDDI is actually implemented, right. Remember UDDI is a specification, it is not a product, right, so because of specification, you have to, somebody has to implement the specification and deploy the server somewhere, only then can you register things into it and can you look it up, right. So that is one thing and it is an open standards process, however UDDI is not being managed by W3C, it was, it started out being managed by W3C but because EBXML was being managed by OSS and they already had a bunch of other stuff going on, the UDDI effort has moved off to OSS as well, which is another standards body which works closely with W3C. So this is what enables dynamic service discovery, if you did not know where the service was running and one of the questions that came up yesterday was you know how far can we carry the notion of dynamic, right. So there are two aspects of dynamic, one of the aspects of which was demands or we showed you the code yesterday of dynamic dispatch where you know what the service is but you do not know where it is, right and you will go find, so you are looking for a particular service whose description you know beforehand, a priori, right and you do not know where it is and you find it out to a directory and then dispatch it all dynamically. The stronger or the deeper aspect of dynamism comes from I do not know what the service looks like as well, right but that is a much harder proposition to deal with, right. It can be dealt with significantly harder, now whether it has any practical use when you do not even know what it looks like is being questioned which is why right now mainly UDDI supports the notion of the first aspect of dynamic, it will give you the whole description, it will give you the wisdom and the question is whether you can construct the service request from that wisdom without human help, right. So what does UDDI contain, UDDI contains many different things like I said not just service descriptions, right, so it contains businesses and other service providers, in other words information about the business, what is the name of the business, where is it located, what are the contacts in the business, you know all of that information is contained and we will take a look at the model, what are the different services that this business exposes for each service, what is the binding or where is the service running as far as the business is concerned and then the different wisdoms supported by each of these services. So registry data can be divided into these two blocks if you will, the first block is just business registration, right, business registrations are, the businesses will give information about themselves, right, nobody else can give this, also the standard service type definitions is created by some standard organization, right, so there is something called a T-model within UDDI and different T-model definitions which can be standardized beforehand, it can be standardized with some standards organization, like what is the PO for example, the type definition for a PO may be common across most industries, it could be standardized and dumped into UDDI as well and everybody can refer to the same notion of a PO if there is a global registry that is available, right, by the way there were some organizations and still are, some organizations running global UDDI registries, IBM was one of them, we just got shut down a few months ago, I don't know what the reason was, no reason has been given on their website, then Microsoft runs one, then NetObject runs one, so we can give you the handles to some of these global registries if you want, take a look at that, okay, so how is data organized, data is organized in many different ways within this, so there are two kinds of data that you saw on the previous slide, can still be organized, can be sliced in different ways, right, so that you can look it up differently and this is very, very similar to how your phone directory notion is organized except that we will add one more concept, right, if you open a standard phone directory there will be white pages and yellow pages, right, in fact there is also something called pink pages, I don't know that we have it here, but governmental organizations, you know, emergency services etc are listed upfront in the directory separately, ambulance, fire, hospitals, airports, things like that, right, so they are actually listed in what are called pink pages at least abroad and they are listed prominently in the very first part of any phone directory that you can pick up, so that you don't have to search through this thing at all, and then there is the standard white pages where if you know the name of a specific entity or a specific person you can get their phone number, right, and then there is the yellow pages where if you know some of the attributes of what you are looking for, you can get information about them, I am looking for somebody who will supply plumbing material, you know, four-inch pipes or something like that, and then you can look under plumbing and then you can look under plumbing shops as opposed to plumbers and then you can kind of drill down there and get information about that, that's what this means, so this is organized very similarly as well, there is a notion of white pages, so if you know the name of a business you can say, go get me the handle to the description of this business, right, then you can drill down and get more detail upon the business and then you can start drilling down from there, so the business exposes services, so there is a containment hierarchy within UDDI, right, that containment hierarchy will allow you to drill down if you get to the top level of a particular business, so you can say get me these services for each service get me the description, get me the location binding, etc, etc, so that's the white pages and there's the yellow pages, the yellow pages are basically going to be based on certain attributes, so for example categorizations that you're going to create, again, so the question that came up a couple of days ago as to whether we can put categorizations, this is where you would put it, you wouldn't put it in the service but you would put it in the registry, right, so there are some standard categorizations that are defined in the West at least, so there are industry codes for example that are defined in the United States, then the ECMA codes, location is one way, etc, right, so where is this particular business located and so on, but you can create any form of categorization that you wish if you control the directory itself, right, and put it in there, yeah. They can be integrated, it depends on what you mean by integrated, you can possibly build your UDDI implementation to go picked off of an extra 500 structure because this contains similar information too, you know information about the business descriptions are also part of UDDI, so you could do that, it's possible to do that, but you would have to build that yourself, so your implementation has to do that, right, yeah, so those will probably not expose APIs, that may be a problem for you to integrate with, okay, so the yellow pages are basically focused on attributes not of services but of businesses, right, so I can find something based on the type of business that I'm looking for and then the green pages are actually based on technical information about the specific services themselves, right, so give me some service that has an SMTP binding and then also has an industrial categorization that does this, it would be an example, so you can search based on both kinds of information and we'll see one such example as well, so who are the people who use UDDI, certainly anybody building a client will use UDDI because they are the service consumer, right, so web service client, you can either browse or registry, in fact there are popular browsers that have also been written to go look at registries and present information in a tree-like manner to you, right, so that you can for a human to sit and consume, in fact the IBM registry has such a browser attached to that, so it's kind of unfortunate that they have pulled it offline, maybe it's temporary, hopefully it's temporary and then pulled back online, so that you can see what such a browser would look like, right, and clients will then pick up the service description, then create a proxy, right, or a stop as we called it yesterday, right, certainly somebody has to publish information to that, as far as UDDI is concerned, even the service creator is a client into this, right, so it's not different for UDDI, and that will generate wisdom and it will construct all the UDDI entities, yeah. In the previous slide, I'm talking about the technical information, so if you have multiple registries, and if I want to publish my service in all the registries, and do they all follow the same, some kind of standard for these, for a particular, I didn't come to a particular service, like, say, from the beginning of the month. We don't know, it's not necessary, right, it's not necessary that all the registries are going to represent the service in the same way, so this is typically what happens, I have a slide that shows that, what happens is that some kind of a standard description for a particular kind of service is put into what is called the T-model aspect of UDDI, okay. This is not specific to business, this is just across all businesses who are going to provide flower delivery, we will create a flower delivery notion, so this would be a consortium of florists, for example, right, so just like there's a consortium of chip companies, semiconductor companies, which have created all these standard descriptions of services that they offer, right. You have to have some kind of domain standards, which can be... That would be the situation where this would be most useful, if you had a domain standard, specific, say, to the financial domain, to the verticals, whatever vertical you're dealing with, right. Now what happens is that that model has been published into the directory, right, it doesn't mean the service is available, just the model of the service has been published into the directory, then individual businesses, should they happen to offer a service that is compliant with that model, will put out an entry saying, here is a binding for a service that will conform to that model that somebody is published here. And you will give a pointer, specific pointer using a key within UDDI to that model, so that many service providers will all provide services that are compliant to that particular model. They're just running someplace else, and they're different service providers, they're differentiated through quality of service or whatever other means. Remember the very first day, the first session when we went through what is a service, right, so standardized description exists. That's why the notion of dynamically discovering what a service looks like is not as useful is what I meant, right. If you have a standardized description of a service and implicitly that's what, you know, that's the way we work as well, right. So if you think of any kind of a service, if you think of a transportation service or a logistics management service, somebody who ships parcels for you, a courier company, all courier companies do the same thing, and that model is fixed in your mind, you know what a courier company does, right. So you call this person, you'll come pick up a parcel, deliver it, deliver an acknowledgement back to you, right. That's a standard model of that service for you. So from that perspective, we want to replicate the same notion here. So the model for the service has been standardized and put out there, and then all you need to know is which courier company to call, right. And so for that, you'll search based on many attributes. So does this serve my area, how much do they charge, what is their efficiency, what is their reputation, whatever, right. And then you'll call the person and you'll use that service. It's a very, very similar analogous notion here. So there is a standardized description of a service that has been put out there by some kind of a consortium, right. That has been formed, that is specific to that vertical domain. If random descriptions of the same kind of service are being put out there, it will make life significantly harder for everybody, right. So that's not, so if two courier companies work entirely differently, then it would confuse you also as a human, right. So this is the same notion here. If two services were described completely differently, it would confuse the client, the consuming client. Or finally, applications that need dynamic binding. So we've kind of already seen through this. So the last line here says that the query can be pre-generated. This is what we showed yesterday, the notion of the dispatcher, where the query itself was generated as a string. The SOAP message was actually encoded and kept as a string, except that we didn't know where to send it to, right. And that was found out dynamically and then shipped. If you take a look at the adoption strategy, typically this is a phased adoption approach, right. Very rarely would anybody want to go to put a public federated registry out there for consumption by the rest of the world, right. So of course phase one is just learning. You'll figure out how to use this effectively. But this is where your first step will be, would be phase two. Is that you will have a private UDGR registry for that organization, right. That's available only on the intranet. So there is restricted access to this in other words. If you have restricted access, the advantage is that this notion of standardization you can do within your own organization. It's not hard to do that, right. So there may be many departments, all of who needs to share the notion of a customer. And the customer should look exactly the same across all the departments in your company, no matter how large your company is. And in which case you will create a standard description of some kind of a CRM service that everybody is using. And any other service that consumes the customer information has to draw out of this description or conform to this description, right. So this is typically what you'll see today, which is why we don't see too many public registries. So the next step is that there are many public registries that are out there, but they are not actually truly federated. What do we mean by federated? They're working together as a single entity, sharing data. And different pieces of data is resident in different directories actually. But I can query any directory and it will go, if it doesn't have the information, it goes and queries the other directories and comes back to me with the information. That would be a federated directory structure, something like DNS. If I query my local DNS server, if it doesn't have the information, it bumps its query up to the next level DNS server, that doesn't have it, bumps it up to the next level. So DNS is organized as a tree, a multi-rooted tree, right. So there are seven root DNS servers in the world and eventually they will have the information, the information propagates within DNS, right. So if you, suppose I set up a new machine today on IIT and put it out on the internet, how will somebody else know of that machine? That DNS entry that is going to be made local to IIT will propagate to the next level. There may be a DNS server from Maharashtra, then it will propagate to India, then it will propagate to one of the seven root DNS servers in the world, right. So somebody searching from Australia for this machine would then first search within their campus, a Sydney or whatever. And if they don't find it, that gets bumped up, finally it will find it in the root. Or if the root doesn't have it, it propagates the search back down the other branches of the tree that it has, right. DNS is organized in a very specific tree like hierarchy. So that is what we mean by a coordinated or a federated system. So no matter where I initiate the search, I'm guaranteed that DNS will find this for me if it is out there, right. So that is phase four, so federated public UDDI registry. So there can be replication of data, in fact there probably will be replication of data for liability purposes or availability purposes. But this we are still a long way away from this. We don't even have a discovery architecture that has been outlined. So this needs a discovery architecture, in other words. How do I propagate the query? Where will I do replication? How much replication will I do on such a system? All these harder issues have to be resolved, none of which is, unfortunately, right. So it turns out that we are doing some work here at IIT Bombay with respect to phase four. So we have created one such discovery architecture for semantically annotated web services, right. So web services with semantic information. And we are in the process of writing a paper and sending it off in the next two months or so, right. But again, this is research, it's not yet out there for people to use, right. Finally, there may be value added registry services which goes one step beyond this and can offer other forms of search. I may even do negotiation on your behalf. It may do selection on your behalf. It may do rank ordering on your behalf, all kinds of things. So if there are 20 services, will I just return a bag of 20? Or will I return them rank ordered in some way so that I can pick it based on a profile that it has of me, right. So that's the notion. So maybe there is the notion of relevance, what is relevance? What is relevant to me may not be relevant to the next person. Or it may be a different relevance to the next person. So this is what we mean by value adding. You can think of anything here. I mean, the list is limitless and if you can provide such a registry with value added services, you can make a lot of money in the future. It's a business opportunity for people. Okay, so what does UDDA look like inside? What are the different entities specifically that exist within UDDA, right? So first of all, it's a business itself. It's called a business entity. It's a provider of some service. It is usually registered with respect to, it's available or searchable with respect to a white page lookup. You can actually also find a business entity based on certain other criteria. But this would be the standard way. I know of a specific business, right? And the business service is some collection of related services that exist. Within that business, within a context of a business. Then there's binding templates just like you have seen earlier for Vizdil and for SOAP. So the notion that the service is running on some particular port and it references some specific technical model in other words, right? So the technical model says what the service description is. Abstract service description. This is what we meant by a standardized service description, right? And we'll see some examples of this as well. So that is the next notion is that of a technical model or a T-model, right? So it's a reusable concept. Once I create such a T-model for some entity, then it can be used by everybody who's using that registry, right? How do I find which the unique T-model entities is a notion of a key that we'll see, right? Let's forget this. The relationship between businesses can also be captured in this. So it's some kind of business networking information can be captured in this directory as well. We are not so interested in this at this point, at least, right? And then subscription. So UDDI actually has API when you can say, subscribe. I'm interested in any business that comes up that deals with this area. And if somebody registers with you, let me know, right? Okay, so here are the core entities. So we'll forget some of the subscription part of it, the relationships between the businesses part of it. But this is what we are going to focus on for today, right? So there is a notion of a business entity. And a business entity provides a business service. The business service can be available at different binding templates. Maybe I offer different protocols at different ports. I can be accessed in many ways is what I'm trying to say. But typically, if it is a single business service, it will be corresponding to some T-model entity that's out there. T-model entity is actually a description of that service, right? So ideally, this would be standardized and reused. Remember, we had that abstract description of a service and then the concrete binding in wisdom. So this is the abstract description, if you will, right? So you can have many different business services that this is offering, right? So there is a containment hierarchy as well as a concept in here, okay? So, yeah, hmm. There's a service that's called through binding templates. Yeah. And that is compliant with different models. Right, in this case, ideally it won't be like this. This is just, it's not representing anything real. It's just a picture. Ideally, you won't have a situation in which the different binding templates are compliant with different interfacing models. It doesn't make a whole lot of sense, if I were to do that. If it were a single business service, it would not do that, right? A model for a career company. Right. Is that number of career companies that follow the same kind of model? Correct. So is this T-model same as that description? Yes. So ideally, we'll see towards the end of this talk, this session. What is the standard way of using UDDI? How would these different entities use UDDI? Right. So yes, it would ideally be the T-model that is shared by all the companies in a particular domain. So if we are talking a financial domain, there could be further classifications in financial, stock traders versus banks and so on. But all of them would share T-models corresponding to services that they provided. So online stock trading service, portfolio management of some kind, whatever, and there may be some set of services. But all of them do the same thing, whether you go to ICICI Bank or whether you go to HDFC, your online stock trading service is an online stock trading service. It's a very, very standard notion. A T-model for one kind of a service. Yes. So your online stock trading service will have a T-model. That they will be put into a registry. If they're all sharing a registry, so much is better, right? And then ICICI Bank will have its own implementation of that service that is running somewhere. That will be advertised as a business service by ICICI Bank, which is a business entity. Same thing with HDFC. HDFC will have its own version of the online stock trading service and so on. Sir, can we say that a model corresponds to a category of services? Not necessarily category. Here the category may be financial stock services. So categorization is a notion where you can club sets of services. So if I want to search, and I don't know exactly what is the service I'm searching for, I'm saying return all services within the notion of stock, something to do with stocks. So that's a categorization notion, right? So the T-model could be placed in a particular category, as we'll see, right? Sir, what is the relationship between domain metadata standards or an ontology with web services? Right now there is no mapping of ontologies to URIDI. I think we discussed this yesterday a little bit. But the next version of this, if you will, is going to be semantically aware. When it is semantically aware, that means that it is going to be tied. So rather than just saying that this message is going to take this particular type of information, I will relate it to a concept in some ontology. That way, even these descriptions can be related to concepts in ontology. One is the concept in the domain. Another is the service itself. That itself, you could have an ontology for the service itself. No, well, there is no ontology for the service. There is no such notion. Something maybe some metadata describing a particular service. That is available even here. Already available within URIDI. In one of the previous slides, we wrote meta-information on WSDR documents. Right, it will be there. So there would be English language descriptions to say what the service is like. If it can be consumed by a human, it can do that. At this moment, can we talk about that yesterday? We talked about orchards and flowers. So is that the same one when we talk about meta-information here or not? It could be. Absolutely it could be. So you could say that I'm a florist, but I only sell orchids. You could describe that restriction there. But it's not formalized, unfortunately. So it's a description that is free text. As a result of which, it's not a formal entity that can be consumed by another computer program and made sense of at this point in time. That will change once we tie it into ontologies. So if we look at that contentment directly, it would be something like T-model at the bottom. At the bottom. T-model at the bottom. So the T-model is first put out there. A business is going to offer many business services. Every business service may have multiple bindings, but a business service corresponds to a particular T-model that is out there. The T-model can be reused by many business services. Each business service corresponding to a different business. So top or bottom depends on how you look at it. But yeah. That business service itself belongs to multiple T-models. No, no, no, no. Business service is conformant with a single T-model. It can't be, it's not one to many there. And T-model is created by some consortium. If there is such a consortium, great. If there isn't, and if you're a big company, you create your own T-models and deal with it. How it is created is a different thing. This is what it offers as a capability. How you use this capability is a good way to use it. And I'm sure there are many ways to use it. So all T-models are available and domain. The disk trees are available. If it is domains, first of all, today, there's nothing available, unfortunately. So there is no confusion. But if we come to a position that many people adopt this standard and start putting registries out there, then we would like to avoid a situation in which the same service is preserved in 10 different ways by 10 different registries. Certainly we want to avoid that situation. How do you do one registry? If two or five career companies want to register their services, one same service, just one registry exposes one way of, I mean, so that within at least its own registry can say that these are the service providers for this T-model. So yeah, that's the whole point of UDDI. To say that there are five career companies offering career services, all of which are conformant to this T-model. In fact, that's exactly what a UDDI query will return. It will return a list of business services to you. Business provider will then register for one of those services. No, no, no. The provider is the one who's putting it into the directory in the first place. Provider is the one. See, we're going to first provider for Korean service. Fine. High register. The UDDI doesn't tell me that these are the services which will be offered through this. I mean, these are the services. There are T-models. There is not services. There are T-models, right? There are T-models. Yeah, so is there a T-model already corresponding to this kind of a service? It's the first question you ask the directory. If there is no T-model, you can create your own and put it out there, right? And then you will also register a service conformant with that T-model, which basically says that here is a binding. That means this service corresponding to this T-model is available at some port. We'll see examples of that. The relationship between the business service and the T-model is one to one, as you say. So then what's the relationship between the binding, template, and business service? I do not understand what does binding template mean. No, I can operate at different ports with different protocols. So I can operate at it, or HTTP port 8080 on some server. Some URL is going to be given there. I can operate via SMTP and somewhere else. The binding template is based upon a T-model. No, no, no binding template is tied to a specific T-model. It's actually the business service should be tied to a T-model. This diagram is not entirely correct. So one business service is tied to T-model. Yeah, yeah, we just discussed this earlier, right? We said this wasn't a true representation of what's going to be out there. We will see several documents. It shouldn't arrive, yeah, this shouldn't arrive, yeah. So this provider has to register all the UDTA directories or the company directories? Well, if it is a federated system, you register somewhere, the registration will propagate. You're like DNS. If it is not federated, what can I say, right? So we want to get to a scenario wherein we have a worldwide federated set of registries like DNS, that's our ideal model. Are we there? No, is the answer. Are there any efforts in that direction? Efforts are there in that direction, clearly. That's the, DNS also evolved on day one, there was no DNS, people were struggling. Finally, they all came together and said here's the smart way of doing things that came up with DNS, which works beautifully today. You don't even realize that, you know, when you do a IP address search from a URL, you might be going halfway across the world to find out where that IP address is. You don't even think about it. It's so transparent to you, right? So that's what happens when you type a URL in a browser. A URL is a name, right? So www.yahoo.com. What does it mean to a computer? Nothing. So it has to translate that to an IP address. Where is www.yahoo.com? It's an IP address on the internet. That is unique on the internet, right? How do I find what that IP address is? Go to DNS, that's my first thing that I'm about to do. So if, where is the DNS? There'll be a local DNS server. Remember when you set up your PC, you'll say, where is DNS? That's the first thing you have to say. Otherwise, the PC will not pretty much work. Right? So I think that EVX is going to provide support for distributed service, supported registry, supported new domains. It's support is provided by everybody, but you have to create such a structure. Just because the fact that there is support, does the structure exist? No. So support is provided even by UDDI to do the federation, but doesn't mean there is such a federated set of registries available in the world. It's not there, right? So somebody now has taken the trouble of defining the seven root DNS servers and maintaining them across the world and all that. Who maintains these registries? Nobody today. Eventually, somebody will pick it up. Since there are no WPC standards for it, right? So everybody getting T-orders, won't it re-pick up the same standards? No, that's what I'm saying. We are actually dumping to the last slide in the presentation, effectively. But what will happen likely, right? How many of you here have heard of Rosetta.net? Nobody? Okay, Rosetta.net, just to kind of divert from the topic, was an industry consortium of semiconductor manufacturers. AMD, Intel, Sun, IBM. There are thousands of smaller ones, Xilinx, you know, all these guys out there. It's an industry consortium who got together and said, listen, we're all buying and selling similar stuff, right? So we have to buy silicon. We have to get wafers done out of it. Once we get wafers, we are going to make chips. And then we have to sell the chips to each other. Some people may customize these things, whatever, right? So all of them deal with the same domain, in other words, right? Semiconductor manufacturing is the domain. And they got together and said, if we are going to be passing around the same information, what's a wafer? Let's define what a wafer is. And let's all use this definition, right? Otherwise, if each one of us define what a wafer is, it's going to be a pain in the neck to deal with the different definitions. So they got together as a unit and they came up with a set of definitions that they call Rosetta.net. And these definitions were created in XML and made public to anybody who wanted to interact with the semiconductor manufacturing industry. They made it a de facto standard, right? There was no standardization organization, right? So they said, if you guys want to talk, anybody out there in the world wants to talk to us as a group, right? Or as an individual, you have to use this standard. Otherwise, we are not going to listen to you. This is what they said. So that will have to eventually happen, right? If that doesn't happen, there would be chaos, but out of the chaos will be born order eventually, right? So if there is chaos long enough, people will get sick and tired of it and fix it. But that will need to proprietary sort of things. No, it's not proprietary. If every semiconductor manufacturer follows standard, what's proprietary about it? That's okay, right? So the notion of a purchase order for a semiconductor manufacturer is defined. It may not be the same thing as a purchase order for if you're buying marble to construct a building. Maybe a different thing. But that's okay. So all the civil contractors may get together and define their own this. But at least now you're dealing with two forms of purchase orders opposed to 20,000 forms of purchase orders. It's a good thing. What is the monetary benefit for that? Monetary benefit is it avoids chaos. Imagine the amount of energy, resources, people, computing, power that is being consumed, just dealing with these different definitions. Different companies give something to them. I am talking about the monetary. No, the Rosetta.net is not a physical thing. It's just a standard. It's a de facto standard. I'm coming back to the same thing. Does, if I'm a manager of some web service, I will publish a review. What is the monetary benefit for the OSS that marriage is built in? Oh, there is no monetary benefit for those people. Let's say they'll probably charge you something to publish it eventually, right? So if I set up a public directory that I'm going to let you use, and I'll probably charge you something to publish information, right? So do you pay the phone company to list you in the yellow pages? How you do? Absolutely you do. Business is not going to get a free listing in the yellow pages. You got to pay the phone company. Same thing, nothing comes free. No free lunch. So moving on, I think we've covered the last third of the presentation anyway. So we just had to cover the middle third and we're done. So what are some of the key design principles in here? We have the notion of keys because we have to uniquely identify many entities out here. T-models, business services, everything is assigned a key. If I register a business, it gets assigned a key. I can register the same business again. It'll get assigned another key. So you can do that. So the keys are either assigned by the publisher or are generated by the registry. Certainly uniqueness has to be guaranteed. So there has to be some way of ensuring that the uniqueness is maintained. There's a notion of containment. We already saw this, right? A business has business services and so on. Every business service can have multiple bindings, whatever. So there's a containment hierarchy, right? So the keys inside these elements are either referring to that element itself, right? Or it is referring to some entity that the element is referencing. Again, we'll see examples. I think it'll make it much clearer. So there can be a collection, right? So the notion of a container implies there are collections because a business can have n business services. That's a collection. And then you can have many different optional attributes. And we'll come back to this example. You can, don't have to worry about the specific example here, right? Okay, so here's a pictorial description of the structure of a business entity. Let's take a look at the structures of different things that we have seen so far, right? So a business entity, what this is saying is that there's some way of interpreting this. It is made up of all of these. Some of them are optional. Some of them are compulsory. It has to have a name. It has to have a description, whatever. So the plus here indicates that it's a complex structure that you can drill down into and find out what's underneath that and we can explore that complex structure. And then there are some standard notions. So you gotta have at least one name and you can have many names, right? So this one to infinity means, you should have at least one name. Zero to infinity means it's optional. I don't necessarily need to have a description, right? Of this particular business, but you could have many descriptions if that's what you wanted. Contacts and then contacts can be drilled down to so on and so forth. Don't worry about the identified bag and the category bag for now, but the category bag is a way of categorizing the business entity in this particular case, right? So you all know what a bag is, right? What's a bag? Students should be able to answer this. What's a bag versus a set? What is the difference between a bag and a set? Why is it a bag? You should know that. What is that? Yeah, you can have duplicate elements, right? That's what you want. A set count. That's why it's a bag. So every business entity is identified by a key, right? Everything has a key, right? So this is also identified uniquely by a key. Then there can be discovery URLs. How do I find this business? I'm going to list it in my discovery URL. You should relate this back here. So the discovery URLs is upfront, right? The topmost entity is that so this is just an example is that there's a discovery URL which is some example.com business keys, this blah, blah, blah. And then it will actually, if you say homepage, then it will return this particular URL that you would have registered. So I can say get back the homepage of this business entity from UDDR. And then it can have multiple names. So the fonts don't appear here, but so these are, if the name were to be in somebody from Japan were to read this is a Japanese version of the name. And so you can have Unicode representations that are stored in here, blah, blah, blah. In English it is called Nippon flowers, whatever. So it's an alternative name, maybe NF for this and so on. And then you can have descriptions in many different languages, right? So you can have a description of what is it that I do as a business, whatever, in many different languages. So what are these identifiers and categories, right? The identifier will basically say, how do I want to be known in terms of not a name, but any other identifiers that are out there. SAP AG is one for SAP and so on. And you can have a set of these, this is a bag. So you can have a whole bunch of these, each one having a different key value. The identifier bag is not as important as probably the category bag, right? So here we are saying that we are an ISO 3166 organization. It's a category, it's a categorization, right? Which can be formally explored. Now in the description also you might say that I am an ISO 9001 organization. I do this, whatever, whatever. But this is a more formal description in XML of the categorization itself, right? This is the T-model key for that categorization. The T-model will actually break up the categorization into greater detail somewhere. But just looking at the T-model key, you can kind of make out that, you know, this is providing a categorization where I am recognized as an ISO 3166 company. So in other words, if there are different ISO standards, I may belong to one or more of these standards, right? And that's what you can belong to many different categories at the same time. Any entity can belong to different categories. Category bag is actually not specific to a business entity, but it will be present for many other entities here as well, as we'll see. Yeah, no, no. A T-model is just a technical model, right? So for example, the abstract portion of your visual would be a T-model, for example, right? So it's not a category. A T-model will simply capture technical details about the category ISO 3166, right? Whatever that happens to be, what does that mean? I don't know, 3166, I'm not familiar with that standard, but whatever that happens to be. So in the case of a T-model for service descriptions, it would actually capture the fact that it offered these operations, blah, blah, blah. That would be the T-model. So it would be equivalent to the abstract portion of your visual on the other side. Wait, hold on. Are you clear first? Okay, so it's not a category. First throw that notion out of your mind, okay? So by itself, it is not a category. Every category can be described by a T-model. It will probably be described T-model, which give you the technical details of the category. Several categories. No, no, no. Each category will be described by a T-model because it is going to have to be uniquely described. Unless there is a general category called ISO, right? And so under that, there may be many different T-models corresponding to 31, 66, 9001, 2001, whatever, right? So that is possible. Category is a representative T-model or a T-model? No, no, T-model is the underlying basis for everything in UDDI, right? You will describe a service using a T-model. You will describe a category using a T-model. Anything, if you want to give a technical description of, you will use a T-model instance. So it is an underlying concept that is not tied to a category. It's not saying, but the categories described, just like a service is described using a T-model, the category can also be described using a T-model. Actually, it can have multiple T-models. Like, PO is a category, but... No, no, no. PO is not a category. A category would be things like, you know, I'm a florist as opposed to I'm a manufacturer of some kind. I sell something versus I make something. That's the notion of a categorization. But finance is a category. Finance is a category. But various domains. Within finance, we can have multiple... You can have specializations of that categorization. T-models will be corresponding to, say, I sell a... I will allow you to trade stocks online through my bank. There will be a T-model for that operation of online trading. So within a category, you can have... Yeah, see, these are orthogonal concepts. They are kind of cutting across each other. They're orthogonal concepts. Just like a... You will... 802.3 is a, say, IEEE standard. 802.311G or it won't be... Right. So those are all... Those are all specific standards corresponding to some category of standards which describe wireless connectivity. That's it. Right? So that's similar notion here. So the category and a specific service that is offered have nothing to do with each other. So I belong to some category. I also offer these services. I could just as easily place myself under the Flourish category and offer online trading services. I just do it wrong, but I can do that. What about a specification? Right? A specification, not a specification. T-model is a specification for this. T-model is a... I will show you an example of a T-model document, an XML document that shows a T-model. We'll come back to this question once we see that and see whether it clears your doubt or not. Sir. Yeah, one of you, go ahead. Just one more question, baby. It might be clarified in the other side. Mm-hmm. Is it that, okay, a category is described by a T-model. Now, inside that category, there might be several services and each of these services might also be described by a T-model. So it is not... Yes, yes, exactly. You got that. All right, excellent. Yes, seriously. All right. The model T is required to this. So then, what is... It's a key. So how do other key names and key values? I am giving additional information. The T-model key has to be unique. The key name might be the same in many different places. But... What we are worried about is a specific key. That has to be unique because that uniquely identifies the T-model entity that is out there. That is our main worry. Don't necessarily need to worry about the other two. Extra information that we have. Extra information that we have. In many cases, it's optional. The key is compulsory. You have to provide the other option. Okay. So this is just contacts. Remember, every business entity can have contacts within it. A contact is described by people, by phone numbers, by emails, addresses. Every address is composed of a bunch of lines and it describes an address line. I mean, this is a standard notion of a contact that you've come across in Facebook and everywhere else. You know, LinkedIn and whatever else, right? It's a similar model, exactly the same model. So T-model key. So this is the notion of a key reference that we are using is a required reference to some T-model that represents the identifier. So it may be an identifier code, geographical category, whatever, right? And we'll see examples of this as well. The other two are... It's an optional description of this identifier, like we said. That's also there. So the overall system has to have some value for that key eventually, somewhere, right? Is what... I think if you see a complete example, it may be a better thing. What is this trying to say? This is saying that there is some kind of a... Let's say this is a business entity, right? So there is a T-model key that says that the categorization group that I'm going to use is described by some WGS84, which is an encoding standard for latitude and longitude encoding, as it turns out, in a GIS way. So I can actually say my business is headquartered in this latitude and longitude, right? Instead of just saying New York, where in New York? I don't know, right? So the key reference basically says that... So this is composed of two different things. That's why it's a categorization group. It's composed of two different things. One represents latitude, one represents longitude, and specific key values are also given for this, right? So I correspond to this key model of latitude, but the value for latitude is this, right? So that's what I am giving here, right? So the name is actually relevant for me in this particular case. It's just a human readable name, but the value is necessary because just giving a T-model would imply that I'm compliant with that model of latitude, but what is the latitude I am at? We don't know, right? So somewhere in the system, this key value has to be present for this particular person using this T-model instance, right? And trying to identify themselves. Yeah. In that case, like for instance, WGS84, is it some kind of a standard for defining latitude? Yes. So if I want to define, for example, we are defining the location, or geographical location in the standards for the anti-account. So I will give reference to that and then see that within that, this is the value which it is. Yeah, so WGS84 basically says you got to have a latitude and longitude. That's what WGS84 is saying, and there is a particular way of encoding that also. I'm not an expert on GIS myself, but that's what I believe. In fact, we are also doing a small project for the Department of Science and Technology here, where we are helping this organization called NSDI, I don't know that you heard about it, the National Spatial Data Infrastructure, store some of that information in spatial databases. And I've come across this term there as well. It's basically a way of encoding latitudes and longitudes, that's what I understand. Okay. So we'll see some more T-model examples as we go along here, okay. So this is a business service as opposed to a business entity, right? We saw business entity, we saw contacts, then we saw, this is a business service. Service also has a name or description, many different binding templates. A category to which this service belongs, multiple categories to which this service belongs, and signatures, right? So the service key attribute has to uniquely identify it. Supplied by UDDI if it is not supplied by the publisher, that's what we mean by optional. So something will be put in there when you stick such a service description or business service into UDDI directly. So we'll see an example as I go through this. The gray is visible, yes, good. Okay, so there is a service key for some business service, this happens to be a stock code service, this is a name, some English language description is given, several different binding templates can exist for this service. So every binding template will have an access point which is a URL, et cetera. So that's what is given out here. And it says that the service for which this binding template is going to serve is referred to by some T-model key that I have not specified in this document, right? So that's one example, we have other examples here as well. So binding template, the main things that are important in the binding template is what is the access point, right? A hosting redirector is somebody who receives open message and directed to the appropriate implementation, but the access point is what is important in here. So here is an example of a category bag for binding templates, as opposed to a category bag for the services themselves. So the service could be categorized, the business can be categorized, the binding template can be categorized and so on. This is an example where it's a test of production template. In other words, if you send a message to this, it's still in test, so you may or may not get a reply. So whatever that might mean, right? So you could have different versions of this also. So for example, you can say that there's going to be three different binding templates, one of which is a gold binding template, one of which is a silver and one of which is a bronze. It represents a different quality of service categories that are being offered to the consumers. So if you use this binding template, you will probably have to pay more, but you'll get better services. That's what it means, right? Now, we had actually seen this example earlier as well. So the binding template was the same thing that was used in the previous service that we described, which was a stock out service, right? So the T models are basically the technical model that underlies pretty much everything in UDDI, right? So whatever you want to describe technically, formally will be described using a T model, right? And you can have many different ways of finding these T models with find qualifiers. So for example, I'll be able to sort by date ascending is one such qualifier that you can give it. So if this T model exists and many instances of this T model exists, I'll be able to sort these by date ascending is what this is saying. There can be many qualifiers so that it'll help people search on the other side. So I can say, here's a set of find qualifiers that I want you to use when you're searching for some information in UDDI. And that information also, some aspect of the search also has to be described in that search message, right? We'll see an example of that. So here is a T model structure. It'll have one name, it may have many descriptions, may not have any descriptions, it'll have what are called overview docs. In fact, your Vizdel is captured as a overview doc. So if there is a Vizdel file that is located somewhere, I can stick the URL of that Vizdel file in here. And therefore, I can return the URL of the Vizdel by looking at this information for a service from UDDR. All right? Sir. Yeah. Similar to T model structure, is there any scope for to have a semantic model of that service can be included in this? This is being extended as we speak. So whatever semantic metadata has to be captured for here is the T model is being extended. So we don't want to have something different because you want to have backward compatibility with existing UDDI entities. So this is being extended. T model structure is being extended. So this is a pictorial representation of exactly the same thing. So here's an example of a T model, right? So T model for the stock code service. It basically says here the description, Vizdel description of a standard stock code service interface. That's your English language description. It's not meant for machine consumption. The overview doc is important for us because it actually gives the URL of where the Vizdel is located, right? And then the category back for this can be financial services or whatever. So we have not actually identified a specific category back in here. But it could be one for financial services that you'll end up creating. So the previous questions with respect to categories and T model is that a little clearer? Pardon? The T model is the, no, the T model is the one that will actually has this information about where the Vizdel is. Or the description is, yeah, it's just an English language description. Some human wants to, if remember UDDI can be used in two ways. One is you can write a UDDI browser that will allow people to browse it or it's meant for program to program communication where you do a search, programmatically do a search and return information in which case it is going to ignore the description field completely. So they made it very general. They said if you want to build a browser and let humans look at it, look at it. So that way I'll allow you to write a description that can be displayed on a web page. So if you write a JSP which is going to display things on a web page, the JSP can actually pass this particular field and say here's the description. Let's take it in a table or something like that. Capital cement. It is W3C itself. There is these outlets extensions that are being done and it's not just going to affect UDDI, it's going to affect a whole lot of other things as well. Standards, right? So your Vizdel also will get affected. Your Vizdel standard because now you're gonna have to describe semantic metadata about the service. So many things are being impacted by OLS. So there is a committee that is looking after extensions to Vizdel to support OLS, committee that looks after extensions to this to support OLS and so on. So it has many implications. Can we impact the Vizdel file in any way? Why would you want to do that? In theory, yes, but why would you want to do that? I don't understand what you're talking about. No, but why, what would it represent is the question. You want a team model to uniquely identify some abstract capability. In this case, some service. But for a common kind of a service, like for a florist only, all the florists, if they work in a uniform manner, they have got a common interface, same interface. But the Vizdel file could be different from something like that. No, the Vizdel file will define how you write your client. The way that you programmatically write your client, right, yesterday you saw this. Right, your client is tied to that Vizdel description, intimately. So your client would have to change the Vizdel changes. Can you please repeat again the difference between categories and team models? So the category is also captured by team model. That's one point that I wish to make, right? So the description of the category is also captured by a team model somewhere. That's one thing. See, in fact, you can see here, in this category bag, you have one keyed reference, which is another team model key that is given to something else, right? A team model is just a way of capturing technical information about anything within UDDI, that this is what you have to keep in mind. Anything, businesses, business entities, location information, service descriptions, all of them is captured within the notion of a team model. A team model is like a class for you, right, in object-oriented design. The notion of a class, if I write different classes, they will capture the semantics of what that class represents. What can be instances of this class? Pardon? What can be, what are the instances of this team model? So you will give a particular key value and say that key value can be interpreted in the light of the team model description that I'm giving you. Like a template. It's like a template, yeah. With values have to be filled in that are given by the key value information when you use a keyed reference, right? So we... Hold on, let's answer this one question once. Unless you're going to clarify that. Okay, excellent. Then you can go. All right. Adding to that, all right, fine. Do it anyways. Flourish, yes. Take that as a category. Okay. So there will be a team model. Right. Describing it. Technically, describing it. Okay. That's what we have to do. Now, we say orcodes. Right. Something else. So there will be, suppose these are the categories, subcategories, of course. Okay. Take that as subcategories. So there will be team models for these subcategories also. Yes. Now, when services are returned, services will have its own key category. Services will have its own team model. Team model, yeah. The service team model actually corresponds to the Vizdel that you're going to give it. So there will be different Vizdel now. Yes. I have one for Orchid, one for something. Yeah. There is no Vizdel for a Flourish service because there is no Flourish service. There is only a service corresponding to an Orchid and other things. So the Flourish category is an abstract category that you have created. That you can say, in your Orchid service, Orchid selling service, that it also corresponds to this category. You can have it correspond to multiple categories. Right. So that's what it is. There are a number of Vizdel now. Yes. That are coming into picture. Right. And the category that is there, that was Flourish. That's fine. So every Vizdel can have multiple categories or every service can have multiple categories. So then multiple Vizdel, are they? No, no multiple Vizdel for the category. See, I am a service, I am going to sell Flourish. I mean, I'm going to sell Orchids, okay? I'm going to put out a service that sells Orchids. I have a Vizdel description that I'm going to put out there, I'm going to include it here. And I will say that I belong to category Orchids, I belong to category Flourish, I belong to category Valentine's Day gifts, whatever it is that you want to think about here, right? So you can have number of category descriptions so that when somebody is searching by category description, I'm looking for a Valentine's Day gift for my girlfriend, then your name will also pop up as a person selling Orchids. That is the notion of categories, right? But I say the services that are to be returned to me that sell Orchids, if I look for that, right? If I look for all services in this category, then it will maybe return a bunch of Flourish back to me, somebody who sells Orchids, somebody who sells it, other things too, right? So the category is just a tag that I'm going to stick on to it to say that if somebody is searching for information by category, then you can also include me in this search, the results of the search. When we search, we are going to team what if it's searchable? Technical description is there? Eventually the technical description has to be returned to the person to make use of that information. Not the technical description about the category is not important, but certainly about the service is important. And if I didn't have technical information about the service, which is a Visdill file, I cannot contact the service at all. And I also need the technical information about the binding template in this particular case. So I need, there are two things, I need the Visdill, right? And I need the binding as to where is this service available? What is the access information? Or the binding template is required? Two pieces of information are required. So search will go to all Visdill? It depends on what you're searching for. The search won't search the Visdill itself, right? It will just search the categories. Categories. Yeah. Search won't actually, so the Visdill may not be stored within UDDI. It's a URL that is stored within UDDI eventually. That is why UDDI never, today UDDI is not used to return the Visdill. It is used to return a URL of a Visdill. Preferably the Visdill is kept with the service provider. So when you return a URL of a Visdill, that URL will refer to the service provider. So you hit that to get the Visdill back, right? Remember the diagram that we wrote out yesterday morning for soap interaction, right? So we said the interaction looks something like this. So there is a service provider and a consumer, right? And there is a registry. This person publishes information about services in this registry, right? This is one. Then two, he searches the registry and gets information back. The information that is returned is a URL of a Visdill, right? It can contain the Visdill too, but typically it doesn't store the Visdill. Typically the Visdill is still here, right? Then he says, go get me the Visdill so that I can understand exactly how to invoke the service, right? So this is Visdill query returns a Visdill and then you invoke the service and then there's a response. This is the picture we saw yesterday. So there is no notion of searching the Visdill file here. You are searching based on certain categorizations that you have done within UDDI, certain tags that you have. You can think of it as a tag, a category is like a tag that I'm going to attach to it, right? I can attach many tags to myself, right? So I can attach, suppose I'm an IIT and I'm teaching, I can say that I want to advertise myself as a service provider and I do many things. One of the things I do is offer CEP courses. So I will be a CEP course provider tag that I'm going to stick to myself. Then I do consulting with many companies. So I'll say consultant, IT consultant, and I'm going to stick that tag, right? So all of these tags can be attached to me, right? Depending on, also if I want to describe myself fully, I must stick other tags, you know, I'm a father of two children. So I'll say father tag, blah, blah, blah. So if somebody is searching for fathers within IIT, they'll find me, right? If somebody is searching for CEP teachers in India, they'll probably find me. So there are all these tags that are stuck to me. That is the notion of category, right? Eventually if they want to find services that are being provided by me, they'll have to get back the WISDL or the URL of the WISDL, right? And that is contained within a T-model description of the service, which is a technical description of the service. And want to register in the same category, can adopt different T-models? The category itself is uniquely described by a T-model. By one T-model. One T-model. It will become a different category if it is a different T-model. Yeah. Then service can have different T-models in that case, finally. Pardon? Service, we had showed, and she in the relationship. Service cannot have different T-models, it can have different categories, each one of which has a different T-model. That is the difference. So finally it means that... No, the WISDL is the same. The WISDL, the T-model describing the actual technical description of the service is the same. The category T-model is different. There is a big difference between the two things. Right? Big difference. Yes. I take a live example. Moment two citizen services, GPC services, and category issue of certificates. Now there are 20 types of certificates, dead certificate, birth certificate, domain science certificate, car certificate, how? Under this category, I have so many. So I will have various T-models for each of the issue of the certificate, or it will be one category. Like, categories are issue of certificate, citizen certificate, but I have dead certificate, birth certificate, class certificate, marriage certificate. Those are different services, all of which will be tied to one category of issue of whatever certificates that you called. You can have common categories, citizen certificates. You can have a common category, exactly. All of them may be sharing a common category in this case. Perfectly, you are going to do that, right? Because I am wearing a T-model. The category for citizen services, what does it mean is described in a T-model? What does citizen services mean is described in a T-model? So, that's what it is. That's what it is. That's what it is. Yes. But when we saw that the T-model distribution, the slide, there was a visual, also, there was a visual URL. The visual URL was in there. The visual URL was in it to the service. This is the access point. This is what you are referring to? Yes, now it is a T-model description. And here the visual URL is also coming into the description. So, this is T-model for the service. This is the T-model. This contains the visual URL. Now, we have a service. It has a tag called as a category. And that category will have a T-model. That is a different T-model. Different T-model. The category T-model description is a different T-model. This is the service T-model. That also refers to categories. Each one of it has a T-model. Does this service T-model? That's it. That's what he was asking. Does it have a T-model or not? It does. Everything has a T-model in UDDIT. Everything. Business entity, service, categories, everything has a T-model. That's why I said it is the basis of all of UDDIT. It underlies everything that's going on within UDDIT. It's a technical fingerprint, as they called it. Keys, we don't have to worry about specifically how the keys are generated for you.