sipservlet-spec
  1. sipservlet-spec
  2. SIPSERVLET_SPEC-38

Add the ability to create a contextual proxy which includes a specified SipApplicationSession in its context

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-pr
    • Labels:
      None

      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.

        Activity

        Hide
        keith-lewis added a comment -

        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.

        Show
        keith-lewis added a comment - 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.
        Hide
        binod added a comment -

        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?

        Show
        binod added a comment - 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?
        Hide
        keith-lewis added a comment -

        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);

        Show
        keith-lewis added a comment - 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);
        Hide
        binod added a comment -

        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

        Show
        binod added a comment - 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
        Hide
        binod added a comment -

        Please refer to section 17.3.2.3 for a description about ContextService.

        Show
        binod added a comment - Please refer to section 17.3.2.3 for a description about ContextService.

          People

          • Assignee:
            binod
            Reporter:
            keith-lewis
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: