[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Open-top coordinators and protocol
Hi Alastair, > > (Hoping this message will reach the list :-) > > I actually received six copies of this mail, dated from 2.23 to 2.45 am! > Oops. I am sorry. I was trying to post to the list and I was getting an error but I didn't think (the time, you see:-) that the cc to you was actually successful :-( Sorry. > > I think there is a distinction between portability and interoperability. I agree. I am talking about interoperability. > to the Java or C++ mappings of CORBA being used to create mostly portable > code for OTS implementations). We would then be able to take the Java > implementation of BTP from Choreology and BEA and try rebuilding and > rerunning across the two implementations. There are lots of issues > involved > in getting to this level of portability.. I am talking about taking BEA's implementation of the BTP Coordinator and using it to drive participants implemented by HP and Choreology. Since it is the Web Services arena, I don't mention any implementation language. BEA may decide to implement their BTP Coordinator in C++, HP in Java, and Choreology in .NET. As long as the actors can accept SOAP messages and they have a well defined interface (using WSDL) the implementation language is of no concern to anyone. I am not suggesting that we should define the spec in this form. This is the mapping of the spec to the Web Services arena. A decision we took in the Boston f2f. There has to be a WSDL interface for every actor in BTP that participates in a defined-by the model-interaction. Let's assume that I want to develop a .NET application that is composed by a number of Web Services. I want to issue a number of calls to the Web Services within the context of one atom. I need to create that Atom so I must communicate with a BTP Coordinator. Let's assume that the Coordinator is not co-located with my application. The only way I contact it is if there is well known interaction protocol. Since we are talking about Web Services, that would be SOAP and WSDL. The API that Mark described is just that. Of course the names of the calls can change but they have to be well known. If we do that, then it doesn't matter who implements the actors. The Coordinator would be able to call prepare, for example, on the Participants without even caring whether they are implemented in .NET by Choreology or in Java by HP. I have to repeat something from one of my previous messages. I am not suggesting that the spec should be described in terms of WSDL. The spec should be defined, as you have proposed, in terms of message sets. I am merely saying that the mapping of BTP to the Web Services arena also needs to be specified. > > WSDL, as I understand it, is essentially an interface definition language > with bindings that enable you to produce wire formats (encodings) for the > messages described. Therefore, it *might* be reasonable to use WSDL to > define the protocol message sets (although that seems unnecessarily > heavyweight as an interoperability feature, as an XML schema would do the > trick). WSDL is actually an XML document in which you can specify XSD schemas. Although I don't like the analogy, you can think it like the IDL of Web Services. Let's not forget that Web Services are the "new" components and as such they need to have an interface. WSDL allows us to specify that interface. If I want to use a Web Service in my application, I have to know its WSDL. [...] > > An interoperability demonstration would allow initiators, services, > coordinators and participants, each created using different > implementations, > to interact correctly. The API used to create the language objects that > represent these actors (or actors-in-roles, depending on your view) could > be > wildly different from implementation to implementation. The actors would > still interact correctly. > There is no disagreement on this. By specifying the methods on the actors that can be called over SOAP, it is my understanding that we achieve just what the spec suggests. > Well, this actually goes back to the BEA submission. I agree with Sanjay > and > disagree with Mark Little that there is no proven or likely need for > one-shotness. I listen to BEA's experience with an actual product out in > the > market. It is backed up by comments made by Mark Potts, whose company also > has deployment experience in this field. In principle, it seems obvious > that > many web service interactions will be based on something similar to > "getQuote". Practical experience in many environments also makes me > allergic > to extra messages (and _relatively_ indifferent to payload size). > I think we all agree that if we are to honour the interactions between actors defined by the spec, interception is required. In this case and if the Initiator and the Coordinator are not co-located, the messages are the same (if not more:-) So, why further populate the protocol? Couldn't we leave this to the application? Here's what I mean. It is an optimisation that the service provides. The Initiator knows that only getQuote() is going to be called on the service, so it propagates that fact, probably through an argument to the call: getQuote(TheOneAndOnlyCallToThisService) :-) Now, the service knows how to handle this by contacting the participants registered with the atom (remember, the service-participant interaction is not specified by the protocol). Notice, that nothing BTP-related is required. Now, you can achieve your optimisation and we can still be happy because things are kept simple at the BTP level :-) > The vote would always be returned to the Coordinator. The service receives > the CONTEXT, containing the coordinator address. It sends back an ENROLL > to > that address (in this case piggybacked on the app response) which contains > the participant address, swiftly followed by a VOTE. The interception code > which would be required to achieve this strips the ENROLL and VOTE and > delivers them to the Coordinator. The net result is no different than > ENROLL, followed by a PREPARE (sent by Coordinator to Participant), > followed > by a VOTE (sent by Participant to Coordinator). The vote has been > received. > You assume co-location here. If the Coordinator and the Initiator are not co-located we do not save messages. > > [all CAPS like this means "BT protocol message"; <inanglequotes> means > "API > call". "I" means "initiator", "C" is "coordinator", "P" is "participant", > "S" means "service", "INT" means "interceptor", *REQ" means app request, > *RESP" means app response] > > In the "standard" case, you see this happen: > > I -- GET_CONTEXT -- C > C -- CONTEXT -- I > I -- CONTEXT -- INT > I -- <sendrequest> -- INT > INT -- *REQ* + CONTEXT -- S [net message 1] > S -- ENROLL -- C [net message 2] The service does not enrol. The participants do. I think you forgot the following. Also, the Coordinator needs to reply to the Participant with the result of the enroll request. S -- UNDEFINED -- P P -- ENROLL -- C [ net message 2 ] C -- ENROLLED -- P [ net message 6 ] (for counting purposes and not ordering) > S -- *RESP* -- I [net message 3] > I -- <prepare> -- C > C -- PREPARE -- P [net message 4] > P -- VOTE -- C [net message 5] > C -- <outcome> -- I > > In the optimized case, you see this happen: > > I -- GET_CONTEXT -- C > C -- CONTEXT -- I > I -- CONTEXT -- INT > I -- <sendrequestwithprepare> -- INT > INT -- *REQ* + CONTEXT + PREPARE -- S [net message 1] > S -- ENROLL + VOTE + *RESP* -- INT [net message 2] Ooops. Again. The Service does not enrol. It's the participant. The service call cannot continue until the participant is registered. Even if we forget that co-location is assumed and _if_ I was to agree with you (which I don't), the last one would probably look like this: S -- UNDEFINED -- P P -- ENROLL + VOTE -- INT [ net message 2] INT -- ENROLL + VOTE -- C C -- ENROLLED -- INT INT -- ENROLLED -- P [ net message 3 ] S -- *RESP* -- INT [ net message 4 ] Unless, of course, you assume there is another interceptor at the service/participant side (again assuming co-location). (Please, remember that I am just following your argument rather than agreeing with it :-) S -- UNDEFINED -- INT' INT' -- UNDEFINED -- P P -- ENROLL + VOTE -- INT' INT' -- *RESP* -- INT [ net message 2 ] The flaw with this is that a service is allowed to respond without knowing the result of the participant's registration with the atom (security consideration?). I don't think we can count this as an optimisation. > INT -- ENROLL + VOTE -- C > INT -- *RESP* -- I > I -- <prepare> -- C > C -- <outcome> -- I > The main problem with this approach is that co-location is assumed at both sides (Initiator/Coordinator and Service/Participant). The interceptors will not save any traffic at all if the actors are not co-located. I think it's very easy to see that with your example. Is it just me or does your example assume that the initiator knows a lot about the service? Does it know that there is only one participant? If more participants had to be registered with the coordinator because of the application request, the interceptor (INT') at the service side would have to persist the enrolls and the votes until the response is constructed and sent. Failure-recovery would have to be a requirement. Finally and I think very importantly, your optimisation is based on the assumption that the service can proceed its execution without knowing the result of the participant's registration with the coordinator. Are we allowed to make such an assumption? The solution I proposed earlier, solves all the above. If an indication is sent to the service, at the application rather than the BTP message exchange level, then the service could instruct the participants to vote when propagating the context (or by some other means that is implemented-specific). Unlike your optimisation, this will work even when the actors are not co-located and it has the significant advantage that it has nothing to do with BTP (thus heeping us happy:-) I -- GET_CONTEXT -- C ( net msg ) C -- CONTEXT -- I ( net msg ) I -- <SendRequestTheOneAndOnly> + CONTEXT -- S [net message 1] S -- UNDEFINED + UNDEFINED_YOU_CAN_PREPARE -- P P -- ENROLL + VOTE -- C [ net message 2] C -- ENROLLED -- P [ net message 3] S -- *RESP* -- I [ net message 4 ] Now, this is again achieves the same optimisation in number of messages as the (what I believe is the correct version above), it has the advantage that it will also reduce the number of messages when the actors are not co-located, and it doesn't even involve BTP at all (thur putting a smile in my face :-) > > 2 net messages between I and S, instead of 5 in the standard case. > That should be 4 messages instead of 6 :-) > I assume for this discussion that I, C and INT are colocated, and S and P > are colocated. That way we see the real likely impact. > Oops. OK then. You are making the assumption! .savas.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC