RE: FW: T2,Proposed solution for ... Re: SyncReplyandReliableMessagingMethod inQualityOfServiceInfo

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Chris Ferris states:
"Again, I disagree here. I think of an MSH as being unaware of the fact
that
it is anything but a MSH. The IM-ness of a node is captured in
application
logic as we have discussed, not as an aspect of the MSH itself. IMO,
the fact that intermediary functionality is being applied by the
"routing app"
is no different than if the "application" were a responding application
of a true endpoint.

I suppose that the MSH node could detect that the ToParty is not itself
and apply a different set of logic, but again, this seems to be a bit
more
complexity than might be needed otherwise.

	   RoutingApp
	   ^	    |
	   |	    V
	MSH-in   MSH-out
"


I do not strongly like this solution.

While it retains some architectural simplicity
for the MSH layer,
it drives many unresolved 
strains and tensions into other areas.

If the RoutingApp is an application, 
then it should be modelled in a BPSS.
So modelled, it is a multi-role, multi-party BP. 
As such, it is not within the scope of the 1.1 CPPA.
So we would not be in a good position to support
the 1.1 MSG in the 1.1 CPPA. 

If the RoutingApp
is part of "middleware" 
between the MSH and not
within the purview of BPSS, then it is a feature
of the extended DeliveryChannel 
that is not currently modelled
in the CPPA. It would certainly require
significant changes in the area of the Transport
element, much beyond putting the intermediary
in as a URL for the To and From party endpoints.
Again, we could add this into CPPA
if the requirements are clear, but we have over 20
months experience with this, and the exact functionality
of this Intermediary based middleware is still too
fluid to have been captured. For example, gatewaying
functionality (involving transforms of payloads, wholesale
changes in security properties, etc) tends to creep
into discussions and these _greatly_ complicate the agreement
model. In general, the "free floating middleware" 
gambit creates more headaches
for CPPA, and leaves BPSS off the hook.
In particular, the bilateral
deomposition strategy favored 
in BPSS would possibly
not continue within CPPA, 
because we would have CPAs between
ToMSH, FromMSH, and IMSH(es) that may not decompose
into pairs of CPAs (ToMSH/IMSH),(IMSH/FromMSH), 
and (ToMSH/FromMSH). (Again this is because 
there is no BP ServiceBinding for the IMSH capability).


Basically, the reality is that 
there _are_ two flavors of IMSH.
I think this becomes particulary 
evident when the quite reasonable
constraint on IMSHes is announced 
that a (forwarding) IMSH should never ack back
before it has been acked. 

For the Ferris solution, the IMSHes ack
when they hand off to the RoutingApp. 
So when there is a downstream
failure in the remaining MSH RM agents, 
our IMSH is in the embarassing situation
of having to somehow withdraw its ack. 
No matter how we twist and
turn here there are problems: 
if we use a DFN message, we have a
danger it does not get back, 
violating Marty's basic principle that
the From app SHALL be notified 
of failure. If we use some other
rollback compensation trick, 
we still may have problems arising from
the optimistic pre-commit that 
the IMSH ack represents. Maybe it is
a small probability event, but 
it must be treated for this to count
as a RM specification. I think the 
way to go here is to never allow an
IM optimistic ack and, by so doing, never get 
involved in rollback/compensation maneuvers
in those cases where there is unrecoverable, 
timed out, downstream failure. 
This will mean that the Retry situation
and timing probably needs much 
more careful sanity checking when IMS.
And that price is trivial compared 
to the mess we get into with
optimistic acks.

Now from the Ferris perspective, the
IMSH ack is not optimistic. It is just
the required Ack for the point to point
RM process. There are only point to
point RM segments in his view. If failure
occurs, it is like an application failure,
so the forwarding IMSH, sends back an 
"application" level response (a DFN ?),
that is a compensating "transaction".
This means that while successful RM
occurs at the MSH level, failure
handling is in part pushed (conceptually)
up to the application layer. Is that
really a RM solution, with different
protocol stack layers handling
different statuses? I think this is
bordering on exploiting (systematically) a
layering confusion for the ebXML 
treatment of RM. IMO, it would be better to just
leave RM undefined in the 1.1 spec. 
when forwarding IMSHes are involved and
wait until a BPSS schem for adding forwarding 
processes to BPSSes is worked
out and added to the ebXML specification suite.