RE: interposition requirements

[Peter Furniss <peter.furniss@choreology.com>]

>
> Mark,
> Looks like we agreed on most of the issues here! Lets read Peters doc
> (requirement doc), I am sure it will further clarify the issues.

I haven't made appreciable changes based on the ongoing interpostion
argument - mostly I just merged the original document and Pal's summary,
plus some tidy-ups.  There is some further work to be done though.  I
mentioned the need for  something on the potential separation of concerns
(interfaces ?) on the client side in the covering note - that would seem to
partly line-up with the concerns here.

I believe a fundamental of the whole approach is that from the viewpoint of
the inter-party protocol (counting both the application messages augmented
by the context, and the btp messages themselves) we do not know, cannot
require and cannot forbid any particular structuring or even distribution of
the entities involved. We have identifiable roles/interfaces and (for the
btp messages at least), addresses.  Anything else is behind the screens.

Peter


>
> Regards,
> --Sazi
>
> At 10:44 AM 5/2/01 +0100, Mark Little wrote:
> >> >Not sure which Mark you mean, but I'll take a stab at it:
> first I don't
> >> >see that the participant and the sub-coordinator have to be different;
> >>
> >> Per f2f definitions a service and a participant are different
> interfaces
> >> (they may be the same entity - implemantation detail) , a service has a
> >> business function interface while a participant has a BTP interface.
> >
> >That's fine. I was talking about the participant and the sub-coordinator,
> >not the service.
> >
> >>
> >> >  if a participating web service wants to propagate the
> context to other,
> >> > back-end (for example) web services then as well as doing
> it's own work
> >> > when it's told to "prepare" it sends this message to those back-end
> >> > services, i.e., it acts like a sub-coordinator.
> >>
> >> It simply invokes a new service (depending on the context the
> >> sub-coordinator of service invoked may register with the root
> coordinator
> >> or with our sub-coordinator.)
> >
> >Agreed.
> >
> >> Whether the service invoked implements both a business service
> interface
> >> and a BTP interface depends on the implementation but as far as BTP
> >> concerened there is an interface to coordinate the
> transaction, it might
> >be
> >> the service it self - we don't know.
> >
> >Yes, various people including myself have been saying this for a while.
> >
> >Mark.
> >
> >----------------------------------------------
> >Dr. Mark Little (mark@arjuna.com)
> >Transactions Architect, HP Arjuna Labs
> >Phone +44 191 2064538
> >Fax   +44 191 2064203
> >
> >
> >
> >
> >
>