 So, WS policy first thing we look at the policy specification itself is meant for you to give certain additional characteristics to services that you may wish to deploy even security is actually expressed as a policy it turns out right. So, policy is actually a framework it is a grammar to express certain requirements or capabilities that are available right. So, it applies to a number of other specifications that lie underneath it will tool see it when we see the architecture of the web service framework. So, this is what it looks like what you will see is that policy sits almost at the top. So, what this is trying to say is that policy is actually expressed in UDDI or WISDIL right. So, you will write policy expressions as we call it and that will be expressed even within WISDIL documents or within UDDI ST models. So, we will have to keep coming back to some of these concepts. The policies refer to something underneath it. So, there may be a reliability policy there may be a security policy whatever right. So, which is why it is placed all the way at the top. So, WS policy itself just tells you how to write policy without being specific about any policy or any set of policy expressions that may actually refer to a policy about security you know reliability and so on right. So, that is the notion here. So, it is a very simple everything obviously is still expressed in XML that does not change for us at all. We will actually see some of these details. So, you say that there is a WS policy there is some namespace and you can. So, this is a description of a policy and then you can actually reference this policy from wherever right. In the case of UDDI you can express the policy as a T model and store it within UDDI and then refer to that even through categorization. So, you can say one of the categories is this policy T model that I actually conform with when I express a service for example right. So, the basic building blocks are what are called assertions within policies right. The assertions like in programming language assertions which just say that this has to be true at some point in time right and we will see some example assertions. The assertions can either be a preference right. So, for people who are asking for it for example, it can be a preference it can be a requirement or from the service provider's perspective it can be a capability that they are providing right. So, there is the notion of usage that we will describe within a policy specification and we will see a complete policy expression statement and we actually what we do is we it is organized hierarchically we collect all of these expressions into a larger entity and those can be attached to different things that is the notion right. So, you say write a set of policy expressions you can group policy expressions in some way and then you can attach this group to something a service for example and so on right. So, the WSP usage values are many of them are there and these can be added these are the standard ones that has been given. So, the policy is required it is optional. So, this preference notion is expressed this way it is observed ignored whatever right. So, general messaging assertions can also be written like you must only send requests in German in this particular example we will actually go to see one of these examples. So, specific assertions have to do with specific aspects of what the policy is trying to describe right. So, for example, if you are trying to describe security to a policy then there are security policy assertions right. So, the basic notion there is the notion of a security token and the token for example can represent a user password login notion versus a certificate of some kind that is coming and so on. And then you can have policy assertions having to do with integrity confidentiality visibility and so on and so forth right. So, these are all extensible there are certain standard things that are defined for you up front. So, if you are talking about policy assertions having to do with reliable messaging then it is things like delivery assurance. Is it for example at most once delivery semantics at least once things like that whether the message expires at certain point in time or there are many of them most of these are self explanatory if you look at the name of this particular assertion itself right. So, for example, retransmission interval means that if I do not get an acknowledgement back then after how long should I wait and then retransmit that particular message right. So, this is another assertion about reliable messaging. Now, WS policy itself is a language that is all language in XML terms means a set of tasks that they give you right. You construct policies out of this right there is no default policy and the policies have to do with some aspect of your service infrastructure either security or messaging or whatever right or coordination and so on there is no default policies that can be written for any of these from what I know, but certainly an organization will first set up some of these policies beforehand right and these can be published via a directory as the models and other people can use them. Sir, is that part of WSDL file? It can be part of WSDL file too remember WSDL and UDDI two separate things you can have WSDL without using UDDI. So, you can actually stick it in the WSDL file itself and I show you an example of how you stick it into the WSDL file. Or you can publish it directly into UDDI as a T-model and then use it one of the two ways of using it. Sir, is it so that we can implement these security policies on SOPs or etc. Yeah. So, the policy does not talk about how it is implemented remember all of web services is an interface specification at the end of the day right it is how do people who use it see it and what is the provider going to expose right. How you actually implement that is left up to you and it is typically a lot of help is provided for the implementation by the engine on which you are going to run this system right. So, if you run it on web logic there will give you a lot of help on implementing certain default policies for example, they might have created default policies that you can use ok. Here is an example of a policy this is a security policy because WS it has something to do with security. This in specifically has something to do with integrity so you can specify the usage is one of those four things you know it is required it is optional things like that. Then we are saying that we are talking about a security token which is a Kerberos kind of a token out here. So, that means that whatever authentication is going to be done has to accept this Kerberos token that is going to come across right that is what you are expressing here as part of a policy. So, here is another example of a confidentiality policy confidentiality in this particular case it has to do with the 509 certificate that is coming across of some form. And here we are just saying that this token is going to be a certificate of this particular kind right and this itself would be defined what does this x509 v3 mean would be defined somewhere for you right. We understand what it means because we understand what 509 means, but for the system to understand it has to be described some place. So, policy operators is this notion of grouping that I talked about earlier. So, you set up a bunch of assertions and then you can group them in some way and call it a policy operator it is just so that there is a notion of reuse that is available here because policy assertion might be reusable in different groups and people may combine different sets of assertions for different purposes right. So, that is the only reason why they have done this there is nothing special about this. Then it is up to you to deal with you should not be actually because a service provider for example, let us say you are a service provider right you are the one defining policies for accessing that service right. So, if you are going to define two different policies which are going to conflict with each other that is going to be your issue it is the system will be high it is highly unlikely that the system can automatically detect and resolve conflicts of any kind. Even detection is very very hard right because the semantics of this are not specified this is only an interface. So, if I as a service provider say that for authentication I require a x509 certificate and then you also stick another policy saying for authentication I require a user name password then how can the system make out the WS policy language does not give you any way of setting up an ordering specifically all it says is that you can specify these policies right for a particular how that policy will actually be executed is really part of the implementation of that and I am not sure there is a standard for that from what I know there is not, but let me verify that right. So, different people may implement it in different ways so, this is one way by which it gives you certain amount of control when you create a group you can say only one in the group have to be executed right or all of the group all of the assertions in the group are applicable to whatever it is it is being attached to right. So, these are some of the three operators that have been given for you or one or more of them are available. So, it is not exactly ordering, but will allow you to say that I can only pick one if there are two conflicting policies that are in there all it is saying is I will accept any one of them in other words I can do security authentication either via 509 certificate or via user name password right it does not matter which is given I will take either one of them. So, that is what exactly one would mean right. So, here in fact that is the example that is here as well it says that here is a policy operator which is a collection of two different policy assertions this is one of the assertions this is the second assertion the first assertion says that you know I am going to take a user name token user name password type of authentication the second one says I am going to take a certificate to do authentication and exactly one of these would be accepted and if both of them came along obviously there would be an issue and they may not agree with each other what if one authentication the other does not that would be an issue. So, I will I am only I am telling you that in part of the specification I will only take one of these you cannot say in both. Suppose this user name is taken therefore in order to use this policy the user will not be able to access this service but how you set up the account is not part of the policy declaration part of it it has nothing to do with that right the policy is just saying how do you access the service in terms you know what are the conditions that I am I am going to put on this for you to access the service ok. So, attachment is the is this notion of simply access the service. So, attachment is the is this notion of simply associating the policy with some subject whatever it happens to be a web service in our case. So, this is how you do it in Vizdel. So, there are different basically every everything is a URI remember we have we have talked about this before as well because in Vizdel there is no notion of T model right. So, that is a UDDI concept just in Vizdel there is no such notion. So, I will say that this look up response message is associated with some policy which can be found at this URI that I am specifying here in the policy URI itself is specified separately and when you hit that URI the description of the policy will be available there right the same thing is being true you can attach different policies for different parts of the message as well that are out there. So, here is a notion of this being expressed as a T model. So, the policy itself is available at some URL the URL is given the overview documentation just like we would give the Vizdel URL as part of the overview documentation when the Vizdel T model right. So, here we are saying that this is a policy expression it is out there some name is going to be given and it is some category back that this policy would might also be attached to right. So, in other words the policy itself may be part of security policies that I am going to have. So, security may be a category back that I am setting up in here right. Now, what will happen is when you when you store a service description in here let us say you are going to store a Vizdel within UDDR then this itself would this T model itself can be referred to as a category for that particular service description that is being put in here which means that if you are searching for services which will accept X509 certificates then that is a category and then you will probably pick up that service if it is attached to that as through the T model relationship right. You get what that means remember everything in UDDR is a T model you mentioned anything concrete and actual policy description is a concrete description right. So, there are some tools that are available to help you deal with this I am not going to go into this, but couple of tools that I wanted to mention because yesterday number of questions came up as to what are the tools privately at least what are the tools that I should be using for some of these things. Almost every enterprise vendor has tools in this space that is the bottom line right. The major enterprise vendors of course are IBM, Microsoft, Oracle, WebLogic is WebLogic being bought by Oracle does anybody know? There is some news in the papers I thought I saw. Open source tools are there certainly I am talking of vendors. Red Hat has taken over Jboss now so you can actually get support from Red Hat if you want to use Jboss as an open source environment so that is a good thing actually ok. So, it is an overview of the policy aspect of it we will go addressing next the notion of WS addressing is to basically not tie the transport protocol as part of the end point specification I will show you what I mean by this and to enable asynchronous communication the asynchronous communication is the key here and we will see examples of how this can be done as well right. So, here is an example of a SOAP message there are three parts to this I am going to do a post on this SOAP message right. So, this is I am using HTTP to send this. So, the host URL is given here and the fact that this message is of type SOAP is given here right and what is the SOAP action to be performed is another URL. So, in other words you got to hit this SOAP message has to be sent to this particular person or not person some kind of an object that is going to receive this and do something about it in this case it is a method that is going to be executed somewhere get stock price method right. So, that is the SOAP action. So, what we have done here is we have made all this dependent on the actual transport protocol of HTTP that we are using. So, in here is another HTTP message that this is referring to and so on. We will see how we want to do this as opposed to this right. In order to make the SOAP message itself be protocol neutral what we want to do is to wrap some of this HTTP specific information with some WSA tags that we have been given right. So, that can actually be replaced with something else. So, this is actually not part of the SOAP message itself now right. What we are saying is that this notion of get stock price which is a SOAP action right which was described separately here as a SOAP action as part of the HTTP header. So, now I am actually mixing the fact that the SOAP action is part of the HTTP header therefore, I am tying myself into HTTP intimately in this right. So, this is what is happening even though it is an HTTP binding that is being used what we are doing is we are mixing the SOAP aspects of it and the HTTP aspects of it into one. So, this SOAP action is really should not be here it should be somewhere in here in the SOAP envelope itself right. So, it should say that this is a method that is to be called eventually right. So, this is how you do it using WS addressing and this will give you transport protocol neutrality. So, this would simply be a HTTP post to some URL right. So, in this case the URL would be www.stock.org and you would send a SOAP message to that and then within there when it parses the WS addressing headers it knows that it has to go to get stock price which would actually be the action and this would have to be sent to some object that would take care of this action right. So, you see the difference between this and this. So, the basic notion here is that this part of it is a SOAP envelope this is a SOAP message that is being sent but the SOAP action is being specified outside of this because we are sending this through a HTTP post right. So, we are actually mixing some part of how this SOAP message should be handled by somebody with the HTTP information which is part of the post that we are doing right. Now, we do not want to do that now the notion is we want to separate these two things cleanly we just want to do a post independent of where this message is supposed to go to I just want the host name in there of course certainly I need a host if I am going to do post there is no question about that. Therefore, I encapsulate everything else within the SOAP message itself right but SOAP will not understand the action part of it. So, I have created certain new tags using WS addressing tags that have been specified for me in which I specify this right. So, now I can specify this in any way it can be HTTP it can be an object reference for example, that is sitting on the other side and so on. It could be a serialized form of an object reference and I could say that it is directed to that and the action is actually a method on that particular object as opposed to an HTTP right. Now, the HTTP post that you do will simply be a normal HTTP post it has no SOAP information that is actually present in that right. So, this we already know about we know that there are three different messaging behaviors that visual defines there actually four of them we did not go through the fourth one yesterday the solicit response one. But we went through the one way the request response and notification two days ago right. So, request response is two messages then notification is only an output message that is coming back from the provider right. So, in the case of HTTP response is made we saw this that it will be conveyed to an open HTTP channel. So, it is not truly asynchronous in that case right. So, there is some client thread that is blocked waiting for this what we really want is a scenario where the client sends off a message and then using say HTTP, but it is not going to wait for that open HTTP channel for the reply to comma it is going to be a separate HTTP message that is directed back to the client right. So, this is completely asynchronous and in the till the message comes along it can be doing some other processing the same client thread can be doing some other process right. So, this is asynchronous communication how do you achieve that could be a question right. And so, WS addressing helps us do that by adding some of these tags. Now, when two independent messages are being sent one from A to B and one from B to A and it is meant to be a request reply scenario right you have to correlate these two messages somehow right. So, we talked about this both yesterday and day before yesterday right that correlation between the different messages are needed and so, WS addressing actually formalizes how you can do that correlation using the notion of a message ID and what it is which other message it is related to and so on right. So, we will see examples of this ok. So, here is the message the basic SOAP message is this is your SOAP header and this is your SOAP body that was there right within the SOAP header now we are adding some information which has to do with this notion of asynchronous that we want to achieve. Now, what are we adding here we are adding the from address we are saying that you know this is who is sending the message and if you want to reply to this please reply to I am there is a listener that is waiting at this particular URL right for a message right. So, I am the message that is going to come back it is going to be coordinated in some way through this UID that is specified here the message ID that is specified here right. So, the message ID is going to be included in the it is not exactly a reply message it is another message that is coming back in the other direction, but it is in response to a message that I had sent in this direction. So, there are two independent messages it is notion of an open HTTP channel I believe here right. So, we are not dependent on that open channel anymore right. So, because the response would take a long time to come back and we do not want to hold that channel open as a result of which we have to do the coordination that coordination is being being done through this ID and then we are also saying where do you send the message back right because in the case of HTTP what happens you open a connection to the other side right. Now, the open connection obviously there is a port on the client process that is opened as well in order to send the information the port on the client process is implicit you do not see it as a client only the listening port is usually seen and set up by the programmer the client port is implicitly used in order to get the information back from the HTTP server and then the information is processed back within the client right. So, there is no client port right. So, this is a way of specifying that client port saying send me back a message that I am waiting for reply at this place and if there happens to be a problem call me back at this place is what I am saying right. So, there is a fault as opposed to of course I can have the same thing I do not have to have these to be separate and I can process the exception at the listening port itself. But in this particular example we have given these two just to illustrate the fact that this two tag that has been defined as part of WS addressing allows you to split these two things out and how I am going to tie in the request and the reply is through using this UID right. Now you can it is a very generic mechanism as you can see and this UID can actually be related to any message. So, I want to tie a series of messages together I can do that. But the typical usage of this would be that it is a request and reply both have the same UID in some way. It is synchronous in the sense it is just doing a post, but I am not waiting for the results of that post in here. That will just be an acknowledgement that is not actually the result of the request that is being encapsulated in the SOAP right. So, this stock gets stock price of IBM is the request. But I am not going to the SOAP handler on the other side is not going to send a reply back where that the channel that is open. That is just an acknowledgement. By default it is asynchronous. Yeah. So, this is how you would achieve a synchronous by default it is synchronous right. If I did not put this block if I did not put this WSA block completely what happens I am doing a post I am specifying some SOAP action and that will return something right. So, the fact that I am putting this block is indicating to the SOAP handler on the other side that I can call this person back later where do I call this person back right. And when I call him back with the results I have to include some reference so that the other person can correlate his request with the message that I am sending that is what is happening here. This is the port at which you can send me a message. If there is a SOAP. Yeah. It is basically a place where there is a SOAP listener that is sitting there and waiting for SOAP messages to come back because the reply is a SOAP message. So, just like you have an endpoint specification that exists on the SOAP server side effectively now the client is also becoming a SOAP server right. Because the client has to be able to process SOAP messages that are coming back and make sense out of that. So, both have to have SOAP server capabilities in this particular case. It is just informing the port number to the server on the other side that the reverse response should be sent to the client at that particular location which is the WS reply listener location. It is just informing the new port number. Right. It is another TCP port. It is not the HTTP connection port that was initially open to send the post. It is another port that I am listening at. So, I actually become a listener which is different than just being a sender. That is all. Reply will be given. Reply will be given but it can come at any time. That is what I am making that is what I am allowing for this. They open now. It will be initiated by the server. That is right. That is exactly correct. That is exactly right. So, this channel would be initiated by the server and it can come at any time which is the key. Since I am listening here it can come at any time. This is WS reply listener and this value would be automatically taken or whichever port is WS reply listener. No, no, no, no. WS reply listener is a port. So, when you say some HTTP whatever .tr slash WS reply listener that means you can invoke this particular port and send a SOAP message to this. Just like I am doing the reverse direction by saying www.stop.org slash get stock price. So, the thing in the forward direction. Right. So, in other words the other person will do a post. Right. To this address and as part of the post there will be a SOAP message. SOAP action. Yes. So, endpoint references we have already seen this the from reply to fault to etc. They are all the notion of endpoint references. So, that has all of these properties this is the schema for it. So, this is an address which is an URI that identifies where the endpoint is we saw an example of that that is this then it may have certain other properties what is the port type the policy associated with that particular endpoint. So, even there we have authentication policies that may be specifiable for every endpoint that we set up that is out there. So, endpoint references separated from the actual service itself. So, an endpoint reference element just looks like this. So, here is the an example of a service which is a stock code service documentation etc. Then, yeah an endpoint is remember we had this notion of a port that we associated with a service when we wrote out our wisdom. Now we are saying that we are going to separate that information out into a structure that looks like this. I am going to give describe an endpoint in a more detailed way right. And I am going to then instead of having a port I am going to associate that endpoint with this particular notion of a port that I had before right. I am just going to allow you to specify that in a more detailed manner instead of just giving a port specification where I am going to be resonant too right. And the advantage here is that I will be able to give it certain other properties descriptions give it a name that I can use where more importantly I can associate a policy with that particular endpoint itself right. So, any anybody calling on this endpoint would have to have some kind of an authentication certificate to come to. It would be an example of such a policy right. So, these three notions already existed address service name port name and port type which you specified in the wisdom document earlier we now have the addition of a policy and certain reference properties so the endpoint actually has to be attached to this particular service that I am defining right. So, that endpoint is specified separately that this diagram does not show that it is attached to that this is just showing the separation of the service specification or the notion of the port that we had earlier along with the endpoint that is specified for it separately. Action of this we have seen earlier already action of wisdom operations we saw this in the very first slide of WSA as to how to include the action as part of the wisdom or the soap message as opposed to have it be part of the HTTP header that is being sent right. So, it is very similar to the first one the first one that we saw the very first slide that we saw in WSA were showing a soap message now what this is showing is actually a wisdom file and how do I associate the soap action with wisdom right. The first one just show the soap message itself the HTTP header and how do I include what was in the HTTP header as the action into the soap message here I am describing it as part of the wisdom itself. Here there are two different actions depending on the the message itself and every message can have a action associated with that as opposed to this where the operation itself is associated with a action not the specific messages themselves. That is the difference between this one and this slide. Fault codes I mean there is some default fault codes that are already there like 404, 200, 220 etc. but I do not think there are things that you can obviously add to this as well and this would come back as a soap fault and the only thing you can specify is that if there was a soap fault somewhere along the way so different endpoint to which the reply can come I will listen at that particular endpoint for fault processing alone. Get code and in that input message there is a WSA call an action in action we have given a URL what is get code here? Now get code is an input message that is coming so these are two different it is going to be treated as an asynchronous operation so the input message will call on this particular point so that is the action point this is presumably trying to say that it is going to have a sequence of ticker symbols that have to process at this point this is an action it is an action link it is an operation so that will basically consume the input message that is all that it is eventually doing so the output message also is associated with an action this should really be the client URL that is extracted from the from field or the reply to field rather that is in the soap message that came in eventually so that is how it should be at least I do not think this is completely right because why would both of these be related to stock.org that is the question so I am not sure this is 100% right what I believe is that the output action would be something that would involve sending a message back to the client at some reply to message URL that has been included in the WSA field right when the client and the client would be calling this operation get last grade price right this two are going to be argument for that operation not two argument points are one argument get rate in pricing input and the other one is get rate price output why are we associating this WSA column action attitude with the message here that is what I am not understanding well what we are trying to do is to separate and see what happened we have to compare it to this what we are trying to do here is that we are saying the get rate price has an action that is associated with it right that you call get rate price what the next slide is trying to say is we can separate these out into the processing of the input and the returning of the output separate these two things out these two are tied here basically this was the action this was the input and this was the output associated with that action the this slide is just trying to show that you can separate these two and have two separate actions associated with the input and sending the output back that is all right and that would be required if you are doing if you are processing this in an asynchronous manner as opposed to the the first one is more of a synchronous request reply scenario right where you will you will hit this particular URL right and this particular URL will have a soap body which which has this stock quote type right eventually that is big pardon now this is one action right this is this particular box is one action corresponding to one operation of getting the rate price for some set of ticker symbols that is being sent that is all this is this is what you normally would expect to see right this is what you are used to seeing this is the one he is saying that makes sense which is why the reason being used to seeing this there is one action that is associated with an operation that is taking some input and returning an output so transactions how many of you are familiar with the concept of a transaction all must be right so with respect to databases transactions has something called asset properties that it provides right the same notion is provided but it becomes particularly relevant to distributed systems when there are many components each one of which can fail independently right so there are many web services for example you saw that people that you wrote out yesterday it was contacting three different web services let's say these three web services were running on three different nodes all together everything was running on the same node in the example you did this way and what happens with this decentralization when you start pushing things out and distributing them is that different nodes can fail right so if there is a single people instance that is running across these different nodes and one of the nodes fails and how do you deal with it right now you don't have any way of dealing with it unless you have some kind of a transactional coordination that is taking place so everybody is referring to a transactions coordinator and we will see how that is done in terms of the architecture right what transactions basically give you is the ability to achieve atomicity finally so either the entire process executes or make it appear as if all the processes executed at all right in other words don't process half of it and then stop processing is what we want to ensure so that is the notion of atomicity and consistency, isolation, durability it means exactly the same thing as it means the respective databases as well in the case of databases for atomicity what it means there is that if I am going to change multiple tables or modify multiple rows then make it appear as if all the changes took place with respect to the operation I am doing on these database tables or not in the case of distributed systems I may be actually hitting physically disparate servers that are sitting wherever right so atomic transactions can usually be either committed or it can be rolled back or aborted as they say and if it is committed then durability has to be guaranteed in other words every change that has been made during the course of the transaction has to be made durable or made available after the period of the transaction is over right in the case is aborted every change that has been made up till the point that we called the abort has to be rolled back okay atomic transactions are good in the case of databases right so it is usually going to work because they are short lived transactions as they are called it happens in the space of at most couple of seconds not more than that but in the case of the kinds of business processes that you saw yesterday it may happen over the course of several days right the business process you saw yesterday of course was a flow through process where there was no human involvement right so the kind of workflow you saw yesterday had no human involvement and therefore everything was happening pretty quick right so as soon as you called the JSP to invoke the business process of the people and the result could come right back right that is actually a short live transactions but typically business processes are long live transactions right and how do transactions work they work by holding on to certain resources in order to ensure that other people will not be able to modify the resources when this transaction is alive so if transaction one starts and starts modifying a table it will typically lock some rows of the table or the table itself depending on what are the semantics that you are going to give it you know locking table level so on now in the case of long live transactions you cannot lock everything and keep it because if you go the transactions will take several days then there is no point so there is going to be a problem there and we have to deal with it very differently so which is why we have this notion of WS transactions right it is actually a suite of specifications because it works along with people itself as well it eventually has to work with business processes what we are interested in in this suite are two transactional models that are specified one for short lived and one for long live there could be short live transactions even with web services being deployed right and one which is more the business activity model which are long live transactions okay so we won't necessarily go through this it is just the coordination to say that there is one framework for all of this what is happening here is that there are transaction aware web services those are the ones that are being described in green here right a client application is the one that kicks off a transaction that cuts across these services there may be many different participants that are out there and then how we achieve this notion of atomicity is through a notion of somebody called a transaction coordinate right so how many of you have used tuxedo here anybody has used tuxedo which is a transaction manager not relating to this but it is a different product that existed before tuxedo which is also was from BEA systems right so it is a transaction manager all these transaction managers do is that every operation that has to be done has to go through them so they are keeping track of how much has been done and so in case an abort has to take place what is it that has to be rolled back right that is being kept track of by somebody and that somebody is a transaction coordinate the same thing happens here not really very different or this is the Java API for that so let us not worry about it at this point in time called jacks tx okay so the different players that are involved in one of these transactions is so the first of all there is the coordinator who is the central player and he drives what is called a two phase commit presume you are familiar with the two phase commit right so those quick cap over the two phase commit is that in the first phase the transaction coordinator will ask all the participants to find out if they are prepared to commit or not right if everybody is prepared to commit then it will issue a commit command in the second phase and commit on that and then if one of them is not prepared to commit it will do an abort or rollback right so that is the participant they can vote to abort or they can vote to prepare to commit right completion initiator is the client right so the client who says commit or abort in the first place and that signal goes to the coordinator and the coordinator coordinates the two phase commit protocol those are the different players this picture is actually not completely right so I will not go through this this is the correct question of this picture little later that I will show you so if you have this on your slide please strike it off I should have removed this yesterday the reason why this is not entirely right is that from completing if you are going to abort you will not go to end you will have to first go back to aborting and then okay so this is a different operations of the coordinator right so it has a commit operation it has a rollback operation it has an error operation etc so the participants completion service has to basically say it has committed or not or it is about it or not or there was an error during this process so this is the the visible for the participant right and the client API for this obviously just says commit or abort so that is the initiator as we called it earlier right one of the things that you can do with WS transactions is you may already have different transactional systems that are out there presumably you will because you are not going to start from scratch there are legacy systems you might have heard of kicks right CICS from IBM it is also a transaction manager similar to tuxedo competing project so you may have for example during the acquisition let's say it's a big company it acquires different companies one company was working with kicks one company was working with tuxedo how do I actually coordinate a transaction that is going across a kicks system and across a tuxedo system right so you need to have some kind of a standard and WS transaction would be a good standard to try and do this kind of a coordination right so in other words the transaction coordinator for WS transactions will talk to the two transaction coordinators for kicks and tuxedo whichever else is there whichever other product is there in that space and will do the two phase commit with respect to those two transaction coordinators who will then drive individual two phase commits down to the lower levels right so it's a hierarchical two phase commit solution can be found out of already existing enterprise applications this is I think the correct picture of the two phase commit that replaces the original picture you start with active and once you are active you go to preparing so if you are prepared to commit then you enter this stage if you are not prepared to commit you start aborting at that point in time right of course you can start aborting even when you are prepared to commit something goes wrong you can abort so you can abort at any time is what what it's trying to say because if it is read only it doesn't matter if you have not changed any data at all then you simply go to end and then you you're in committing state and then you finally end that particular transaction right so this is phase one of your two phase commit this is the coordinator generated phase and then there is phase two which is the participant for two phase commit yes I don't think we need to go through this there is lot more complexity to transactions than we would even want to think about this is actually showing a message sequence diagram for a two phase commit protocol right which involves a database web service in this particular case so this there 10 steps that it is going to go through in order to actually achieve this two phase commit first some transactional activities created by the application itself right and transactional activity could be an abort or a commit call that is being made right the coordinator service returns transactional activity is actually the beginning of the transaction it's not an abort or a commit so the way that it works is that let me just write this down so there is there is some client code and the client code would basically say begin transaction when you say begin transaction the step that is happening here is that the coordination service which is the coordinator transaction coordinator will return a coordination context alright so the reason why the context is required is because the context captures is some kind of a unique identifier for the coordinator that says that there may be many parallel instances of transactions going on many transactions are going on in parallel so I will want to identify everything associated with one transaction right and then this does some transactional operations let's say OP 1 OP 2 etc every operation is going to be sent the context to the coordinator to the participant let's say this is participant 1 participant 2 let's say OP 1 will go it will carry the context to participant 1 who will then identify the fact that it did some operation as part of that specific transaction so if it has to roll back it has to identify what it has to roll back same thing with respect to OP 2 OP 2 so the context is used in every operation that is done and finally you will do a commit or an abort at that point right so let's say there is some exception that is raised if an exception is raised then I will do an abort if an exception is not raised then I will do a commit that would be that is what the client code looks like okay so this is the first step where it is actually returning the coordination context itself right so the identifier here happens to be something called activity 1 that is the coordination context okay in the second step okay this is fine the coordinator reference is returned then some operation is performed in a web service which is what I just said after the begin some operation some set of operations are performed any one of these operations would look like this but the coordination context information actually has to be given there which is this activity one tag that was gotten in the first step if you notice right which is the coordination context is going to be part of any activity there so instead of just doing a soap operation which in this particular case it is a debit account soap operation I will include certain header information having to do with the transaction that says that this soap operation that I am performing is part of a transaction identified by a transaction context that I am including the header right so that is what this is doing is of type atomic transaction then finally there is the service registers a two phase commit so let us say that some set of operations only one of which was shown in this sequence and finally it registers a two phase commit so it says what is the coordinator address what particular two phase commit the web service is now going to return a result that also includes the thing so the debit account result is being returned as a separate soap message which is why it can have a header as well right ok so here is where the application is calling the commit itself so it is a completion that is happening the port type is completion and the message is commit remember the current messages that were available as part of the coordinator interface so this message is going to be sent to the coordinator itself to say that we want to now commit this transaction that we had opened earlier right pardon you can the message would be a rollback in that case it is completion with rollback right so it has to complete both ways so your client code would really be what would drive a commit versus rollback is a successful completion versus some exception raised during your process that is the standard client code right so the coordinator then starts the two phase commit by asking people to prepare so it will actually so this is a participant protocol service so every participant is sent this particular message to say you know you prepare for a commit what is not shown here which would be shown is that the transaction context remember that something it was called something one it was called right activity one so this transaction context is also included I have not shown this here necessarily so the prepare is sent but the transaction context has to be sent as part of every soap message in the header otherwise you cannot identify what is it that you are preparing to commit that identifies which transaction because the same participant could be involved in multiple transactions at the same time right and you could have made certain changes on behalf of each transaction so that context also has to be included that is not shown here the participant actually sends back a message saying prepare right so this is part of the coordinator protocol report type is a two phase commit so the web service that is capable of participating in a transaction will have to support the two phase commit port type will have to support that is what we meant by a transaction aware web service in the diagram that we showed earlier that is what it means so apart from whatever port type its own operation it is going to export it will also have to support so it is suppose let us say it is a bank account kind of a web service so it will support the debit credit transfer whatever operations plus the two phase commit has to be a port type that it exports the participant then sends committed the usual two phase commit and at that point the protocol X so it is 11 steps in order to these 11 steps of course include everything from beginning the transaction then the several operations that are done and then the final two phase commit protocol itself