[SIPSERVLET_SPEC-38] Add the ability to create a contextual proxy which includes a specified SipApplicationSession in its context Created: 05/Feb/14  Updated: 26/Mar/14  Resolved: 26/Mar/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: New Feature Priority: Major
Reporter: keith-lewis Assignee: binod
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When a SIP container is included as part of a JEE 7 platform it should make available one or more implementations of the ContextService as described in "Concurrency Utilities for Java EE v1.0" (JSR236).

This service can be used to create a contextual proxy from a supplied Java object.
Any method called on the proxy executes in the thread context of the SIP thread that created the proxy.
In particular it will share the same the SipApplicationSession (SAS) context as the original thread.

This facility is very useful when registering callback objects with components that will execute the callback from a thread that is not a SIP container managed thread. The contextual proxy will set up the appropriate context for the method call.

In the case of a callback the context to use is taken from the original SIP thread so the caller does not specify the SAS to use.
It would also useful to be able to create a contextual proxy where the SAS is explicitly specified when the proxy is created.
This allows the SIP application to provide a service that can be called by non-SIP containers and unmanaged threads.
These service can make use of SIP container facilities that rely on the SAS context such as SipApplicationSession scoped CDI beans and SAS level concurrency guarantees.

The caller can choose to use a new SAS or an existing SAS looked up using a SAS-id that is known to the caller.

An example of its use would be an application which exposes a Web service that provides call origination and call control methods.



 Comments   
Comment by keith-lewis [ 05/Feb/14 ]

One possible implementation of this feature would be to provide the following method on SipApplicationSession

ContextService getContextService();

The returned context service implements the interface defined in JSR236 which could then be used to create a contextual proxy e.g.

MyService proxy = contextService.createContextualProxy(svcObject, MyService.class);

In addition to setting up the appropriate thread context the proxy would apply the application's concurrency mode. If this is set to APPLICATIONSESSION then calls to any method on the proxy would block until no other thread is executing in the context of the specified SAS.

Comment by binod [ 05/Feb/14 ]

Section 18.3.2.1 (and the example 18.3.2.4) explains a way to create contextual proxies by specifying the application session ids
using the ContextService. Isn't that sufficient?

Comment by keith-lewis [ 12/Feb/14 ]

The proposed 2.0 spec does now have this facility so it would be possible to use that mechanism.

The spec currently only discusses the facility in the context of submitting asynchronous tasks.
It does not mention the possibility of using the contextual proxy directly e.g. for synchronous access to SIP methods from a web servlet. So at the very least the document should be enhanced.

It should discuss the concurrency control implications in the case where SAS level locking is used.

In addition the current mechanism uses the SAS-id which is only unique to a SAR/WAR.

Using a method on the SipApplicationSession object would seem a more direct way of providing the functionality.

If we want to avoid including any concurrency classes in the SIP API then we can provide the following method on SipApplicationSession as suggested previously.

<T> T createSipContextualProxy(T instance, Class<T> intf);

Comment by binod [ 13/Feb/14 ]

In the current mechanism that uses SAS-id or key, doesnt require the SipApplicationSession to be looked
up before setting the context. Usually, this mechanism will be used, if an app want to submit a task with
a "different sas as context than the one associated with the current thread". With this proposal, application will have to
lookup SAS (which could be an expensive operation, could affect concurrency in some containers etc) before creating
the contextual proxy.

Yes, I agree that we can add some text describing usage of contextual proxy directly from a thread. Eg: from a webservlet

Comment by binod [ 26/Mar/14 ]

Please refer to section 17.3.2.3 for a description about ContextService.

Generated at Fri Mar 06 06:20:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.