Re: Open-top coordinators and protocol

[Mark Little <mcl@arjuna.com>]

> I think there is a distinction between portability and interoperability.
If
> we wanted to create a portable Java demonstrator (for example), then we
> would have to have a standardized API in Java that defined all the
> relationships between application components and the BTP protocol
(analogous
> 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..

Hold on. We're talking about Web Services here, or at least I thought we
were. In that case, the implementation language is not important at all. We
have a Web Service exporting operations A, B and C. How it implements them
at the back-end is unimportant. Likewise, how the user of that service
intends to implement the client is unimportant. All they have to agree on is
using SOAP and XML to interact. If they want to use CORBA then they'd agree
on an IDL definition. However, the end result would be agreeing on a series
of operations that can be invoked from the client to the server. At the
low-level these operations are message exchanges (and even lower they're a
sequence of bytes transmitted over TCP/IP or UDP). But the important issue
is agreeing on the operations (the contract). That was the thrust of the
original coordinator email.

>
> CORBA has standardized algorithmic language mappings from a canonical IDL,
> which can be used to create local and distributed objects; we have no
> equivalent.

Correct. However, whether the coordinator talks SOAP, CORBA IIOP, Java RMI,
or whatever, it will be necessary for it to support a series of operations.
By default (and agreed at the first London face-to-face) we would use SOAP
and XML as an example.

> 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).

Actually I'm less concerned about whether we use WSDL or an XML schema.
However, I want the protocol to have the flexibility of choosing both.

> But WSDL has no standardized language mappings, unless I'm missing
> something. There is no standard way of creating Java objects that map WSDL
> definitions, or C# objects or C++ objects, etc etc. Therefore, to use WSDL
> to define an API might not be so useful.

Tools do exist. However, as I said above I'm not too concerned about this.

> After that, you still have to deal with bootstrapping (an area where CORBA
> OTS portability breaks down). Common naming conventions for OASIS
packages.
> Interface/implementation separation to allow different implementations, in
> languages without clear interface constructs ...
>
> Interoperability is a simpler, cleaner target, which is also a defined
> requirement. The current document refers to the original Choreology
> submission, which read:
>
> "Requirement #12: Interoperability
>
> An interoperable protocol will be based on agreed network message formats
> for distributed processing and clear contractual commitments on the
parties
> involved in requesting or receiving the invocation of a computation.

We do not have an issue here then. All we are talking about are semantics.
Whether it's defined in IDL, WSDL or an XML schema, there will be
"operations" which take certain parameters and do certain work. How they are
implemented is up to the back end. But what those operations are is
important, and was the focus of my original email.

> It is assumed as an overriding requirement that message formats will be
> described in terms of XML schemas, capable of validation on despatch and
> receipt:"
>
> Interoperable implementations use standardized message formats, understand
> the correct sequence of messages and the reactions that are required in
> response to
> receipt of messages. In order to communicate they must have a common
> understanding of messaging, in terms of underlying carrier protocol,
> addressing of endpoints, and concrete encodings (wire formats).
>
> 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.

Agreed. How we map from the SOAP/XML requests to the higher-level
implementation objects is outside the scope of this specification (and
rightly so).

> We did decide, way back at a models FTF, that an illustrative API would
help
> us to discuss and explain the use of the BTP protocol. Then the last FTF
> placed heavy emphasis on the need to create distributed coordination sites
> (ones separate from the initiator) and this led to the decision to bite
the
> bullet and define the protocol for the I-C relationship.

However, from some of what Peter has been saying there seems to be the
implicit assumption that coordinator and initiator are co-located in such a
way that implicit under-the-covers communication can take place between
them. In a web services world, where all first-class objects (actors) are
web services, this isn't going to happen.

> 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 do not see this as the 95% case, or even close to a 50% case, and is
contrary to much of HPs experience in this area. However, if it's required
then a) take the interposition-route and put it in the extended context, or
b) do it better in the first place and do it at the application level with
cooperation between service and participant.

> 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.

I agree with this as far as the web service/participant is concerned.
However, as I pointed out in an earlier email, I believe that the ability to
tell the service to prepare should be done at the application level with
application-specific enhancements to the XML, for example. The initiator
should not be allowed to send coordinator-specific messages, either directly
or indirectly (piggybacked).

> The only difference between the one-shot case, and the long-winded
approach,
> is that messages are boxcarred via interception, rather than being sent
> out-of-band (asynchronously to the application traffic). For this to be
> achieved the protocol actors (Coordinator, Participant) decide to
_delegate_
> message transmission to the application actors (Initiator, Service).

Does this not assume that the initiator knows some of the
coordinator-participant protocol (at least what it takes to issue prepare)?
If the initiator sends a full-blown PREPARE message (whether it is
piggybacked on a service request or not) then it will have to know how to
assemble such a message, payload etc. This kind of blows separation of
concerns out of the water, because now whenever (and if) the BTP protocol
changes in terms of PREPARE, all initiators will have to know. If the
initiator simple sends a "I'm finished with you" message, then that's
exactly the application specific type of thing I'm arguing for. I'm not
against early prepare per se, only how it is implemented.

> The next issue here is: should the protocol allow boxcarring? Should we
> allow messages (any messages) to be concatenated on the wire, so that an
> interoperable receiver can ingest several messages at once? I can see no
> good reason to prevent that kind of optimization.
>
> If we tolerate delegation (which is hidden from us), and permit boxcarring
> then you can't stop the one-shot deal being implemented. Then the debate
> resolves to the issue PREPARE or PERMISSION_TO_PREPARE, which is another
> subject.

Boxcarring can only occur if the coordinator and initiator are colocated, or
the initiator has some knowledge of the coordinator protocol. The first
situation should not be mandated, while the latter is unreasonable.

>
> > If the vote goes to the Coordinator, then the Initiator does not know
the
> > result of the vote. It needs to talk to the Coordinator to
> > find out.
>
> This is not new. All that has happened is that the initiator used some API
> to say <boxcar PREPARE with this message>, and the VOTE was returned.
>
> [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]
> 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]
> INT -- ENROLL + VOTE -- C
> INT -- *RESP* -- I
> I -- <prepare> -- C
> C -- <outcome> -- I
>
> In the optimized case the prepare API call just gets back the vote result
as
> held locally.
>
> 2 net messages between I and S, instead of 5 in the standard case.
>
> 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.

So much for the Web Service approach to coordination we agreed on at Mt
Laurel. If I and C are co-located, and you have sufficiently intelligent
interception, then this is possible. However, we agreed that we would not
require this to be the case. In which case I and C messages comes from
different routes entirely. If we take the application route I have mentioned
then we can *always* support it because a) the context with the coordinator
information flows from I to S, b) S interprets the application-specific XML
as meaning "I'm a one-shot" and tells P, and c) P sends the vote back to C.
It's the same number of messages, but we maintain the strong distinction
between I and C, *and* it works whether or not I and C are co-located. In
terms of model and portability this has got to be preferrable, surely.

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203