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 agree. I think that much of the work on knowing what is the right thing
to do in the event of a failure (whose very definition is going to be
application specific in many situations) should be handled by the a level above
the basic coordination and control framework. What works for your application
may very well not work for mine.
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.
I think that this model may be exactly what you need for your application
domain (and may suit others too). However, as we tried to illustrate in the HP
submission, it's not going to suit everyone. If we can find a way of supporting
different models in the same infrastructure then we give the person who
constructs the business transaction application the freedom to customise the
framework to their application requirements. It's certainly more work/effort
than simply deciding we're going to support a single model, but in the long run
it surely means that BTP has more lifetime.
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 go a little further and say we need some way of
coordination/control and notification.
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.
This is pretty much in line with our thinking. Given this we can wrap
pretty much any legacy application as well.
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.
Agreed. If we get the underlying framework right (and it is possible to
make it lightweight) then building specific extended models on it (with any
accompanying APIs that may be required to ease application development) should
come next.
Mark.
----------------------------------------------
Dr. Mark Little ()
Transactions Architect, HP
Arjuna Labs
Phone +44 191 2064538
Fax +44 191 2064203
