bt-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [bt-spec] feedback for BTP draft spec version 0.9.0.2
- From: "Cho, Pyounguk" <PCho@iona.com>
- To: 'Peter Furniss' <peter.furniss@choreology.com>,BT - spec <bt-spec@lists.oasis-open.org>
- Date: Thu, 03 Jan 2002 15:04:51 -0800
Hi
BTPers,
The last holidays gave me a chance
to go over the BTP spec(version 0.9.0.2) line by line. I found
it extraordinarily well-organized and well written. I'm glad we're almost
getting there.
On the other hand, even though I've
been following up BTP since last June, which has made me a little more
familiar with it than others on the street, there are still quite a few quetions
that came to my mind while reading through the current version of the draft.
I suppose some of those questions can arise to the readers when the
spec is out the door. And I would also love to know whether my
understanding/interpretation is correct. Please, see my thoughts and
questions below, and let us share what you think.
All the best,
Pyounguk
=======================================================================================================================
General comments and questions :
- The definition of the BTP-reserved word "PREPARED" needs to be
clarified more careully. In the traditional 2PC/3PC-based DTP(Distributed
Transaction Processing), especially in many DB books taught in school, PREPARED
means that the participant is ready to confirm if the coordinator makes such a
call. Otherwise, CANCELLED should be sent in the 1st phase in response to
PREPARE. In BTP, PREPARED means that the participant is ready either to confirm
or to cancel following its Superior's decision. It can be confusing to readers
who are familiar with traditional DTP.
- When can a
Service/Participant truly forget about the TX? Even after (autonomous)
CONFIRMED/CANCELLED message has been sent out, CONTRADICTION can arrive
anytime!
- What is an Inferior expected
to do for CONTRADCITION message after its autonomous decision has been made?
Cancel or confirm to obey to the Superior's call? Then, what's the advantage of
making autonomous decisions anyway?
- Context created by Factory
includes SuperiorID but not TrID(TrID is optional for subcomposer/coordinator
enrollment). Exchanges between Superiors and Inferiors use SuperiorID.
Application sends Context to Factory if necessary. Application sends Context
with application messages to Participant, which responds with Context_Reply.
Application, as the Terminator, sends TrID to Decider. Isn't it enough just to
pass around TrID to keep track of things for the transaction? What advantages do
we get by using Context, SuperiorID, and TrID for different relationships? How
are they differnt from each other in terms of coverage of a given transaction
tree especially when it has branches? Why should TrID be separated from Context?
How is SuperiorID different from TrID? What are the life cycles of each of them?
How shoud values like transaction timelimit defined inside Context be used for
messages between Superiors and Inferiors?
- My understanding about Web
services is that they are meant to be used or popular for stateless services.
Personally, I have never seen any Web Services available that represents a
stateful session bean(EJB) for instance. Typical Web Services toolkits in the
market provide runtime environment that loads classes for service implementation
for each request, which is different from servelt container that loads classes
only once and keeps using it. So, you cannot even static data members. Given
that, I'm wondering how compensating operation can be designed and implemented
by BTP application developers in this type of environment.
Corrections and Issues :
line 546 - 549, line 832 - 833 :
Not every
exchange is initiated by Terminator. BTP does not follow synchronous
request/response messaging model even between Terminator and Decider let alone
between Superiors and inferiors. For instance, REQUEST_STATUS message sent by
Terminator should provide its address so that Decider can send INFERIOR_STATUSES
message to Terminator after all the information is available, in which case the
exchange is apparently initiated by Decider.
line 648 - 656
:
CONTRADICTION message is missing among those sent by
Superior
line 678 - 679
:
When the Factory may enrol a new Inferior which is also
a Superior as a result of receiving BEGIN&CONTEXT, how is enrollment status
managed? In case of CONTEXT related to application message, its corresponding
CONTEXT_REPLY message converys the enrollment status info as
completion_status(complete/related/repudiated). Do we have to add
completion_status field to BEGUN&CONTEXT message?
line 797 - 800, line 810 - 813
:
How about HAZARD message from Inferiors?
line 1033 - 1040
:
Isn't it more natural to apply request/response model
for messages such as ENROL:ENROLLED, BEGIN:BEGUN unless it takes indefinite
amount of time to process the request? This will not require use of reply
addresses in the messages.
line 1091 - 1109
:
I have no idea what "one-shot" means here.
line 1216 - 1249
:
When completion_status field in CONTEXT_REPLY is
"related", what should the application do? How can it get notified of the
completion of enrollment of the Participant that has sent the CONTEXT_REPLY with
"related"?
line 1264 - 1266, 1298 - 1299
:
Given that this is for application address, the
application(Initiator in this case) should exist as a web service? Or, should it
have some sort of listner? Application address as Terminator is used in PREPARE
or REQUEST_CONFIRM as well.
line 1306 - 1310
:
Can TrID and SuperiorID be used in an interchangeable
fashion as described here?
line 1335 - 1401
:
If a Service(operation) associated with a Participant
gets invoked multiple times before it has got into PREPARED state, does each
invocation involve enrollment in such a way that each enrollent is separate from
each other logically? Otheriwise, how can the application notifiy Participant
that no enrollment operation is necessary from the 2nd invocation? CONTEXT
message has no such fields currently.
line 1466 - 1530
:
PREPARED is an overloaded message for different
relationships. Parameter list and corresponding description should be separated
to make things easier to understand.
My interpretation of
2PC based on the current message set definitions, which is quite different from
Sanjay's described in his diagram. The main difference is that termination
protocol is driven by application in case of Composer whereas it is very similar
to the classic 2PC for Coordinator. Please, also notice the different message
exchanges for each case.
1) When Decider =
Composer:
1st phase :
Terminator(application) sends PREPARE or PREPARE/inf's to Decider possibly
multiple times. Composer is expected to send INF_STATUSES after forwarding
PREPARE message to its Inferiors and compiling results. This is how application
can evolve the confirm set of the
Cohesion.
2nd phase :
Terminator(application) issues REQUEST_CONFIRM to Composer for Inferiors in the
final confirm set. Composer propagates CONFIRM to those Inferiors. The outcome
can be either CONFIRMED, CANCELLED or
INF_STATUSES.
2) When Decider =
Coordinator:
1st phase :
Terminator(application) sends REQUEST_CONFIRM to Coordinator(Decider).
Coordinator sends PREPARE message to its Inferiors and compiling
results.
2nd phase : Coordinator
issues CONFIRM to Inferiors if and only if all the inferiors have sent PREPARED
in the 1stpahse. Coordiator propagates the outcome to application, which can be
either CONFIRMED, CANCELLED or INF_STATUSES.
line 1911 - 1915
:
Reply address should be added to the parameter list when
reply requested = true
line 1961 - 1965
:
Reply address should be added to the parameter list when
reply requested = true
line 2241 - 2262
:
How about using SOPA Fault codes? WrongState can be
mapped to SOAP Server Fault whereas UnknownParameter to SOAP Client Fault and so
on.
line 2300 - 2318
:
It can be useful to optionally prevent either heuristic
decision or autonomous decision from being made. Just to give superiors a more
deterministic control over transaction branches
line 2397 - 2612
:
When 2PC processes are quite different between Atom and
Cohesion, how can have a single sup:inf state table for
both?
It is quite difficult to follow the state transition
described here.
line 1216 - 1249, 3447 - 3453
:
"enrol" parameter is missing in the list when
completion_status is "related". Actually <enrol> element is missing in the
XML Schema definition as well when the example using SOAP binding includes an
<enrol> element. What's the rule of message compounding? Arbitary messages
can be compounded? If that's the case, how can they validated or interpreted in
the receiving side? For the sake of interoperability, this needs to
well-defined.
line 3458 - 3526
:
Description about binding does not seem to be good
enough.
line 3529 - 3697
:
How is versioning handled? The proposed "btp" namespace
definition does not appear to provide timestamp or version
info.
SOAP Actor can be possibly defined and used for each
BTP role.
SOAP mustUnderstand attribute in the header
should be mandatory not optional to ensure proper processing of BTP
messages.
Even when no application message is sent, BTP
messages should be placed in the SOAP header for the sake of consistency. In
order to observe the SOAP rule, an empty SOAP body can be sent together. This
way Participant does not have to check out SOAP body blocks for every BTP
messages(SOAP headers with BTP Actor are the only blocks to look at).
Some errors in the example like namespace for
encodingStyle attribute.
Putting an example with HTTP
headers might be helpful.
line 4402 - 4428
:
Role Groups should be better defined. For instance,
what's the difference between Cohesive Hub and Cohesive Superior? Is there any
better scheme to define BTP conformance model?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC