how to distinguish request from response when a service supports both REQMOD and RESPMOD

Asked by qianguozheng

I am wondering how to distinguish between request and response when enable both REQMOD and RESPMOD.

To be simplify, I want to judge in ecap module this is a request or a response from server, so I can handle them in different way.
If we can not distinguish between them , I can also write two modules to handle each of them separately.

Question information

English Edit question
eCAP Edit question
No assignee Edit question
Solved by:
Alex Rousskov
Last query:
Last reply:
Revision history for this message
Best Alex Rousskov (rousskov) said :

* In REQMOD, hostx->virgin() is a request (and hostx->cause() is nil).

* In RESPMOD, hostx->virgin() is a response (and hostx->cause() is usually set to the request that triggered that response).

There are several ways an adapter transaction can tell whether it is being used in REQMOD or RESPMOD, including these two:

1. If hostx->virgin() is a request, then the adaptation mode is REQMOD. If hostx->virgin() is a response, then the adaptation mode is RESPMOD. The transaction can determine hostx->virgin() "direction" using C++ dynamic_cast of hostx->virgin()->firstLine() to either libecap::RequestLine or libecap::StatusLine. For example:

    const bool gotRequest = dynamic_cast<const libecap::RequestLine*>(&hostx->virgin()->firstLine());

2. The adapter registration code may register several adaptation Service objects, each with a mode-specific URI, and expect the host application administrator to configure/use those services according to their URI/mode. For example, the adapter registration code may register an adapter Service object with "ecap:://" URI and then expect the host application administrator to configure that service for REQMOD adaptation. When the Service object creates a transaction, it will inform that transaction what mode it is expected to operate in.

... where "hostx" is the libecap::host::Xaction pointer.

Revision history for this message
qianguozheng (guozhengqian0825) said :

Thanks Alex Rousskov, that solved my question.