OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[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