This may turn out to be a meta-meta... comment. My
apologies...
I largely agree - at least as concerning the strict definition of
the inter-party protocol. The discussion on transactions is perhaps more to see what you can do with protocol.
But
I do think we want to have at least some element of conditional or reversible
performance of service requests. Though how far it actually goes is up to the
service.
I think that this is all
interesting, but somewhat out of our control. Except by why of defining
our space, I'm not sure we need be so concerned with carefully defining these
transactions. It seems to me that we should focus on what it takes to be
a business transaction. In particular, I offer the following
observation, with a few specific comments.
I think we need to concentrate on what services/semantics are
delivered to the users of the protocol -- callers and services. I'm not
sure the rest of it is terribly relevant. Specifically,
- I think we need to recognize that in many cases, for BTP work,
the form of recovery is unknown. Moreover, although it may be knowable
by the implementors, I suspect that they may be unwilling to publish it
-- it is likely to change over time. I think we should, again
for BTP work, simply concentrate only on our ability to inform the
collection of services invoked in a BT (of P fame...) that it went forward
or not.
I
agree - in the general case, the service would be offering no more
than "if you tell me you didn't want it, I will make it as if you had not
asked for these aspects of the operation ..... (which are visible to
you), but these effects .... (also visible to you) will still apply" (and
there may be all sorts of stuff invisible to you).
- I think we cannot and should not rely on
ACID properties. Semantically, if I offer a service, I
probably make a promise that it's Durable (although that may vary according
to my Terms Of Service). But I do not want to promise that it's Atomic
(internally or externally), Consistent (that's my business, not yours), or
Isolated (unless there's some privacy contract/semantic that a service and
its invokers have).
Yes
- I do not know what you do with the data involved in your service, and if you
get in a mess internally that's your problem. But if your service offers (in
some degree) to undo/reverse/cancel/compensate if I request, I can build your
service into a consistent set of service invocations, even in the case where
some of the set do not work as I'd hoped.
- I think we should be careful to be architecturally neutral.
We are often descending into speaking about coordinators, authorities,
etc. We cannot/should not specify that -- we just to Protocol -- how
do I ask to have something accomplished.
What
to call these entities is one of the trickiest bits ! There's
something up there sending these messages ! (You can write protocol specs in
passive voice, but it gets a bit wordy)
Given these, it's my
opinion that we're concerned only (in BTP) with collections of services and
some mechanism to collaborate on their collected outcome.
I would prefer that we focus on that. So, we get something like:
- The Business Transaction Protocol is a vehicle for the coordination of
web services.
- When participating in a Business Transaction, a web service will
- be informed of it's participation (by inclusion of XXX protocol
fragments)
- be given the unique id of the transaction for reference
- be expected to respond "appropriately" to requests concerning this BT.
- A BT will add little, if any, architectural overhead.
In many ways, I think that for at least the first draft, we might
want to restrict the notion of a BT to simply a collaborative name id for a
collection of web services and a protocol by which to specify it.
Passing around id's, and then expanding the implications of the id
later on is a bit risky. If it's just label on a bunch of invocations that can
be used for queries now, there
will likely need to be another id
if, later, we want to say anything about the relationship of the decisions
(yes/no, forward/backward, confirm/cancel) that apply to the
invocations.
Above that, we could add certain API's (really, web services I suspect)
which allow for query of status -- perhaps from a service "back" to the
invoker (after, say, some time has passed), or by which the BT may be
officially ended.
Working loosely, suppose we say that a BT has a id which is a
URL + identifier (generally some id that the invoker "knows" to be unique at
that URL -- the URL deals with global uniqueness.)
Each service is then tagged as belonging to that transaction. The
services themselves can use that ID to track whatever it is they wanna
track.
If we then add some service to the URL portion, invoked services could
ask it about the status ("it's been a week, did it finish?")
change their status ("I've changed my mind and xxxx is no longer
available....")
Moreover, as a new service is added, it
could add a URL (or other contact point) for push-type messages as part of
it's response.
My opinion is that it would behoove us to make this
is a light in weight as possible. As we define things
& momentum builds, we could add more capability.
Note that the definition above is primarily by way of
conceptualizing. I'm by no means certain that it's complete.
However, I wanted to illustrate a "smaller" undertaking that seems (to
me) more likely to be workable in the shorter term.
thanx/fred
--
Fred Carter 510.986.3622 (7-3622)
mailto:frederick.carter@sun.com (external)
mailto:frederick.carter@ebay (internal)
Fusion Development/iPlanet Integration Server @ {Sun Microsystems, Inc., iPlanet}
Peter
------------------------------------------------
Peter
Furniss
Choreology Ltd
email:
peter.furniss@choreology.com
phone: +44 20 7670 1679
direct: +44
20 7670 1783
13 Austin Friars, London EC2N 2JX