I suppose we could implement an optional "conversation id" or "request id". I've used this kind of thing before when implementing some of the FIPA protocols for distributed intelligent agent systems. This will at least provide a hook to build on top of, so long as it's optional.
What bothers me about it is that it starts to make the protocol look transactional. Right now TAPIR is a simple, stateless protocol. That makes it easy for us to implement it over the top of HTTP. Once we start talking about distributed, or especially asynchronous processing of TAPIR messages, things get complicated.
If TAPIR becomes asynchronous, clients will have to have a mechanism to cancel a request before they get a response (meaning free up state and move on). To do this properly, TAPIR requests should be given a time to live so that downstream services that process requests can also cancel and free up state when necessary. We may also need to give the client a method for telling the service it's talking to that it should not pass requests down or should only do so to a certain depth, in other words for the client to have some control over how it's request is serviced.
In summary, we may need several additional mechanisms to make this a stateful asychronous distributed protocol. I'm not against adding a request id attribute, but going much beyond that will require some serious thought as to the implications.
-Steve
Döring, Markus wrote:
Hi, talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source.
Does this make sense? Does anyone know how other people deal with this problem?
The other thoughts were about TapirLite. We both think its a very bad idea to push all responsibility to the client by allowing any TAPIR service to be very minimalistic. If a client should be able to contact services that have different operators, operations and concepts, then I dont think we will get anything interoperable.
I still prefer that these things must exist in the most basic TAPIR service. Otherwise we should call it different - maybe even TAPIR Lite as a valid subset:
- all operations
- all logical operators
- the main COPs (<=> like)
Cconcepts and response models can be optional without much problems I think. What do you think? should we sacrifice all this to have few clients but many providers?
BTW, I think we didnt specify anywhere in capabilities if GET or XML Messaging is supported. So the idea is to always have both for all services, right?
Markus
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org