Hi Kevin,
Thanks for your answer.
Here's some more info:
The DCOM object is executing a set of tasks async. So, the main call to it from the Java server returns immidietialy, while the DCOM object continues execution.
Unfortuantley, it's quite an old object and i have no control over its implementation or interface - I can't change that. The DCOM object doesn't even have COM events. The only way to know if it is done or not, is to poll it using a specific method (getStatus).
I don't want to poll it from my REST API implementation, as this will break the REST concept. I have no way to know in advance how long it will take for the DCOM object to run, so I can't keep the session alive that long.
The DCOM instance is applicable to a specific user, but I can skip the requirement to get its status in subsequent calls - I can settle for just making sure it completes the execution before its destructed. The user can check the execution results later in a different app, which views the same data.
Unfortunately, I can't see how a resource will keep that reference. As far as I understand, REST is not stateful, so the resource doesn't stay alive itslef. That's esseintaly my problem in the first place.
The REST framework I'm using was internally developed, but its very strict in adhering to the REST concept.
As for another layer - this is essentialy the direction I thought of, but I don't know enough about Java server side to be sure how to go about implementing this. Would EJBs be a good answer? If not, which other objects can be maintained out of session context in the Web\Java server side?
Regards,
Inbar