Julien, the semantics you describe is (AFAICT) the semantics of inout AADLv2 port, or CORBA two-way (synchronous) request/reply.

I think it is better (at AADL level) to support it this way: one inout port, with a type being a union, for the in direction, use one part of the union, for the out direction, use the other part. This would make things easier to process at code generation level. These ports were never implemented for the reasons below.

The reply has to be synchronous, if not it will become tricky to model it in AADL. In CORBA, they use callback for the asynchronous case, but this makes the code really noisy to read: you have to split at code-level sending from receiving, which is counter-intuitive in many cases.

For the records, bidirectionnal interactions were forbidden during ASSERT because it breaks many assumptions of the RCM. So this should be designed carefully.

The problem is the following: suppose a sporadic thread that is entering a bidir interaction. Then this thread has two point of suspension: the wait for event, the wait for the answer. This fundamentally breaks RCM which allows just one suspension point.

In your example, you indicate using HTTP, so breaking RCM is not a big deal for this protocol. It would become if you want to allow it for more constrained systems

Ok, so, I was wondering if this would break the RCM model and now, I see and understand the problem. I think we night consider several things.

Your TASTE sporadic thread (we don't talk about the mapping to AADL right now, I think it is out of the scope of this discussion - at least for this moment) will have ONLY one IN parameter. And will ALWAYS wait for this incoming event. In other words, it means that you have only one interruption point (the IN parameter). Receiving the data from the request is considered as part of the application code.

If this is not enough precise, I think we can consider the sporadic thread as a state machine. It will act as the following :
1. Sporadic threads that provides PI with OUT ports:
WAIT -[IN data received]-> CALL APPLICATION CODE -> SEND DATA -> WAIT

1. Task that performs a RI with OUT parameters
   SEND-> [WAIT FOR INCOMING DATA] -> CONTINUE EXECUTION

The fact is that the [WAIT FOR INCOMING DATA] state for RI that may call PI with OUT parameters is not a suspension point as a sporadic event : it is part of the application code. In terms of schedulability, you have to consider the time required to get the OUT values in the execution time.

However, I see also the problem it can cause from a theoric point of view: in that case, the WCET would not reflect the processing time but a large estimation of execution time, leading to a very pessimist execution time. In that case, we can also issue a warning to the user when he designed such systems to indicate that network communication time has to be included in the WCET and so, may lead to incorrect results.

After all, there is also another solution which consists in considering the reply as a other sporadic event to be received by the task. But in that case, it also introduces some errors : you have to provide a mechanism to identify the reply according to the request (because you don't know if the reply come from the previous request or the one you did 3 minutes ago ...), you directly break scheduling assumptions (but we can deal with that and propose a message to the user). I think that by waiting automatically after sending the request is the KISS method and would be the most used. However, as stated, this is an open bug and we can also imagine that we can support both mechanisms ...

We could support both mechanisms, as long as we can tell the user when not to use one of them.
Note that MAST supports synchronous remote procedure calls (from their transactional model), so the analysis is possible, yet pessimistic. So the issue is to know wether we can to support it or not

Out of curiosity, you mentioned HTTP, but are there some services that would benefit from synchronous calls, e.g. as part of PUS?

That is ok for me in that case.
Just for precision, it would be used for SOIS. In SOIS, you can have a service to read a file. So, you have a sporadic function that waits for a request. The request can be : create/delete/read/writea file. In case of reading , the request will pass a buffer, the sporadic task will receive the request, fill the buffer and send the reply with the content.

If you want to have a look at the standard: http://cwe.ccsds.org/sois/default.aspx [^]

I will try to propose an implementation of SOIS within TASTE, so, we would need to introduce new services in polyorb, but not that much ...