|
This may turn out to be a meta-meta... comment. My apologies...
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 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).
-
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.
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.
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}
|